大模型有个重要的处理单元是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对并发编程逻辑做了编排，也只是治标而已。 而解决“线程数量限制”、“线程切换开销大”等问题的一个常用方案，就是构建用户态...

《十天后回到现实》：黑色大楼 很爱看一些有脑力游戏设计的大逃杀作品，最近的一个新综艺《十天后回到现实》，其中有一个关卡“【脑力7】黑色大楼”很有意思，本质上是改编小时候玩过的“谁先数到20”的游戏，这个游戏的来源是“尼姆博弈游戏”，来分析一下。 游戏描述 大楼从7层开始到14层，每层分别有8、7、6、……、1个房间亮灯，共36盏灯。闯关者和关主轮流关灯，每次只能关一层的灯，最少1盏，最多全部。游戏获胜条件是：关掉14楼的最后1盏灯获胜（通往14楼的楼梯在其余楼层灯关闭完成之前不开放）。本质上这是一个尼姆博弈游戏。

HashMap的扩容问题作为Java八股文的重要考点之一，已经背得滚瓜烂熟，但还是在生产中踩了坑（总有一个坑的形状适合你）。这里再记录一下当时的复盘。 问题概述 2023.10.27，某国0点开始，业务投放量同比前一天出现明显下跌（约30%），当天下午通过报表数据发现了此问题，晚上20:00修复代码后数据恢复。 问题发现过程 11:00，下游业务触发限流，发现流量上涨了一倍多，但因临近大促以为是大促流量，直接调高了限流阈值，没有引起重视 16:20，算法同学发现业务投放量有明显下跌，开始排查问题，看到是从0点开始，业务投放量同比昨天下跌了30%左右。排查入口流量，发现流量平稳，并没有大促带来的流量，说明可能是代码问题，排查陷入僵局 19:00~20:00，找到问题原因，修复代码并发布

动态代理在实际工作中很难用到，通常都是一些底层组件才会使用，比如SpringAOP。但由于业务正在做“降本增笑效”的多租户改造，因此正好有了使用机会。 我们的业务分布在6个国家，每个国家都有独立的服务器、数据库、中间件，然而每个国家的用户数、使用APP时间段、使用习惯等各种因素导致服务器资源的使用效率不高：有的服务可能CPU在1%～10%使用率，为了高可用却仍然需要至少4台服务器，资源会有浪费。现在要做的就是把业务、服务器、数据库均合并，通过全链路携带“租户标记TenantId”来区分请求来源，所有国家共用服务器和数据库资源。 实现的方式很简单，类似skywalking这种tracing组件，利用ThreadLocal等数据结构，将类似“业务_国家_语言_货币单位”这种请求标记全链路传递。