最近在刷LeetCode的题目，发现利用AI可以加速刷题，非常好用，详细地记录一下心得。 刷题痛点 传统的刷题方式，通常的流程是： 找到大神题单、热门题单或者自己按考点分类题单 做题，如果实在没有思路就直接看答案；如果有思路且能正常AC，则答案可以不看或者略看 直接去面试（完全碰运气和考验记忆力） 但有几个突出的问题点。 1. 标准答案看不懂 每个人的水平都不一样，标准答案通常只会照顾大多数人的水平，因此会产生两个具体的问题： 关键步骤完全看不懂，导致整个思路无法看下去 虽然能看懂，但理解答案思路需要耗费大量时间，最后得到的成果也只是“看懂这道题”而已，投入和产出悬殊巨大 2. 标准答案记不住 标准答案能看懂，但下次面试又会忘记。类比高考，标准答案能看懂，但下次考到同类题甚至原题，还是会忘记。思考一下高考当时是如何做的：找到核心考点，记住解题套路，并按自己的习惯写出来。但高考考纲是固定的，而且老师/习题会给你准备好考点和解题套路。而LeetCode并不会这样，没有人能帮助你。
大模型有个重要的处理单元是Token，云厂商AI模型的收费标准也通常是基于“Token”，英伟达黄仁勋近期GTC大会上表示Token会成为AI时代的货币（只是为了卖GPU罢了，电力+Token才是新货币……），大厂们纷纷把“每人每年发放Token”作为新的福利，体制内甚至还掀起了一股为“Token”取中文名的风潮（个人认为毫无意义……）。 NLP自然语言处理、ES关键词搜索那个时代，长句子会被分词器切分成关键词，然后被ES建立倒排索引，就很容易实现关键词搜索文档的功能。不同的分词器有不同的切分方式，最常见的就是按单词划分，比如： text[You're] [the] [1st] [runner] [home]! 1对于中文，有著名的结巴分词组件，它利用前缀词典按频率记录中文词汇，利用有向无环图（DAG）构建词汇之间字与字的关联，比如北->京->大->学包含了北京和北京大学以及各个单字词汇，利用动态规划去求得最好的词汇划分方式，利用隐马尔可夫模型（HMM）去猜测未记录的生僻词汇。这些算法都耳熟能详，分词方式也符合人类习惯。 NLP、ES等，将这种词汇叫做“词法分析单元”（Token，词元...
接触到大模型的RAG功能后，我才逐渐了解向量数据库。其中，FAISS是最古老、基础的向量数据库，有必要分析一下。 RAG和向量数据库 RAG（Retrieval-Augmented Generation，检索增强生成），结合信息检索和大模型生成的一种技术架构，通过为大模型提供知识源，来提升大模型准确度、减少大模型幻觉、提升大模型推理速度，以及让大模型能够进行“本地化”地回答。 RAG的主要流程就是“检索 - 增强 - 生成”： 检索：将输入的查询转化为向量，利用向量数据库找出最接近的上下文数据 增强：将检索结果与原始查询拼接，增强了大模型对于原始查询中关键词的理解 生成：大模型基于原始查询和检索到的上下文数据，更快速地生成更准确、更本地化的回答。 举个例子： 类型 数据 输入 我的手机经常卡死，怎么解决？ 检索R 搜索到结果：我的手机很容易卡死，怎么办？回答：清理手机垃圾。我的手机很卡，如何解决？回答：清理微信缓存的图片数据。 增强A 我的手机经常卡死，怎么解决？参考资料：“我的手机很容易卡死，怎么办？回答：清理手机垃圾。”“我的手机很卡，如何解决？回答：清理微信缓存的图片数据。” ...
近期CTO在内部推行了一个战略叫做《Skill-First：xx公司的技术战略与组织进化》，我觉得是公司和CTO为数不多的正确决策（其他大多数决策我内心都不认可哈哈，都是像长安的荔枝一样的狗屁工作，只是为了工资在作为傀儡执行），引发了我的一些思考。 Skill-First 和云计算微服务时代的API-First类似，Skill-First是AI时代的编程方式——技能优先，面向Skill编程。这种说法实际上是“面向自然语言编程”的一种实现方式，效果类似于Java里面的“面向对象编程”，只不过这里抽象和封装的不再是单个系统的“业务对象”，而是整个公司的“业务域”。 CTO下了一个核心判断：Skill是AI Agent时代的一等公民，认为公司是一组Skill的集合，人和AI Agent是Skill的编排者，例如： 数据团队：是指拥有“数据采集”、“分布分析”、“标注管理”、“质量检测”这一组Skill的编排者 算法团队：是指拥有“模型训练”、“模型验证”、“模型应用”、“模型迭代”这一组Skill的编排者 开发的核心任务，从实现需求转变为了构建更好的Skill和构建更好的Skill编排机制...
春节终于有时间把网站继续改版到3.0： 1.0: PHP+LayUI+Mysql，纯手写 2.0: Hexo + markdown，想用markdown格式 3.0：AI + vitepress + markdown + (mongo或mysql做后端，还没想好，先完成一版) vitepress 现在没有那么多空闲时间去像早期一样手撸HTML+JS+CSS了，虽然自定义程度高，但实在太累。 用Hexo就是想偷懒，无奈不能控制源代码，类似性能优化就很难做，评论之类的也很难修改，需要大量阅读前端源代码。 想用更现代的React/Vue前端框架，正好Vue出了类似博客论坛时代wordpress的vitepress，开箱即用，十分方便，于是基于vitepress开始编写第三版。
虚拟线程是JDK21最重要的、可能会成为JDK8的lambda这样标志性的特性。这里对虚拟线程做原理级别的系统性分析。 Redis使用zset存储在线车辆导致CPU100%的分析 近期发现Redis的内存使用率很低（1%），CPU反倒经常干到100%产生告警，需要分析原因。 观察到两个规律： CPU100%的时间和工作时间相同，和工作触发的某些操作有关 CPU高通常由主线程阻塞或高频操作导致，而内存低说明数据量非主因。需优先定位主线程的耗时操作。 继续观察耗时操作，这里我使用的是Redis官方客户端Redis Insight去分析，你也可以借助命令行、云厂商工具、AI去分析： 可以明显看出高耗时都是进行zrevrangebyscore操作导致的，key是online car，这是我们的在线车辆信息的缓存，用于查看在线车辆的最后上报时间、车辆元信息等数据。数据结构使用的是redisson的MapCache，底层是redis的zset。 问题就在于，zset有非常多的耗时操作，比如zadd、zrange、zrem，共同作用导致redis CPU升高。
DeepSeek的开源，可以预见国内高质量大模型资源将会越来越容易获得。“如何利用大模型来获取价值”会成为变现的方法。最近我发现了一个非常有前景的应用点——“给项目取有趣的名字”。 给项目起个有趣的名字！ 给项目取个有趣的名字，会让开发变得更有乐趣。比如之前遇到过的一些项目： 社交游戏搭建平台：Disney 参考的就是迪士尼乐园 APP首页搭建平台：Domino 参考的就是多米诺积木 接口调用攻击防范平台：霸下 参考的就是中国古代传说中参与大禹治水的神兽“霸下”，代表着力量和稳定 IT远程访问控制系统：南天门 参考的就是天庭的入口“南天门” 群告警机器人：用水浒传的108将的诨名 这会比"PlayStation"、"xxxPlatform"、"xxxManagement"这种名字来得有趣得多。但一个与项目有关联的好名字并不容易想到，需要大量的文化知识以及丰富的联想能力。这种事情交给大模型就非常合适。
虚拟线程是JDK21最重要的、可能会成为JDK8的lambda这样标志性的特性。这里对虚拟线程做原理级别的系统性分析。 虚拟线程的设计动机 对于后台服务器开发，一个请求对应一条处理线程，是最容易理解的服务器应用编程思路。但是，线程的数量会受到物理资源限制：比如默认Java线程会占用1MB内存，就会受到物理内存大小的限制；比如线程切换涉及内核态-用户态转换，需要频繁保存上下文，浪费CPU时间进行数据复制，受到CPU和带宽的限制。在海量请求到达时，线程资源会很快耗尽，成为主要的性能瓶颈。 早期的一个通常解法是：提高线程的利用率。一方面利用池化技术，减少线程创建销毁的开销，多余任务排队执行减少线程的数量；另一方面利用异步编程API（比如Future），在等待I/O时让出资源。但这样的后果是，一个请求的处理逻辑会被切分成很多段，执行-阻塞-回调-执行-阻塞-回调……这些段可能运行在不同的线程上，导致代码理解困难、调试困难。即使利用JDK8的CompletableFuture对并发编程逻辑做了编排，也只是治标而已。 而解决“线程数量限制”、“线程切换开销大”等问题的一个常用方案，就是构建用户态...
HashMap的扩容问题作为Java八股文的重要考点之一，已经背得滚瓜烂熟，但还是在生产中踩了坑（总有一个坑的形状适合你）。这里再记录一下当时的复盘。 问题概述 2023.10.27，某国0点开始，业务投放量同比前一天出现明显下跌（约30%），当天下午通过报表数据发现了此问题，晚上20:00修复代码后数据恢复。 问题发现过程 11:00，下游业务触发限流，发现流量上涨了一倍多，但因临近大促以为是大促流量，直接调高了限流阈值，没有引起重视 16:20，算法同学发现业务投放量有明显下跌，开始排查问题，看到是从0点开始，业务投放量同比昨天下跌了30%左右。排查入口流量，发现流量平稳，并没有大促带来的流量，说明可能是代码问题，排查陷入僵局 19:00~20:00，找到问题原因，修复代码并发布
粤公网安备44030602007943号