事件交代

前两周，女朋友去了开封玩一趟，回来后不久，她微信上和我吐槽了一件糟心事：由于她在两个平台都购了票，后面行程太赶，忘记在其中一个平台退票，导致现在无法退票

由于广州很多景点买票是要选择具体日期的（例如白云山、陈家祠），所以我以为她可能就是在抖音、美团买了同一天的两张票，后面忘记退掉抖音的票，导致现在票逾期，无法退款

但我还是想的太简单了，如果仅此而已，大家就不会看到这篇小破文

深入了解

随着我深入了解，才发现开封景区的购票大有不同，以下是我了解到的开封景区购票方式：

1️⃣ 你去哪个景点就买哪个景点的票，这种模式只适合去单个景区游玩，但开封景区特别多，这样买特别亏

2️⃣ 购买景区联票，开封这边景区基本是相互合作的，例如他们会出2个、4个、6个等的景区联票套餐，我女朋友就是先在抖音购买了4景区联票，后面她朋友又发现美团有6景区联票，玩起来更划算，所以才会出现了买两个平台的票的情况

抖音4景区联票：

美团6景区联票：

抖音4景区联票包含：万岁山武侠城+翰园碑林+开封城墙+铁塔公园

美团6景区联票包含：万岁山武侠城+翰园碑林+开封城墙+铁塔公园+龙亭景区+天波杨府

其中，美团的6景区联票中，龙亭景区和天波杨府是抖音4景区联票中没有的，这两个信息特别关键

其次还有两个关键信息：

（1）平台承诺随时退：票虽然有使用截止日期，但在截止日期之前，是可以申请退款，如果截止日期仍未使用，系统自动退款

（2）女友的两个平台订单状态皆为已使用

那我开头揣测是票逾期，无法退款的情况就是错误的，既然如此，是什么情况导致了两个订单都为已使用呢？

逐层分析

我原本以为景区的核销订单模式会是：订单生成一个二维码，进入景区时有个机器扫描

如此一来，就可以精准锁定平台的订单核销，但我再次猜错了。女友和我说开封这边的景区都是使用了人脸识别技术，购票时只需要录入身-份-证号，到景区就能人脸识别进入了。

到这里事情已经逐渐清晰了，于是，我尝试站在一名程序员的角度来分析景区的核销流程

• 第一步：识别用户身份

• 第二步：识别用户身份成功，分析该用户是否在合作平台购买过相关景区票

• 第三步：核销平台订单，也是最复杂的一步，因为该环节存在多种情况

1️⃣：该用户在一个平台购买了一个景区的票，这种情况最容易，用户进景区后，票务系统直接核销平台订单，核销完成平台的钱就流向票务系统；

2️⃣：该用户在一个平台购买了联合景区的票，此时锁定该票，等到用户玩完最后一个景区后，才核销订单；有人可能会存在疑惑，为什么不是玩第一个景区时就进行订单核销，而是等玩完全部景区才触发核销？这就涉及到多个平台卖票的问题，程序设计需要兼容多个平台：假设你在抖音购买了两景区联合票：万岁山+铁塔公园，在美团购买了两景区联合票：万岁山+开封城墙，你先去了万岁山，此时如果游玩第一个景区就要核销订单的话，该核销哪个平台的订单？是不是没法核销了，只有等第二个景区玩完你才知道要核销哪个平台的订单；但即使如此，也存在一种情况，就是用户只玩了一个景区，其他景区不去玩。我猜这种特殊情况下，该票就一直处于锁定未核销的状态，直到订单时间逾期，才自动核销

3️⃣：该用户在多个平台购买了一个景区的票，说实在这种情况属实矛盾，但作为一名程序员，还是得给解，我猜很有可能是以时间优先来核销订单的，也就是先在哪个平台下单，就先核销该平台的订单，毕竟用户肯定是希望核销日期更早的一张票

4️⃣：该用户在多个平台购买了联合景区的票，而我女朋友的情况就属于这一种情况，按理说这种情况也挺好解，还记得我前面提到的龙亭景区、天波杨府吗？这两个景区是抖音平台4景区联票套餐中不包含的，而美团平台6景区联票中包含的，也就是说我女朋友她们去了其中一个，就可判断出核销美团平台的订单

但巧妙又凑合的一点就是她们的游玩路线居然是：万岁山武侠城->翰园碑林->开封城墙->铁塔公园->天波杨府->龙亭景区，恰巧把两个特殊的景区放在了最后游玩

当游玩万岁山武侠城->翰园碑林->开封城墙->铁塔公园时，对于抖音平台的订单来说，已经是满足触发核销的条件，我知道此时同为聪明程序员的你也会大有疑问🤔：美团平台的订单同样存在这4个景区，不应该直接就核销抖音平台的订单。

还记得情况3吗？也就是用户在多个平台购买了一个景区票的情况，我猜测的是票务系统以时间优先来核销不同平台的订单，再看看我开头贴出来的聊天记录，我女朋友也说了：先购买抖音的4景区联票，后购买美团的6景区联票

故此，以时间优先来核销的话，程序先核销抖音平台的订单确实没问题，当她们开心地继续畅玩天波杨府->龙亭景区时，却不知又触发了新一轮美团的订单锁单，待玩完这俩景区后，剩余的景点没玩，以至于三天逾期后自动核销订单，这也佐证了情况2里的猜测

复盘总结

后续打电话跟抖音平台核实了相关的情况，顺利完成了退票退款流程。女朋友还在一旁跟我聊着整个出行的趣事，但此时我满脑子都是在想着怎么修复票务系统中的bug🐛

一开始想的方案解决方案很粗暴：就是让景区提供一个特殊通道，用户可以通过打开二维码来核销平台订单，但这种也预防不了用户通过人脸识别进入的情况

后面想了一个从根本上解决的方案：用户人脸识别，检测到存在多个平台订单时，需要提示用户选择指定平台的订单进行核销，这样就可以彻底预防多个平台重复核销的情况了

今天的分享就到此结束，如果你对技术/行业交流有兴趣，欢迎添加howcoder微信，邀你进群交流

往期精彩

《这次终于轮到前端给后端兜底了🤣》

《你不了解的Grid布局》

《就你小子还不会 Grid布局是吧？》

《超硬核：从零到一部署指南》

《私活2年，我赚到了人生的第一桶金》

是的，没错。那个被人熟知的国产开源框架 Hutool 距离被卖已经过去近 7 个月了。

那 Hutool 现在的发展如何呢？它未来有哪些更新计划呢？Hutool AI 又该如何使用呢？如果不想用 Hutool 有没有可替代的框架呢？

近半年现状

从 Hutool 官网可以看出，其被卖近 7 个月内仅发布了 4 个版本更新，除了少量的新功能外，大多是 Bug 修复，当期在此期间发布了 Hutool AI 模块，算是一个里程碑式的更新：

更新日志：hutool.cn/docs/#/CHAN…

收购公司

没错，收购 Hutool 的这家公司和收购 AList 的公司是同一家公司（不够科技），该公司前段时间因为其在收购 AList 代码中悄悄收集用户设备信息，而被推向过风口浪尖，业内人士认为其收购开源框架就是为了“投毒”，所以为此让收购框架损失了很多忠实的用户。

其实，放眼望去那些 APP 公司收集用户设备和用户信息属于家常便饭了（国内隐私侵犯问题比较严重），但 AList 因为其未做文档声明，且未将收集设备信息的代码提交到公共仓库，所以大家发现之后才会比较气愤。

Hutool-AI模块使用

Hutool AI 模块的发布算是被收购之后发布的最值得让人欣喜的事了，使用它可以对接各大 AI 模型的工具模块，提供了统一的 API 接口来访问不同的 AI 服务。

目前支持 DeepSeek、OpenAI、Grok 和豆包等主流 AI 大模型。

该模块的主要特点包括：

• 统一的 API 设计，简化不同 AI 服务的调用方式。


• 支持多种主流 AI 模型服务。


• 灵活的配置方式。


• 开箱即用的工具方法。


• 一行代码调用。

具体使用如下。

1.添加依赖

<dependency>

    <groupId>cn.hutool</groupId>

    <artifactId>hutool-ai</artifactId>

    <version>5.8.38</version>

</dependency>

2.调用API

实现对话功能：

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel("your bots id").build(), DoubaoService.class);

ArrayList<Message> messages = new ArrayList<>();

messages.add(new Message("system","你是什么都可以"));

messages.add(new Message("user","你想做些什么"));

String botsChat = doubaoService.botsChat(messages);

识别图片：

//可以使用base64图片

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel(Models.Doubao.DOUBAO_1_5_VISION_PRO_32K.getModel()).build(), DoubaoService.class);

String base64 = ImgUtil.toBase64DataUri(Toolkit.getDefaultToolkit().createImage("your imageUrl"), "png");

String chatVision = doubaoService.chatVision("图片上有些什么？", Arrays.asList(base64));



//也可以使用网络图片

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel(Models.Doubao.DOUBAO_1_5_VISION_PRO_32K.getModel()).build(), DoubaoService.class);

String chatVision = doubaoService.chatVision("图片上有些什么？", Arrays.asList("https://img2.baidu.com/it/u=862000265,4064861820&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=1544"),DoubaoCommon.DoubaoVision.HIGH.getDetail());

生成视频：

//创建视频任务

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel("your Endpoint ID").build(), DoubaoService.class);

String videoTasks = doubaoService.videoTasks("生成一段动画视频，主角是大耳朵图图，一个活泼可爱的小男孩。视频中图图在公园里玩耍，" +

		"画面采用明亮温暖的卡通风格，色彩鲜艳，动作流畅。背景音乐轻快活泼，带有冒险感，音效包括鸟叫声、欢笑声和山洞回声。", "https://img2.baidu.com/it/u=862000265,4064861820&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=1544");

		

//查询视频生成任务信息

String videoTasksInfo = doubaoService.getVideoTasksInfo("任务id");

未来发展

• Hutool5：目前 Hutool 5.x 版本主要是基于 JDK 8 实现的，后面更新主要以 BUG 修复为准。


• Hutool6：主要以功能尝鲜为主。


• Hutool7：升级为 JDK 17，添加一些新功能，删除一些不用的类。

目前只发布了 Hutool 5.x，按照目前的更新进度来看，不知何时才能盼来 Hutool7 的发布。

同类替代框架

如果担心 Hutool 有安全性问题，或更新不及时的问题可以尝试使用同类开源工具类：

• Apache Commons：commons.apache.org/


• Google Guava：github.com/google/guav…

视频解析

http://www.bilibili.com/video/BV1QR…

小结

虽然我们不知道 Hutool 被收购意味着什么？是会变的越来越好？还是会就此陨落？我们都不知道答案，所以只能把这个问题交给时间。但从个人情感的角度出发，我希望国产开源框架越做越好。好了，我是磊哥，咱们下期见。

本文已收录到我的面试小站 http://www.javacn.site，其中包含的内容有：场景题、SpringAI、SpringAIAlibaba、并发编程、MySQL、Redis、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、JVM、设计模式、消息队列、Dify、Coze、AI常见面试题等。

什么是联合索引？

首先，要理解最左匹配原则，得先知道什么是联合索引。

• 单列索引：只针对一个表列创建的索引。例如，为 users 表的 name 字段创建一个索引。


• 联合索引：也叫复合索引，是针对多个表列创建的索引。例如，为 users 表的 (last_name, first_name) 两个字段创建一个联合索引。

这个索引的结构可以想象成类似于电话簿或字典。电话簿是先按姓氏排序，在姓氏相同的情况下，再按名字排序。你无法直接跳过姓氏，快速找到一个特定的名字。

什么是最左匹配原则？

最左匹配原则指的是：在使用联合索引进行查询时，MySQL/SQL数据库从索引的最左前列开始，并且不能跳过中间的列，一直向右匹配，直到遇到范围查询（>、<、BETWEEN、LIKE）就会停止匹配。

这个原则决定了你的 SQL 查询语句是否能够使用以及如何高效地使用这个联合索引。

核心要点：

举例说明

假设我们有一个 users 表，并创建了一个联合索引 idx_name_age，包含 (last_name, age) 两个字段。

索引 idx_name_age 在磁盘上大致是这样排序的（先按 last_name 排序，last_name 相同再按 age 排序）：

(Li, 30) (Wang, 20) (Wang, 22) (Zhang, 25) (Zhang, 28)

现在，我们来看不同的查询场景：

✅ 场景一：完全匹配最左列

SELECT * FROM users WHERE last_name = 'Wang';

• 分析：查询条件包含了索引的最左列 last_name。


• 索引使用情况：✅ 可以使用索引。数据库可以快速在索引树中找到所有 last_name = 'Wang' 的记录（(Wang, 20) 和 (Wang, 22)）。

✅ 场景二：匹配所有列

SELECT * FROM users WHERE last_name = 'Wang' AND age = 22;

• 分析：查询条件包含了索引的所有列，并且顺序与索引定义一致。


• 索引使用情况：✅ 可以高效使用索引。数据库先定位到 last_name = 'Wang'，然后在这些结果中快速找到 age = 22 的记录。

✅ 场景三：匹配最左连续列

SELECT * FROM users WHERE last_name = 'Zhang';

• 分析：虽然只用了 last_name，但它是索引的最左列。


• 索引使用情况：✅ 可以使用索引。和场景一类似。

❌ 场景四：跳过最左列

SELECT * FROM users WHERE age = 25;

• 分析：查询条件没有包含索引的最左列 last_name。


• 索引使用情况：❌ 无法使用索引。这就像让你在电话簿里直接找所有叫“伟”的人，你必须翻遍整个电话簿，也就是全表扫描。

⚠️ 场景五：包含最左列，但中间有断档

-- 假设我们有一个三个字段的索引 (col1, col2, col3) -- 查询条件为 WHERE col1 = 'a' AND col3 = 'c';

• 分析：虽然包含了最左列 col1，但跳过了 col2 直接查询 col3。


• 索引使用情况：✅ 部分使用索引。数据库只能使用 col1 来缩小范围，找到所有 col1 = 'a' 的记录。对于 col3 的过滤，它无法利用索引，需要在第一步的结果集中进行逐行筛选。

⚠️ 场景六：最左列是范围查询

SELECT * FROM users WHERE last_name > 'Li' AND age = 25;

• 分析：最左列 last_name 使用了范围查询 >。


• 索引使用情况：✅ 部分使用索引。数据库可以使用索引找到所有 last_name > 'Li' 的记录（即从 Wang 开始往后的所有记录）。但是，对于 age = 25 这个条件，由于 last_name 已经是范围匹配，age 列在索引中是无序的，因此数据库无法再利用索引对 age 进行快速筛选，只能在 last_name > 'Li' 的结果集中逐行检查 age。

总结与最佳实践

最左匹配原则的本质是由索引的数据结构（B+Tree） 决定的。索引按照定义的字段顺序构建，所以必须从最左边开始才能利用其有序性。

如何设计好的联合索引？

题记

生命中的风景千变万化，但我一直在路上。

风雨兼程，不是为了抵达终点，而是为了沿途的风景。

起因

今天闲来无事，翻翻看看之前的项目。

在看到一个项目的时候，项目框架用的是SpringMvc+Spring+Mybatis。项目里面注释时间写的是2018年，时间长了，里面有好多语法现在看起来好麻烦的样子呀！

说有它就有，这不就有一个吗？在Mybatis配置的xml中，有好多where 1=1 拼接Sql的方式,看的人头都大了。想着改一下吧，又一想，代码已经时间长了，如果出现问题找谁，就先不管了。

话是这样说，但在实际工作中，还是会有方法可以代替的，下面我们一起来看看吧！

替换方式

在 MyBatis 中，WHERE 1=1 通常用来在多条件查询情况下下进行SQL 拼接，其目的就是避免在没有条件时出现语法错误。

但这种写法不够优雅，可通过以下方式进行替代：

1. 使用 <where> 标签（推荐）

MyBatis 的 <where> 标签会自动处理 SQL 的 WHERE 语句，移除多余的 AND 或 OR 关键字。

看实例：

<select id="selectUsers" resultType="User"> 

    SELECT * FROM user 

    <where> 

        <if test="username != null and username != ''"> 

            AND username = #{username} 

        </if> 

        <if test="age != null"> 

            AND age = #{age}

        </if> 

    </where> 

</select>

效果说明：

• 当无参数时，此时执行的Sql语句为：SELECT * FROM user


• 当仅传 username 时，此时执行的Sql语句为：SELECT * FROM user WHERE username = ?


• 当传 username 和 age 时，此时执行的Sql语句为：SELECT * FROM user WHERE username = ? AND age = ?

2. 使用 <trim> 标签自定义

<trim> 可更灵活地处理 SQL 片段，通过设置 prefix 和 prefixOverrides 属性模拟 <where> 的功能。

看实例：

<select id="selectUsers" resultType="User">

  SELECT * FROM user

  <trim prefix="WHERE" prefixOverrides="AND |OR ">

    <if test="username != null and username != ''">

      AND username = #{username}

    </if>

    <if test="age != null">

      AND age = #{age}

    </if>

  </trim>

</select>

说明：

• prefix="WHERE"：在条件前添加 WHERE 关键字。


• prefixOverrides="AND |OR "：移除条件前多余的 AND 或 OR。

3. 使用 <choose>、<when>、<otherwise>

类似Java在进行判断中常用的 switch-case语句，此方式适用于多条件互斥的场景。

看实例：

<select id="selectUsers" resultType="User">

  SELECT * FROM user

  <where>

    <choose>

      <when test="username != null and username != ''">

        username = #{username}

      </when>

      <when test="age != null">

        age = #{age}

      </when>

      <otherwise>

        1=1  <!-- 仅在无任何条件时使用 -->

      </otherwise>

    </choose>

  </where>

</select>

4. Java代码判断控制

在 Service 层根据条件动态选择不同的 SQL 语句。

看实例：

public List<User> getUsers(String username, Integer age) {

    if (username != null && !username.isEmpty()) {

        return userMapper.selectByUsername(username);

    } else if (age != null) {

        return userMapper.selectByAge(age);

    } else {

        return userMapper.selectAll();

    }

}

具体方式对比与选择

总结

推荐优先使用 <where> 标签，它能自动处理 SQL 语法，避免冗余代码。只有在需要更精细控制时，才考虑 <trim> 或其他方式。尽量避免在 XML 中使用 WHERE 1=1，保持 SQL 的简洁性和规范性。

展望

世间万物皆美好, 终有归途暖心潮。

在纷繁的世界里，保持内心的宁静与坚定，让每一步都走向完美的结局。

一、前言：当权限判断写满业务代码

几乎所有企业系统，都逃不过“权限”这道关。

从“谁能看”、“谁能改”到“谁能审批”，权限逻辑贯穿了业务的方方面面。

起初，大多数项目使用最常见的 RBAC（基于角色的访问控制） 模型

if (user.hasRole("admin")) {

    documentService.update(doc);

}

逻辑简单、上手快，看似能解决 80% 的问题。

但随着业务复杂度上升，RBAC 很快会失控。

比如你可能遇到以下需求 👇

• “文档的作者可以编辑自己的文档”；


• “同部门的经理也可以编辑该文档”；


• “外部合作方仅能查看共享文档”；


• “项目归档后，所有人都只读”。

这些场景无法用“角色”简单定义，

于是权限判断开始蔓延在业务代码各处，像这样：

if (user.getId().equals(doc.getOwnerId()) 

    || (user.getDept().equals(doc.getDept()) && user.isManager())) {

    // 编辑文档

} else {

    throw new AccessDeniedException("无权限");

}

时间久了，这些判断像杂草一样蔓延。

权限逻辑与业务逻辑纠缠不清，修改一处可能引发连锁反应。

可维护性、可测试性、可演化性统统崩盘。

二、RBAC 的天花板：角色无法描述现实世界

RBAC 的问题在于：它过于静态。

“角色”可以描述一类人，但描述不了上下文。

举个例子：

研发经理能编辑本部门的文档，但不能编辑市场部的。

在 RBAC 下，你只能再创建新角色：

研发经理、市场经理、项目经理……

角色越来越多，最终爆炸。

而现实世界的权限，往往与“属性”有关：

• 用户的部门


• 资源的拥有者


• 操作发生的时间 / 状态

这些动态因素，是 RBAC 无法覆盖的。

于是我们需要一个更灵活的模型 —— ABAC。

三、ABAC：基于属性的访问控制

ABAC（Attribute-Based Access Control） 的核心理念是：

授权决策 = 函数（主体属性、资源属性、操作属性、环境属性）

一句话总结：

ABAC 不关心用户是谁，而关心“用户和资源具有什么属性”。

举例说明：

“用户可以编辑自己部门的文档，或自己创建的文档。”

简单、直观、灵活。

四、引入 JCasbin：让授权逻辑从代码中消失

JCasbin(github.com/casbin/jcas…) 是一个优秀的 Java 权限引擎，支持多种模型（RBAC、ABAC）。

它最大的价值在于：

把授权逻辑从代码中抽离，让代码只负责执行业务。

在 JCasbin 中，我们通过定义：

• 模型文件（model） ：规则框架；


• 策略文件（policy） ：具体规则。

然后由 Casbin 引擎来执行判断。

五、核心实现：几行配置搞定动态权限

模型文件 model.conf

[request_definition]

r = sub, obj, act



[policy_definition]

p = sub_rule, obj_rule, act



[policy_effect]

e = some(where (p.eft == allow))



[matchers]

m = eval(p.sub_rule) && eval(p.obj_rule) && r.act == p.act

策略文件 policy.csv

p, r.sub.dept == r.obj.dept, true, edit

p, r.sub.id == r.obj.ownerId, true, edit

p, true, true, read

解释：

• 同部门可编辑；


• 作者可编辑；


• 所有人可阅读。

在代码中调用

Enforcer enforcer = new Enforcer("model.conf", "policy.csv");



User user = new User("u1", "研发部");

Document doc = new Document("d1", "研发部", "u1");



boolean canEdit = enforcer.enforce(user, doc, "edit");

System.out.println("是否有编辑权限：" + canEdit);

输出：

是否有编辑权限：true

无需任何 if-else，逻辑全在外部配置中定义。

业务代码只需调用 Enforcer，简单又优雅。

六、在 Spring Boot 中实现“无感校验”

实际项目中，我们希望权限校验能“自动触发”，

这可以通过 注解 + AOP 切面 的方式实现。

定义注解

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface CheckPermission {

    String action();

}

编写切面

@Aspect

@Component

public class PermissionAspect {



    @Autowired

    private Enforcer enforcer;



    @Before("@annotation(checkPermission)")

    public void checkAuth(JoinPoint jp, CheckPermission checkPermission) {

        Object user = getCurrentUser();

        Object resource = getRequestResource(jp);

        String action = checkPermission.action();



        if (!enforcer.enforce(user, resource, action)) {

            throw new AccessDeniedException("无权限执行操作：" + action);

        }

    }

}

在业务代码中使用

@CheckPermission(action = "edit")

@PostMapping("/doc/edit")

public void editDoc(@RequestBody Document doc) {

    documentService.update(doc);

}

✅ 授权逻辑彻底从业务中解耦，权限统一由 Casbin 引擎处理。

七、策略动态化与分布式支持

在生产环境中，权限策略通常存储在数据库中，而非文件。

JCasbin 支持多种扩展方式：

JDBCAdapter adapter = new JDBCAdapter(dataSource);

Enforcer enforcer = new Enforcer("model.conf", adapter);

支持特性包括：

• 💽 MySQL / PostgreSQL 等持久化；


• 🔄 Redis Watcher 实现多节点策略热更新；


• ⚡ SyncedEnforcer 支持高并发一致性。

这样修改权限规则就无需重新部署代码，权限即改即生效

八、总结

引入 JCasbin 后，项目结构会发生显著变化👇

最重要的是：新增规则无需改代码。

只要在策略表里加一条记录，就能实现全新的授权逻辑。

权限系统的复杂，不在于“能不能判断”，

而在于——“判断逻辑放在哪儿”。

当项目越做越大，你会发现：

真正的架构能力，不是多写逻辑，而是让逻辑有边界。

JCasbin 给了我们一个极好的解法：

一个统一的决策引擎，让权限系统既灵活又有秩序。

它不是银弹，但能让你在权限处理上的代码更纯净、系统扩展性更好。

github.com/yuboon/java…

导语

本文从日常值班问题排查痛点出发，分析方法复用的调用链路和上下文业务逻辑，通过思考分析，借助栈帧开发了一个方法调用栈的链式跟踪工具，便于展示一次请求的方法串行调用链，有助于快速定位代码来源和流量入口，有效提升研发和运维排查定位效率。期望在大家面临类似痛点时可以提供一些实践经验和参考，也欢迎大家合适的场景下接入使用。



现状分析

在系统值班时，经常会有人拿着报错截图前来咨询，作为值班研发，我们则需要获取尽可能多的信息，帮助我们分析报错场景，便于排查识别问题。

例如，下图就是一个常见的的报错信息截图示例。

从图中，我们可以初步获取到一些信息：

•菜单名称：变更单下架，我们这是变更单下架操作时的一个报错提醒。

•报错信息：序列号状态为离库状态，请检查。

•其他辅助信息：例如用户扫描或输入的86开头编码，SKU、商品名称、储位等。

这时会有一些常见的排查思路：

1、根据提示，将用户输入的86编码，按照提示文案去检查用户数据，即作为序列号编码，去看一下序列号是否存在，是否真的是离库了。

2、如果86编码确实是序列号，而且真的是离库了，那么基本上可以快速结案了，这个86编码确实是序列号并且是已离库，正如提示文案所示，这时跟提问人做好解释答疑即可。

3、如果第2步排查完，发现86编码不是序列号编码，或并非离库状态，即与提示文案不符，这时就要定位报错文案的代码来源，继续查看代码逻辑来进行判案了。（这种也比较常见，一种是报错场景较多，但提示文案比较单一，不便于在提示文案中覆盖所有报错场景；另一种提示文案陈旧未跟随需求演变而更新。这两点可以通过细分场景细化对应的报错文案，或更新报错文案，使得报错文案更优更新，但不是本文讨论的重点。）

4、如何根据报错文案快速找到代码来源呢？一般我们会在代码库中搜索提示文案，或者在日志中检索报错信息，辅助定位代码来源，后者依赖于代码中打印了该报错信息，且日志级别配置能够确保该信息打印到日志文件中。

5、倘若我们根据提示文案搜索代码时，发现该提示文案有多处代码出现，此时就较为复杂了，我们需要进一步识别，哪个才与本次报错直接有关。







每个方法向上追溯，又发现调用来源众多：

















在业务复杂的系统中，方法复用比较常见，不同的上下文和参数传递，也有着不同的业务逻辑判断和走向。

这时，基本上进入到本文要讨论的痛点：如何根据有限的提示信息快速定位代码来源？以便于分析报错业务场景，答疑解惑或快速处理问题。

屏幕前的小伙伴，如果你也经常值班排查问题，应该也会有类似的痛点所在。

启发

这是我想到了Exception异常机制，作为一名Coder，我们对异常堆栈再熟悉不过了，异常堆栈是一个“可爱”又“可恨”的东西，“可爱”在于异常堆栈确实可以帮助我们快速定位问题所在，“可恨”在于有异常基本上就是有问题，堆栈让我们审美疲劳，累觉不爱。

下面是一个Java语言的异常堆栈信息示例：







异常类体系和异常处理机制在本文中不是重点，不做过多赘述，本文重点希望能从异常堆栈中获取一些启发。

让我们近距离再观察一下我们的老朋友。

在异常堆栈信息中，主要有四类信息：

•全限定类名

•方法名

•文件名

•代码行号

这四类信息可以帮助我们有效定位代码来源，而且堆栈中记录行先后顺序，也表示着异常发生的第一现场、第二现场、第三现场、……，以此传递。

这让我想起了JVM方法栈中的栈帧。

每当一个方法被调用时，JVM会为该方法创建一个新的栈帧，并将其压入当前线程的栈（也称为调用栈或执行栈)中。栈帧包含了方法执行所需的所有信息，包括局部变量、操作数栈、常量池引用等。







思路

从Java中的Throwable中，可以看到staceTrace的get和set，这个StackTraceElement数组里面存放的信息就是我们在异常堆栈中经常看到的信息。



















再次放一下这张图，方便对照着看。







StackTraceElement类的注释中赫然写着：

StackTraceElement represents a stack frame.

对，StackTraceElement代表着一个栈帧。

这个StackTraceElement就是我要找的东西，即使非异常情况下，每个线程在执行方法调用时都会记录栈帧信息。







按照方法调用先后顺序，将调用栈中方法依次串联起来，就像糖葫芦一样，就可以得到我想要的方法调用链了。

NEXT，我可以动工写个工具了。

工具开发

工具的核心代码并不复杂，StackTraceElement 也是 Java JDK 中现成的，我所做的工作主要是从中过滤出必要的信息，加工简化成，按照顺序整理成链式信息，方便我们一眼就可以看出来方法的调用链。







入参介绍

pretty： 表示是只拼接类和方法，不拼接文件名和行号，非 pretty 是四个都会拼接。

simple： 表示会过滤一些我们代码中场景的代理增强出来的方法的信息输出。

specifiedPrefix： 指定保留相应的包路径堆栈信息，去掉一些过多的中间件信息。

其他还会过滤一些常见代理的堆栈信息：

•FastClassBySpringCGLIB

•EnhancerBySpringCGLIB

•lambda$

•Aspect

•Interceptor

对此，还封装了一些默认参数的方法，使用起来更为方便。







还有一些其他工具方法也可以使用：







使用效果

1、不过滤中间件、代理增强方法的调用栈信息

Thread#run ==> ThreadPoolExecutorWorker#run ==> ThreadPoolExecutor#runWorker ==> BaseTask#run ==> JSFTask#doRun ==> ProviderProxyInvoker#invoke ==> FilterChain#invoke ==> SystemTimeCheckFilter#invoke ==> ProviderExceptionFilter#invoke ==> ProviderContextFilter#invoke ==> InstMethodsInter#intercept ==> ProviderContextFiltereone$auxiliary$9f9kd21#call ==> ProviderContextFilter#eone$original$invoke$p882ot3$accessor$eone$pclcbe2 ==> ProviderContextFilter#eone$original$invokep882ot3 ==> ProviderGenericFilter#invoke ==> ProviderUnitValidationFilter#invoke ==> ProviderHttpGWFilter#invoke ==> ProviderInvokeLimitFilter#invoke ==> ProviderMethodCheckFilter#invoke ==> ProviderTimeoutFilter#invoke ==> ValidationFilter#invoke ==> ProviderConcurrentsFilter#invoke ==> ProviderSecurityFilter#invoke ==> WmsRpcExceptionFilter#invoke ==> WmsRpcExceptionFilter#invoke4provider ==> AdmissionControlJsfFilter#invoke ==> AdmissionControlJsfFilter#providerSide ==> AdmissionControlJsfFilter#processRequest ==> ChainedDeadlineJsfFilter#invoke ==> ChainedDeadlineJsfFilter#providerSide ==> JsfPerformanceMonitor#invoke ==> AbstractMiddlewarePerformanceMonitor#doExecute ==> PerformanceMonitorTemplateComposite#execute ==> PerformanceMonitorTemplateComposite#lambdaexecute0 ==> PerformanceMonitorTemplateUmp#execute ==> PerformanceMonitorTemplateComposite#lambdaexecute0 ==> PerformanceMonitorTemplatePayload#execute ==> JsfPerformanceMonitor#lambdainvoke0 ==> JsfPerformanceMonitor#doInvoke ==> ProviderInvokeFilter#invoke ==> ProviderInvokeFilter#reflectInvoke ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1704#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor344#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1276#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor868#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor869#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1642#invoke ==> MagicAspect#magic ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor868#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor869#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1295#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor868#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AnnotationAwareRetryOperationsInterceptor#invoke ==> RetryOperationsInterceptor#invoke ==> RetryTemplate#execute ==> RetryTemplate#doExecute ==> RetryOperationsInterceptor1#doWithRetry ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1276#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> TransactionInterceptor#invoke ==> TransactionAspectSupport#invokeWithinTransaction ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor869#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> PersistenceExceptionTranslationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxy$CglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> StackTraceUtils#trace

2、指定包路径过滤中间件后的调用栈栈信息

LockAspect#lock ==> StockTransferAppServiceImpl#increaseStock ==> MonitorAspect#monitor ==> StockRetryExecutor#operateStock ==> StockRetryExecutor$FastClassBySpringCGLIB$5188d6e#invoke ==> BaseStockOperation$FastClassBySpringCGLIB$9d76cd9a#invoke ==> StockTransferServiceImpl$FastClassBySpringCGLIB$85bb181e#invoke ==> ValidationAspect#logAndReturn ==> LogAspect#log ==> ThreadLocalRemovalAspect#removal ==> ValidationAspect#validate ==> BaseStockOperation#go ==> StockRepositoryImpl$EnhancerBySpringCGLIB$1388ef12#operateStock ==> StockTransferAppServiceImpl$EnhancerBySpringCGLIB$1095eafa#increaseStock ==> StockRepositoryImpl$FastClassBySpringCGLIB$a1b4dae4#invoke ==> StockTransferServiceImpl#increaseStock ==> DataBaseExecutor#execute ==> StockRetryExecutor$EnhancerBySpringCGLIB$b42789a#operateStock ==> StockInitializer$EnhancerBySpringCGLIB$85faf510#go ==> StockTransferServiceImpl$EnhancerBySpringCGLIB$afc21975#increaseStock ==> StockRepositoryImpl#operateStock ==> DataBaseExecutor#operate ==> StockTransferAppServiceImpl$FastClassBySpringCGLIB$e348d8e1#invoke

3、去掉Spring代理增强之后的调用栈信息

LogAspect#log ==> LockAspect#lock ==> ValidationAspect#validate ==> ValidationAspect#logAndReturn ==> MonitorAspect#monitor ==> StockTransferAppServiceImpl#decreaseStock ==> ThreadLocalRemovalAspect#removal ==> StockTransferServiceImpl#decreaseStock ==> StockOperationLoader#go ==> BaseStockOperation#go ==> DataBaseExecutor#operate ==> DataBaseExecutor#execute ==> StockRetryExecutor#operateStock ==> StockRepositoryImpl#operateStock

4、去掉一些自定义代理之后的调用栈栈信息

StockTransferAppServiceImpl#increaseStock ==> StockTransferServiceImpl#increaseStock ==> BaseStockOperation#go ==> DataBaseExecutor#operate ==> DataBaseExecutor#execute ==> StockRetryExecutor#operateStock ==> StockRepositoryImpl#operateStock

5、如果带上文件名和行号后的调用栈栈信息

StockTransferAppServiceImpl#increaseStock(StockTransferAppServiceImpl.java:103) ==> StockTransferServiceImpl#increaseStock(StockTransferServiceImpl.java:168) ==> BaseStockOperation#go(BaseStockOperation.java:152) ==> BaseStockOperation#go(BaseStockOperation.java:181) ==> BaseStockOperation#go(BaseStockOperation.java:172) ==> DataBaseExecutor#operate(DataBaseExecutor.java:34) ==> DataBaseExecutor#operate(DataBaseExecutor.java:64) ==> DataBaseExecutor#execute(DataBaseExecutor.java:79) ==> StockRetryExecutor#operateStock(StockRetryExecutor.java:64) ==> StockRepositoryImpl#operateStock(StockRepositoryImpl.java:303)



线上应用实践





接入方法调用栈跟踪工具后，根据报错提示词，可以检索到对应日志，从 ImmediateTransferController#offShelf ==> AopConfig#pointApiExpression ==> TransferOffShelfAppServiceImpl#offShelf ==> TransferOffShelfAppServiceImpl#doOffShelf 中顺藤摸瓜可以快速找到流量入口的代码位置。















适用场景

该方法调用栈工具类，可以在一些堆栈信息进行辅助排查分析的地方进行预埋，例如：

•业务异常时输出堆栈到日志信息中。

•业务监控告警信息中加入调用栈信息。

•一些复用方法调用复杂场景下，打印调用栈信息，展示调用链，方便分析。

•其他一些场景等。

延伸

在《如何一眼定位SQL的代码来源：一款SQL染色标记的简易MyBatis插件》一文中，我发布了一款SQL染色插件，该插件目前已有statementId信息，还支持通过SQLMarkingThreadLocal传递自定义附加信息。其他BGBU的技术小伙伴，也有呼声，希望在statementId基础上可以继续追溯入口方法。通过本文引入的方法调用栈跟踪工具，我在SQL染色插件中增加了方法调用栈染色信息。

SQL染色工具新版特性，欢迎大家先在TEST和UAT环境尝鲜试用，TEST和UAT环境验证没问题后，再逐步推广正式环境。

升级方法：

1、sword-mybatis-plugins版本升级至1.0.8-SNAPSHOT。

2、同时新引入本文的工具依赖

<!-- http://sd.jd.com/article/45616?shareId=105168&isHideShareButton=1 -->

<dependency>

    <groupId>com.jd.sword</groupId>

    <artifactId>sword-utils-common</artifactId>

    <version>1.0.3-SNAPSHOT</version>

</dependency>

3、mybatis config xml 配置文件按最新配置调整

<!-- http://sd.jd.com/article/42942?shareId=105168&isHideShareButton=1 -->

<!-- SQLMarking Plugin，放在第一个Plugin的位置，不影响其他组件，但不强要求位置，也可以灵活调整顺序位置 -->

<plugin interceptor="com.jd.sword.mybatis.plugin.sql.SQLMarkingInterceptor">

    <!-- 是否开启SQL染色标记插件 -->

    <property name="enabled" value="true"/>

    <!-- 是否开启方法调用栈跟踪 -->

    <property name="stackTraceEnabled" value="true"/>

    <!-- 指定需要方法调用栈跟踪的package，减少信息量，value配置为自己工程的package路径，多个路径用英文逗号分割 -->

    <property name="specifiedStackTracePackages" value="com.jdwl.wms.stock"/>

    <!-- 忽略而不进行方法堆栈跟踪的类名列表，多个用英文逗号分割，减少信息量 -->

    <property name="ignoredStackTraceClassNames" value=""/>

    <!-- 结合CPU利用率和性能考虑，方法调用栈跟踪采集率配置采集率，配置示例: m/n，表示n个里面抽m个进行采集跟踪 -->

    <!-- 预发环境和测试环境可以配置全采集，例如配置1/1，生产环境可以结合CPU利用率和性能考虑按需配置采集率 -->

    <property name="stackTraceSamplingRate" value="1/2"/>

    <!-- 是否允许SQL染色标记作为前缀，默认false表示仅作为后缀 -->

    <property name="startsWithMarkingAllowed" value="false"/>

    <!-- 方法调用栈跟踪最大深度，减少信息量 -->

    <property name="maxStackDepth" value="10"/>

</plugin>



或代码配置方式

/**

     * SQLMarking Plugin

     * http://sd.jd.com/article/42942?shareId=105168&isHideShareButton=1

     *

     * @return

     */

    @Bean

    public SQLMarkingInterceptor sQLMarkingInterceptor() {

        SQLMarkingInterceptor sQLMarkingInterceptor = new SQLMarkingInterceptor();

        Properties properties = new Properties();

        // 是否开启SQL染色标记插件

        properties.setProperty("enabled", "true");

        // 是否开启方法调用栈跟踪

        properties.setProperty("stackTraceEnabled", "true");

        // 指定需要方法调用栈跟踪的package，减少信息量，value配置为自己工程的package路径，多个路径用英文逗号分割

        properties.setProperty("specifiedStackTracePackages", "com.jdwl.wms.picking");

        // 结合CPU利用率和性能考虑，方法调用栈跟踪采集率配置采集率，配置示例: m/n，表示n个里面抽m个进行采集跟踪

        // 预发环境和测试环境可以配置全采集，例如配置1/1，生产环境可以结合CPU利用率和性能考虑按需配置采集率

        properties.setProperty("stackTraceSamplingRate", "1/2");

        // 是否允许SQL染色标记作为前缀，默认false表示仅作为后缀

        properties.setProperty("startsWithMarkingAllowed", "false");

        sQLMarkingInterceptor.setProperties(properties);

        return sQLMarkingInterceptor;

    }

接入效果

SELECT

	id,

	tenant_code,

	warehouse_no,

	sku,

	location_no,

	container_level_1,

	container_level_2,

	lot_no,

	sku_level,

	owner_no,

	pack_code,

	conversion_rate,

	stock_qty,

	prepicked_qty,

	premoved_qty,

	frozen_qty,

	diff_qty,

	broken_qty,

	status,

	md5_value,

	version,

	create_user,

	update_user,

	create_time,

	update_time,

	extend_content

FROM

	st_stock

WHERE

	deleted = 0

	AND warehouse_no = ?

	AND location_no IN(?)

	AND container_level_1 IN(?)

	AND container_level_2 IN(?)

	AND sku IN(?)

	/* [SQLMarking] statementId: com.jdwl.wms.stock.infrastructure.jdbc.main.dao.StockQueryDao.selectExtendedStockByLocation, stackTrace: BaseJmqConsumer#onMessage ==> StockInfoConsumer#handle ==> StockInfoConsumer#handleEvent ==> StockExtendContentFiller#fillExtendContent ==> StockInitializer#queryStockByWarehouse ==> StockInitializer#batchQueryStockByWarehouse ==> StockInitializer#queryByLocationAndSku ==> StockQueryRepositoryImpl#queryExtendedStockByLocationAndSku, warehouseNo: 6_6_601 */

如何接入本文工具？

如果小伙伴也有类似使用诉求，大家可以先在测试、UAT环境接入试用，然后再逐步推广线上生产环境。

1、新引入本文的工具依赖

<dependency>

    <groupId>com.jd.sword</groupId>

    <artifactId>sword-utils-common</artifactId>

    <version>1.0.3-SNAPSHOT</version>

</dependency>

2、使用工具类静态方法

com.jd.sword.utils.common.runtime.StackTraceUtils#simpleTrace()

com.jd.sword.utils.common.runtime.StackTraceUtils#simpleTrace(java.lang.String...)

com.jd.sword.utils.common.runtime.StackTraceUtils#trace()

com.jd.sword.utils.common.runtime.StackTraceUtils#trace(java.lang.String...)

com.jd.sword.utils.common.runtime.StackTraceUtils#trace(boolean)

com.jd.sword.utils.common.runtime.StackTraceUtils#trace(boolean, boolean, java.lang.String...)

最近公司里事儿比较多，项目也比较杂，但是因为公司的项目主要是聚焦OA方面，很多东西可以复用。

比方说：表单、表格、搜索栏等等，这部分现阶段大部分都是各写各的，每个项目因为主要的开发不同，各自维护自己的一份。

但是领导现在觉得还是维护一套组件库来的比较方便，一来是减少重复工作量，提升开发效率，二来是方便新人加入团队以后尽量与老成员开发风格保持一致。

另外还有一个原因是项目内现在有的用AntDesign，有的用ElmentPlus，这些库的样式和UI设计出来的风格不搭，改起来也非常麻烦。

我听见这个提议以后后背冷汗都下来了。

我再跟大家强调一遍，不要封装组件库！

咱们说说为什么：

抬高开发成本

大部分人都感觉封装组件库是降低了开发成本，但实际上大部分项目并非如此，封装组件库大部分时候都是抬高了开发成本。

项目不同，面对的客户不同，需求也就不同，所以无论是客户方的需求还是UI设计稿都存在一定的差别，有些时候差距很大。

针对项目单独进行开发虽然在表面上看起来是浪费了人力资源，重复了很多工作，但是在后期开发和维护过程中会节省非常多的时间。

这部分都是成本。很多时候组件的开发并不是面对产品或者团队的，而是面向项目和客户的。

这也就导致了组件的开发会存在极大的不确定性，一方面是需求的不确定，另一方面是组件灵活度的不确定。

很多时候开发出来的组件库会衍生出N多个版本，切出N多个分支，最后在各个项目中引用，逐渐变成一个臃肿的垃圾代码集合体。

我不相信有人会在自己的项目上改完以后，还把修改的部分根据他人的反馈再进行调整，最后合并到 master 分支上去。

我从未见过有这个操作的兄弟。

技术达不到封装水平

团队内部技术不在一个水平线上，事实上也不可能在一个水平线上。

有些人的技术好，封装出来的组件确实很契合大多数的业务场景，有些人技术稍逊，封装出来的组件就不一定能契合项目。

但是如果你用他人封装的组件，牵扯到定制化需求的时候势必会改造，这时候改造就有可能会影响其他项目。

尤其一种情况，老项目升级，这是组件库最容易出问题的时候。可能上个版本封版的组件库在老项目运行的非常完美，但是需要升级的项目引用新的组件库的时候就会出现很多问题。

大部分程序员其实都达不到封装组件库的水准。

如果想要试一试可以参考ElmentUI老版本代码，自己封装一下Select、Input、Button这几个组件，看看和这些久经考验的开源组件库编码程序员还差多少。

技术负债严重

承接上一个问题，不是团队内每个人的水平都一样，并且每个人的编码风格也都是不一样的。(Ts最大的作用点)

可能组件库建立初期会节省非常多的重复工作，毕竟拿来就用，而且本身就是封装好的，简直可以为自己鼓掌了。

照着镜子问这是哪个天才编写的组件库，简直不要太棒了。

但是随着时间的推移，你会发现这个组件库越来越难用，需要考虑的方面越来越多，受影响的模块越来越多，你会变得越来越不敢动其中的代码。

项目越来越多，组件库中的分支和版本越来越多，团队中的人有些已经离开，有些人刚来，这时候技术负债就已经形成了。

更不要说大部分人没有写技术文档的习惯，甚至是连写注释的习惯都没有，功能全靠看代码和猜，技术上的负债越来越严重，这个阶段组件库离崩塌就已经不远了。

新项目在立项之初你就会本能的排斥使用组件库，但是对于老项目呢？改是不可能改动的，但是不维护Bug又挂在这儿。

那你到底是选择代码能跑，还是选择...

对个人发展不利

有些兄弟觉得能封装组件库，让自己的代码在这个团队，这个公司永远的流传下去，简直是跟青史留名差不多了。以后谁用到这个组件都会看到author后面写着我的名字。

但事实并非如此！

封装出的组件库大部分情况下会让你"青💩留名"，因为后面的每个人用这个组件都会骂，这是哪个zz封装的组件，为啥这么写，这里不应该这么写嘛？

如果你一直呆在这个公司，由你一手搭建的这个组件库将伴随你在这个公司的整个职业生涯。

一时造轮子，一辈子维护轮子！

只要任何人用到你这个组件库，遇到了问题一定会来找你。不管你现在到底有没有在负责这个组件库！

这种通用性的组件库不可能没有问题，但是一旦有了问题找到你，你或者是解决不了，又或者是解决的不及时，都将或多或少的影响你的同事对你的评价。

当所有人都对你封装的这个组件库不满意，并且在开组会的时候提出来因为xx封装的组件库不好使，导致了项目延期，时间一长你的领导会对你有好印象？

结语

希望兄弟们还是要明白，对于一个职场人来说，挣钱最重要，能升上去最重要。其他的所有都是细枝末节，不必太在意。

对于客户和老板而言，能快速交付，把钱挣到手最重要，其他也都是无所谓的小事。

对于咱们自己来说，喜欢折腾是程序员的特质，但是要分清形势。

大家好，我是程序员鱼皮。我发现很多程序员都不打日志，有的是 不想 打、有的是 意识不到 要打、还有的是 真不会 打日志啊！

前段时间的模拟面试中，我问了几位应届的 Java 开发同学 “你在项目中是怎么打日志的”，得到的答案竟然是 “支支吾吾”、“阿巴阿巴”，更有甚者，竟然表示：直接用 System.out.println() 打印一下吧。。。

要知道，日志是我们系统出现错误时，最快速有效的定位工具，没有日志给出的错误信息，遇到报错你就会一脸懵逼；而且日志还可以用来记录业务信息，比如记录用户执行的每个操作，不仅可以用于分析改进系统，同时在遇到非法操作时，也能很快找到凶手。

因此，对于程序员来说，日志记录是重要的基本功。但很多同学并没有系统学习过日志操作、缺乏经验，所以我写下这篇文章，分享自己在开发项目中记录日志的方法和最佳实践，希望对大家有帮助~

一、日志记录的方法

日志框架选型

有很多 Java 的日志框架和工具库，可以帮我们用一行代码快速完成日志记录。

在学习日志记录之前，很多同学应该是通过 System.out.println 输出信息来调试程序的，简单方便。

但是，System.out.println 存在很严重的问题！

首先，System.out.println 是一个同步方法，每次调用都会导致 I/O 操作，比较耗时，频繁使用甚至会严重影响应用程序的性能，所以不建议在生产环境使用。此外，它只能输出简单的信息到标准控制台，无法灵活设置日志级别、格式、输出位置等。

所以我们一般会选择专业的 Java 日志框架或工具库，比如经典的 Apache Log4j 和它的升级版 Log4j 2，还有 Spring Boot 默认集成的 Logback 库。不仅可以帮我们用一行代码更快地完成日志记录，还能灵活调整格式、设置日志级别、将日志写入到文件中、压缩日志等。

可能还有同学听说过 SLF4J（Simple Logging Facade for Java），看英文名就知道了，这玩意并不是一个具体的日志实现，而是为各种日志框架提供简单统一接口的日志门面（抽象层）。

啥是门面？

举个例子，现在我们要记录日志了，先联系到前台接待人员 SLF4J，它说必须要让我们选择日志的级别（debug / info / warn / error），然后要提供日志的内容。确认之后，SLF4J 自己不干活，屁颠屁颠儿地去找具体的日志实现框架，比如 Logback，然后由 Logback 进行日志写入。

这样做有什么好处呢？无论我们选择哪套日志框架、或者后期要切换日志框架，调用的方法始终是相同的，不用再去更改日志调用代码，比如将 log.info 改为 log.printInfo。

既然 SLF4J 只是玩抽象，那么 Log4j、Log4j 2 和 Logback 应该选择哪一个呢？

值得一提的是，SLF4J、Log4j 和 Logback 竟然都是同一个作者（俄罗斯程序员 Ceki Gülcü）。

首先，Log4j 已经停止维护，直接排除。Log4j 2 和 Logback 基本都能满足功能需求，那么就看性能、稳定性和易用性。

• 从性能来说，Log4j 2 和 Logback 虽然都支持异步日志，但是 Log4j 基于 LMAX Disruptor 高性能异步处理库实现，性能更高。


• 从稳定性来说，虽然这些日志库都被曝出过漏洞，但 Log4j 2 的漏洞更为致命，姑且算是 Logback 得一分。


• 从易用性来说，二者差不多，但 Logback 是 SLF4J 的原生实现、Log4j2 需要额外使用 SLF4J 绑定器实现。

再加上 Spring Boot 默认集成了 Logback，如果没有特殊的性能需求，我会更推荐初学者选择 Logback，都不用引入额外的库了~

使用日志框架

日志框架的使用非常简单，一般需要先获取到 Logger 日志对象，然后调用 logger.xxx（比如 logger.info）就能输出日志了。

最传统的方法就是通过 LoggerFactory 手动获取 Logger，示例代码如下：

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

​

public class MyService {

   private static final Logger logger = LoggerFactory.getLogger(MyService.class);

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

上述代码中，我们通过调用日志工厂并传入当前类，创建了一个 logger。但由于每个类的类名都不同，我们又经常复制这行代码到不同的类中，就很容易忘记修改类名。

所以我们可以使用 this.getClass 动态获取当前类的实例，来创建 Logger 对象：

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

给每个类都复制一遍这行代码，就能愉快地打日志了。

但我觉得这样做还是有点麻烦，我连复制粘贴都懒得做，怎么办？

还有更简单的方式，使用 Lombok 工具库提供的 @Slf4j 注解，可以自动为当前类生成一个名为 log 的 SLF4J Logger 对象，简化了 Logger 的定义过程。示例代码如下：

import lombok.extern.slf4j.Slf4j;

​

@Slf4j

public class MyService {

   public void doSomething() {

       log.info("执行了一些操作");

  }

}

这也是我比较推荐的方式，效率杠杠的。

此外，你可以通过修改日志配置文件（比如 logback.xml 或 logback-spring.xml）来设置日志输出的格式、级别、输出路径等。日志配置文件比较复杂，不建议大家去记忆语法，随用随查即可。

二、日志记录的最佳实践

学习完日志记录的方法后，再分享一些我个人记录日志的经验。内容较多，大家可以先了解一下，实际开发中按需运用。

1、合理选择日志级别

日志级别的作用是标识日志的重要程度，常见的级别有：

• TRACE：最细粒度的信息，通常只在开发过程中使用，用于跟踪程序的执行路径。


• DEBUG：调试信息，记录程序运行时的内部状态和变量值。


• INFO：一般信息，记录系统的关键运行状态和业务流程。


• WARN：警告信息，表示可能存在潜在问题，但系统仍可继续运行。


• ERROR：错误信息，表示出现了影响系统功能的问题，需要及时处理。


• FATAL：致命错误，表示系统可能无法继续运行，需要立即关注。

其中，用的最多的当属 DEBUG、INFO、WARN 和 ERROR 了。

建议在开发环境使用低级别日志（比如 DEBUG），以获取详细的信息；生产环境使用高级别日志（比如 INFO 或 WARN），减少日志量，降低性能开销的同时，防止重要信息被无用日志淹没。

注意一点，日志级别未必是一成不变的，假如有一天你的程序出错了，但是看日志找不到任何有效信息，可能就需要降低下日志输出级别了。

2、正确记录日志信息

当要输出的日志内容中存在变量时，建议使用参数化日志，也就是在日志信息中使用占位符（比如 {}），由日志框架在运行时替换为实际参数值。

比如输出一行用户登录日志：

// 不推荐

logger.debug("用户ID：" + userId + " 登录成功。");

​

// 推荐

logger.debug("用户ID：{} 登录成功。", userId);

这样做不仅让日志清晰易读；而且在日志级别低于当前记录级别时，不会执行字符串拼接，从而避免了字符串拼接带来的性能开销、以及潜在的 NullPointerException 问题。所以建议在所有日志记录中，使用参数化的方式替代字符串拼接。

此外，在输出异常信息时，建议同时记录上下文信息、以及完整的异常堆栈信息，便于排查问题：

try {

   // 业务逻辑

} catch (Exception e) {

logger.error("处理用户ID：{} 时发生异常：", userId, e);

}

3、控制日志输出量

过多的日志不仅会占用更多的磁盘空间，还会增加系统的 I/O 负担，影响系统性能。

因此，除了根据环境设置合适的日志级别外，还要尽量避免在循环中输出日志。

可以添加条件来控制，比如在批量处理时，每处理 1000 条数据时才记录一次：

if (index % 1000 == 0) {

   logger.info("已处理 {} 条记录", index);

}

或者在循环中利用 StringBuilder 进行字符串拼接，循环结束后统一输出：

StringBuilder logBuilder = new StringBuilder("处理结果：");

for (Item item : items) {

   try {

       processItem(item);

       logBuilder.append(String.format("成功[ID=%s], ", item.getId()));

  } catch (Exception e) {

       logBuilder.append(String.format("失败[ID=%s, 原因=%s], ", item.getId(), e.getMessage()));

  }

}

logger.info(logBuilder.toString());

如果参数的计算开销较大，且当前日志级别不需要输出，应该在记录前进行级别检查，从而避免多余的参数计算：

if (logger.isDebugEnabled()) {

   logger.debug("复杂对象信息：{}", expensiveToComputeObject());

}

此外，还可以通过更改日志配置文件整体过滤掉特定级别的日志，来防止日志刷屏：

<!-- Logback 示例 -->

<appender name="LIMITED" class="ch.qos.logback.classic.AsyncAppender">

<!-- 只允许 INFO 级别及以上的日志通过 -->

   <filter class="ch.qos.logback.classic.filter.ThresholdFilter">

       <level>INFO</level>

   </filter>

   <!-- 配置其他属性 -->

</appender>

4、把控时机和内容

很多开发者（尤其是线上经验不丰富的开发者）并没有养成记录日志的习惯，觉得记录日志不重要，等到出了问题无法排查的时候才追悔莫及。

一般情况下，需要在系统的关键流程和重要业务节点记录日志，比如用户登录、订单处理、支付等都是关键业务，建议多记录日志。

对于重要的方法，建议在入口和出口记录重要的参数和返回值，便于快速还原现场、复现问题。

对于调用链较长的操作，确保在每个环节都有日志，以便追踪到问题所在的环节。

如果你不想区分上面这些情况，我的建议是尽量在前期多记录一些日志，后面再慢慢移除掉不需要的日志。比如可以利用 AOP 切面编程在每个业务方法执行前输出执行信息：

@Aspect

@Component

public class LoggingAspect {

​

   @Before("execution(* com.example.service..*(..))")

   public void logBeforeMethod(JoinPoint joinPoint) {

       Logger logger = LoggerFactory.getLogger(joinPoint.getTarget().getClass());

       logger.info("方法 {} 开始执行", joinPoint.getSignature().getName());

  }

}

利用 AOP，还可以自动打印每个 Controller 接口的请求参数和返回值，这样就不会错过任何一次调用信息了。

不过这样做也有一个很重要的点，注意不要在日志中记录了敏感信息，比如用户密码。万一你的日志不小心泄露出去，就相当于泄露了大量用户的信息。

5、日志管理

随着日志文件的持续增长，会导致磁盘空间耗尽，影响系统正常运行，所以我们需要一些策略来对日志进行管理。

首先是设置日志的滚动策略，可以根据文件大小或日期，自动对日志文件进行切分。比如按文件大小滚动：

<!-- 按大小滚动 -->

<rollingPolicy class="ch.qos.logback.core.rolling.SizeBasedRollingPolicy">

   <maxFileSize>10MB</maxFileSize>

</rollingPolicy>

如果日志文件大小达到 10MB，Logback 会将当前日志文件重命名为 app.log.1 或其他命名模式（具体由文件名模式决定），然后创建新的 app.log 文件继续写入日志。

还有按照时间日期滚动：

<!-- 按时间滚动 -->

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log</fileNamePattern>

</rollingPolicy>

上述配置表示每天创建一个新的日志文件，%d{yyyy-MM-dd} 表示按照日期命名日志文件，例如 app-2024-11-21.log。

还可以通过 maxHistory 属性，限制保留的历史日志文件数量或天数：

<maxHistory>30</maxHistory>

这样一来，我们就可以按照天数查看指定的日志，单个日志文件也不会很大，提高了日志检索效率。

对于用户较多的企业级项目，日志的增长是飞快的，因此建议开启日志压缩功能，节省磁盘空间。

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log.gz</fileNamePattern>

</rollingPolicy>

上述配置表示：每天生成一个新的日志文件，旧的日志文件会被压缩存储。

除了配置日志切分和压缩外，我们还需要定期审查日志，查看日志的有效性和空间占用情况，从日志中发现系统的问题、清理无用的日志信息等。

如果你想偷懒，也可以写个自动化清理脚本，定期清理过期的日志文件，释放磁盘空间。比如：

# 每月清理一次超过 90 天的日志文件

find /var/log/myapp/ -type f -mtime +90 -exec rm {} ;

6、统一日志格式

统一的日志格式有助于日志的解析、搜索和分析，特别是在分布式系统中。

我举个例子大家就能感受到这么做的重要性了。

统一的日志格式：

2024-11-21 14:30:15.123 [main] INFO com.example.service.UserService - 用户ID：12345 登录成功

2024-11-21 14:30:16.789 [main] ERROR com.example.service.UserService - 用户ID：12345 登录失败，原因：密码错误

2024-11-21 14:30:17.456 [main] DEBUG com.example.dao.UserDao - 执行SQL：[SELECT * FROM users WHERE id=12345]

2024-11-21 14:30:18.654 [main] WARN com.example.config.AppConfig - 配置项 `timeout` 使用默认值：3000ms

2024-11-21 14:30:19.001 [main] INFO com.example.Main - 应用启动成功，耗时：2.34秒

这段日志整齐清晰，支持按照时间、线程、级别、类名和内容搜索。

不统一的日志格式：

2024/11/21 14:30 登录成功 用户ID: 12345

2024-11-21 14:30:16 错误 用户12345登录失败！密码不对

DEBUG 执行SQL SELECT * FROM users WHERE id=12345

Timeout = default

应用启动成功

emm，看到这种日志我直接原地爆炸！

建议每个项目都要明确约定和配置一套日志输出规范，确保日志中包含时间戳、日志级别、线程、类名、方法名、消息等关键信息。

<!-- 控制台日志输出 -->

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

   <encoder>

       <!-- 日志格式 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

   </encoder>

</appender>

也可以直接使用标准化格式，比如 JSON，确保所有日志遵循相同的结构，便于后续对日志进行分析处理：

<encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">

   <!-- 配置 JSON 编码器 -->

</encoder>

此外，你还可以通过 MDC（Mapped Diagnostic Context）给日志添加额外的上下文信息，比如用户 ID、请求 ID 等，方便追踪。在 Java 代码中，可以为 MDC 变量设置值：

MDC.put("requestId", "666");

MDC.put("userId", "yupi");

logger.info("用户请求处理完成");

MDC.clear();

对应的日志配置如下：

<!-- 文件日志配置 -->

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

   <encoder>

       <!-- 包含 MDC 信息 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{requestId}] [%X{userId}] %msg%n</pattern>

   </encoder>

</appender>

这样，每个请求、每个用户的操作一目了然。

7、使用异步日志

对于追求性能的操作，可以使用异步日志，将日志的写入操作放在单独的线程中，减少对主线程的阻塞，从而提升系统性能。

除了自己开线程去执行 log 操作之外，还可以直接修改配置来开启 Logback 的异步日志功能：

<!-- 异步 Appender -->

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">

   <queueSize>500</queueSize> <!-- 队列大小 -->

   <discardingThreshold>0</discardingThreshold> <!-- 丢弃阈值，0 表示不丢弃 -->

   <neverBlock>true</neverBlock> <!-- 队列满时是否阻塞主线程，true 表示不阻塞 -->

   <appender-ref ref="CONSOLE" /> <!-- 生效的日志目标 -->

   <appender-ref ref="FILE" />

</appender>

上述配置的关键是配置缓冲队列，要设置合适的队列大小和丢弃策略，防止日志积压或丢失。

8、集成日志收集系统

在比较成熟的公司中，我们可能会使用更专业的日志管理和分析系统，比如 ELK（Elasticsearch、Logstash、Kibana）。不仅不用每次都登录到服务器上查看日志文件，还可以更灵活地搜索日志。

但是搭建和运维 ELK 的成本还是比较大的，对于小团队，我的建议是不要急着搞这一套。

OK，就分享到这里，洋洋洒洒 4000 多字，希望这篇文章能帮助大家意识到日志记录的重要性，并养成良好的日志记录习惯。学会的话给鱼皮点个赞吧~

日志不是写给机器看的，是写给未来的你和你的队友看的！

更多

💻 编程学习交流：编程导航

📃 简历快速制作：老鱼简历

✏️ 面试刷题神器：面试鸭

最近在做的事情正好需要系统地研究微服务与单体架构的取舍与演进。读到这篇文章《Microservices Are Quietly Dying — And It’s Beautiful》，许多观点直击痛点、非常启发，于是我顺手把它翻译出来，分享给大家，也希望能给同样在复杂性与效率之间权衡的团队一些参考。

微服务正在悄然消亡：这是一件美好的事

为了把我们的创业产品扩展到数百万用户，我们搭建了 47 个微服务。

用户从未达到一百万，但我们达到了每月 23,000 美元的 AWS 账单、长达 14 小时的故障，以及一个再也无法高效交付新功能的团队。

那一刻我才意识到：我们并没有在构建产品，而是在搭建一座分布式的自恋纪念碑。

我们都信过的谎言

五年前，微服务几乎是教条。Netflix 用它，Uber 用它。每一场技术大会、每一篇 Medium 文章、每一位资深架构师都在高喊同一句话：单体不具备可扩展性，微服务才是答案。

于是我们照做了。我们把 Rails 单体拆成一个个服务：用户服务、认证服务、支付服务、通知服务、分析服务、邮件服务；然后是子服务，再然后是调用服务的服务，层层套叠。

到第六个月，我们已经在 12 个 GitHub 仓库里维护 47 个服务。我们的部署流水线像一张地铁图，架构图需要 4K 显示器才能看清。

当“最佳实践”变成“最差实践”

我们不断告诫自己：一切都在运转。我们有 Kubernetes，有服务网格，有用 Jaeger 的分布式追踪，有 ELK 的日志——我们很“现代”。

但那些光鲜的微服务文章从不提的一点是：分布式的隐性税。

每一个新功能都变成跨团队的协商。想给用户资料加一个字段？那意味着要改五个服务、提三个 PR、协调两周，并进行一次像劫案电影一样精心编排的数据库迁移。

我们的预发布环境成本甚至高于生产环境，因为想测试任何东西，都需要把一切都跑起来。47 个服务在 Docker Compose 里同时启动，内存被疯狂吞噬。

那个彻夜崩溃的夜晚

凌晨 2:47，Slack 被消息炸翻。

生产环境宕了。不是某一个服务——是所有服务。支付服务连不上用户服务，通知服务不断超时，API 网关对每个请求都返回 503。

我打开分布式追踪面板：一万五千个 span，全线飘红。瀑布图像抽象艺术。我花了 40 分钟才定位出故障起点。

结果呢？一位初级开发在认证服务上发布了一个配置变更，只是一个环境变量。它让令牌校验多了 2 秒延迟，这个延迟在 11 个下游服务间层层传递，超时叠加、断路器触发、重试逻辑制造请求风暴，整个系统在自身重量下轰然倒塌。

我们搭了一座纸牌屋，却称之为“容错架构”。

我们花了六个小时才修复。并不是因为 bug 复杂——它只是一个配置的单行改动，而是因为排查分布式系统就像破获一桩谋杀案：每个目击者说着不同的语言，而且有一半在撒谎。

那个被忽略的低语

一周后，在复盘会上，我们的 CTO 说了句让所有人不自在的话：

“要不我们……回去？”

回到单体。回到一个仓库。回到简单。

会议室一片沉默。你能感到认知失调。我们是工程师，我们很“高级”。单体是给传统公司和训练营毕业生用的，不是给一家正打造未来的 A 轮初创公司用的。

但随后有人把指标展开：平均恢复时间 4.2 小时；部署频率每周 2.3 次（从单体时代的每周 12 次一路下滑）；云成本增长速度比营收快 40%。

数字不会说谎。是架构在拖垮我们。

美丽的回归

我们用了三个月做整合。47 个服务归并成一个模块划分清晰的 Rails 应用；Kubernetes 变成负载均衡后面的三台 EC2；12 个仓库的工作流收敛成一个边界明确的仓库。

结果简直让人尴尬。

部署时间从 25 分钟降到 90 秒；AWS 账单从 23,000 美元降到 3,800 美元；P95 延迟提升了 60%，因为我们消除了 80% 的网络调用。更重要的是——我们又开始按时交付功能了。

开发者不再说“我需要和三个团队协调”，而是开始说“午饭前给你”。

我们的“分布式系统”变回了结构良好的应用。边界上下文变成 Rails 引擎，服务调用变成方法调用，Kafka 变成后台任务，“编排层”……就是 Rails 控制器。

它更快，它更省，它更好。

我们真正学到的是什么

这是真相：我们为此付出两年时间和 40 万美元才领悟——

微服务不是一种纯粹的架构模式，而是一种组织模式。Netflix 需要它，因为他们有 200 个团队。你没有。Uber 需要它，因为他们一天发布 4,000 次。你没有。

复杂性之所以诱人，是因为它看起来像进步。 拥有 47 个服务、Kubernetes、服务网格和分布式追踪，看起来很“专业”；而一个单体加一套 Postgres，看起来很“业余”。

但复杂性是一种税。它以认知负担、运营开销、开发者幸福感和交付速度为代价。

而大多数初创公司根本付不起这笔税。

我们花了两年时间为并不存在的规模做优化，同时牺牲了能让我们真正达到规模的简单性。

你不需要 50 个微服务，你需要的是自律

软件架构的“肮脏秘密”是：好的设计在任何规模都奏效。

一个结构良好的单体，拥有清晰的模块、明确的边界上下文和合理的关注点分离，比一团由希望和 YAML 勉强粘合在一起的微服务乱麻走得更远。

微服务并不是因为“糟糕”而式微，而是因为我们出于错误的理由使用了它。我们选择了分布式的复杂性而不是本地的自律，选择了运营的负担而不是价值的交付。

那些悄悄回归单体的公司并非承认失败，而是在承认更难的事实：我们一直在解决错误的问题。

所以我想问一个问题：你构建微服务，是在逃避什么？

如果答案是“一个凌乱的代码库”，那我有个坏消息——分布式系统不会修好坏代码，它只会让问题更难被发现。

嘿，各位 Java 小伙伴们！今天咱们要来聊聊 Spring Boot 里一个超酷炫但又有点让人头疼的家伙 —— 分布式事务。这玩意儿就像是一场大型派对的组织者，要确保派对上所有的活动（操作）要么都顺顺利利地进行，要么就一起取消，绝对不能出现有的活动进行了一半，有的却没开始的尴尬局面。

为啥要有分布式事务

在以前那种单体应用的小世界里，事务处理就像在自己家里整理东西，所有的东西（数据）都在一个地方，要保证操作的一致性很容易。但随着业务越来越复杂，应用变成了分布式的 “大杂烩”，各个服务就像住在不同房子里的小伙伴，这时候再想保证所有操作都一致，就需要分布式事务这个 “超级协调员” 出场啦。

Spring Boot 里的分布式事务支持

Spring Boot 对分布式事务的支持就像是给你配备了一套超级工具包。其中，@Transactional注解大家肯定都很熟悉，在单体应用里它就是事务管理的小能手。但在分布式场景下，我们还有更厉害的武器，比如基于 XA 协议的分布式事务管理器，以及像 Seata 这样的开源框架。

XA 协议的分布式事务管理器

XA 协议就像是一个国际通用的 “交流规则”，它规定了数据库和事务管理器之间怎么沟通。在 Spring Boot 里使用 XA 协议的分布式事务管理器，就像是给各个服务的数据库都请了一个翻译，让它们能准确地交流事务相关的信息。

下面我们来看一段简单的代码示例，假设我们有两个服务，一个是订单服务，一个是库存服务，我们要在创建订单的同时扣减库存，并且保证这两个操作要么都成功，要么都失败。

首先，我们需要配置 XA 数据源，这里以 MySQL 为例：

@Configuration

public class XADataSourceConfig {

    @Bean

    @ConfigurationProperties(prefix = "spring.datasource")

    public DataSourceProperties dataSourceProperties() {

        return new DataSourceProperties();

    }

    @Bean

    public DataSource dataSource() {

        return dataSourceProperties().initializeDataSourceBuilder()

              .type(com.mysql.cj.jdbc.MysqlXADataSource.class)

              .build();

    }

}

然后，配置事务管理器：

@Configuration

public class XATransactionConfig {

    @Autowired

    private DataSource dataSource;

    @Bean

    public PlatformTransactionManager transactionManager() throws SQLException {

        return new JtaTransactionManager(new UserTransactionFactory(), new TransactionManagerFactory(dataSource));

    }

}

接下来，在业务代码里使用@Transactional注解：

@Service

public class OrderService {

    @Autowired

    private OrderRepository orderRepository;

    @Autowired

    private StockService stockService;

    @Transactional

    public void createOrder(Order order) {

        orderRepository.save(order);

        stockService.decreaseStock(order.getProductId(), order.getQuantity());

    }

}

在这个例子里，createOrder方法上的@Transactional注解就像一个 “指挥官”，它会协调订单保存和库存扣减这两个操作，确保它们在同一个事务里执行。

Seata 框架

Seata 就像是一个更智能、更强大的 “事务指挥官”。它有三个重要的组件：TC（Transaction Coordinator）事务协调器、TM（Transaction Manager）事务管理器和 RM（Resource Manager）资源管理器。TC 就像一个调度中心，TM 负责发起和管理事务，RM 则负责管理资源和提交 / 回滚事务。

使用 Seata，我们首先要在项目里引入相关依赖：

<dependency>

    <groupId>com.alibaba.cloud</groupId>

    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>

</dependency>

然后，配置 Seata 客户端：

seata:

  application-id: ${spring.application.name}

  tx-service-group: my_test_tx_group

  enable-auto-data-source-proxy: true

  client:

    rm:

      async-commit-buffer-limit: 10000

      lock:

        retry-interval: 10

        retry-times: 30

        retry-policy-branch-rollback-on-conflict: true

    tm:

      commit-retry-count: 5

      rollback-retry-count: 5

    undo:

      data-validation: true

      log-serialization: jackson

      log-table: undo_log

在业务代码里，我们使用@GlobalTransactional注解来开启全局事务：

@Service

public class OrderService {

    @Autowired

    private OrderRepository orderRepository;

    @Autowired

    private StockService stockService;

    @GlobalTransactional

    public void createOrder(Order order) {

        orderRepository.save(order);

        stockService.decreaseStock(order.getProductId(), order.getQuantity());

    }

}

这里的@GlobalTransactional注解就像是给整个分布式事务场景下了一道 “圣旨”，让所有涉及到的服务都按照统一的事务规则来执行。

总结

分布式事务虽然复杂，但有了 Spring Boot 提供的强大支持，以及像 Seata 这样优秀的框架，我们也能轻松应对。就像掌握了一门高超的魔法，让我们的分布式系统变得更加可靠和强大。希望今天的分享能让大家对 Spring Boot 中的分布式事务有更深入的理解，在开发的道路上一路 “开挂”，解决各种复杂的业务场景。

一、选手登场！🎬

🔵 蓝方：synchronized（老牌选手）

// synchronized：Java自带的语法糖

public synchronized void method() {

    // 临界区代码

}



// 或者

public void method() {

    synchronized(this) {

        // 临界区代码

    }

}

特点：

• 📜 JDK 1.0就有了，资历老


• 🎯 简单粗暴，写法简单


• 🤖 JVM级别实现，自动释放


• 💰 免费午餐，不需要手动管理

🔴 红方：ReentrantLock（新锐选手）

// ReentrantLock：JDK 1.5引入

ReentrantLock lock = new ReentrantLock();



public void method() {

    lock.lock();  // 手动加锁

    try {

        // 临界区代码

    } finally {

        lock.unlock();  // 必须手动释放！

    }

}

特点：

• 🆕 JDK 1.5新秀，年轻有活力


• 🎨 功能丰富，花样多


• 🏗️ API级别实现，灵活强大


• ⚠️ 需要手动管理，容易忘记释放

二、底层实现对决 💻

Round 1: synchronized的底层实现

1️⃣ 对象头结构（Mark Word）

Java对象内存布局：

┌────────────────────────────────────┐

│        对象头 (Object Header)       │

│  ┌─────────────────────────────┐   │

│  │   Mark Word (8字节)          │ ← 存储锁信息

│  ├─────────────────────────────┤   │

│  │   类型指针 (4/8字节)         │   │

│  └─────────────────────────────┘   │

├────────────────────────────────────┤

│        实例数据 (Instance Data)     │

├────────────────────────────────────┤

│        对齐填充 (Padding)           │

└────────────────────────────────────┘

Mark Word在不同锁状态下的变化：

64位虚拟机的Mark Word（8字节=64位）



┌──────────────────────────────────────────────────┐

│  无锁状态 (001)                                   │

│  ┌────────────┬─────┬──┬──┬──┐                   │

│  │  hashcode  │ age │0 │01│   未锁定              │

│  └────────────┴─────┴──┴──┴──┘                   │

├──────────────────────────────────────────────────┤

│  偏向锁 (101)                                     │

│  ┌────────────┬─────┬──┬──┬──┐                   │

│  │  线程ID    │epoch│1 │01│   偏向锁              │

│  └────────────┴─────┴──┴──┴──┘                   │

├──────────────────────────────────────────────────┤

│  轻量级锁 (00)                                    │

│  ┌────────────────────────────┬──┐               │

│  │  栈中锁记录指针             │00│  轻量级锁     │

│  └────────────────────────────┴──┘               │

├──────────────────────────────────────────────────┤

│  重量级锁 (10)                                    │

│  ┌────────────────────────────┬──┐               │

│  │  Monitor对象指针            │10│  重量级锁     │

│  └────────────────────────────┴──┘               │

└──────────────────────────────────────────────────┘

2️⃣ 锁升级过程（重点！）

                    锁升级路径

                    

无锁状态              偏向锁              轻量级锁            重量级锁

  │                   │                   │                   │

  │    第一次访问      │    有竞争         │    竞争激烈       │

  ├──────────────→   ├──────────────→   ├──────────────→   │

  │                   │                   │                   │

  │                   │    CAS失败        │    自旋失败       │

  │                   │                   │                   │

  

  🚶 一个人         🚶 还是一个人       🚶🚶 两个人        🚶🚶🚶 一群人

   走路             (偏向这个人)        抢着走             排队走

详细解释：

阶段1：无锁 → 偏向锁

// 第一次有线程访问synchronized块

Thread-1第一次进入：

1. 对象处于无锁状态

2. Thread-1通过CAS在Mark Word中记录自己的线程ID

3. 成功！升级为偏向锁，偏向Thread-1

4. 下次Thread-1再来，发现Mark Word里是自己的ID，直接进入！

   （就像VIP通道，不用检查）✨



生活比喻：

你第一次去常去的咖啡店☕，店员记住了你的脸。

下次你来，店员一看是你，直接给你做你的老口味，不用问！

阶段2：偏向锁 → 轻量级锁

Thread-2也想进入：

1. 发现偏向锁偏向的是Thread-1

2. Thread-1已经退出了，撤销偏向锁

3. 升级为轻量级锁

4. Thread-2通过CAS在栈帧中创建Lock Record

5. CAS将对象头的Mark Word复制到Lock Record

6. CAS将对象头指向Lock Record

7. 成功！获取轻量级锁 🎉



生活比喻：

咖啡店来了第二个客人，店员发现需要排队系统了。

拿出号码牌，谁先抢到谁先点单（自旋CAS）🎫

阶段3：轻量级锁 → 重量级锁

Thread-3、Thread-4、Thread-5也来了：

1. 多个线程竞争，CAS自旋失败

2. 自旋一定次数后，升级为重量级锁

3. 没抢到的线程进入阻塞队列

4. 需要操作系统介入，线程挂起（park）😴



生活比喻：

咖啡店人太多了！需要叫号系统 + 座位等待区。

没叫到号的人坐下来等，不用一直站着抢（操作系统介入）🪑

3️⃣ 字节码层面

public synchronized void method() {

    System.out.println("hello");

}

字节码：

public synchronized void method();

  descriptor: ()V

  flags: ACC_PUBLIC, ACC_SYNCHRONIZED  ← 看这里！方法标记

  Code:

    stack=2, locals=1, args_size=1

       0: getstatic     #2

       3: ldc           #3

       5: invokevirtual #4

       8: return

同步块字节码：

public void method() {

    synchronized(this) {

        System.out.println("hello");

    }

}

public void method();

  Code:

     0: aload_0

     1: dup

     2: astore_1

     3: monitorenter      ← 进入monitor

     4: getstatic     #2

     7: ldc           #3

     9: invokevirtual #4

    12: aload_1

    13: monitorexit       ← 退出monitor

    14: goto          22

    17: astore_2

    18: aload_1

    19: monitorexit       ← 异常时也要退出

    20: aload_2

    21: athrow

    22: return

Round 2: ReentrantLock的底层实现

基于AQS（AbstractQueuedSynchronizer）实现：

// ReentrantLock内部

public class ReentrantLock {

    private final Sync sync;

    

    // 抽象同步器

    abstract static class Sync extends AbstractQueuedSynchronizer {

        // ...

    }

    

    // 非公平锁实现

    static final class NonfairSync extends Sync {

        final void lock() {

            // 先CAS抢一次

            if (compareAndSetState(0, 1))

                setExclusiveOwnerThread(Thread.currentThread());

            else

                acquire(1);  // 进入AQS队列

        }

    }

    

    // 公平锁实现  

    static final class FairSync extends Sync {

        final void lock() {

            acquire(1);  // 直接排队，不插队

        }

    }

}

数据结构：

ReentrantLock

    │

    ├─ Sync (继承AQS)

    │    ├─ state: int (0=未锁，>0=重入次数)

    │    └─ exclusiveOwnerThread: Thread (持锁线程)

    │

    └─ CLH队列

         Head → Node1 → Node2 → Tail

                 ↓       ↓

              Thread2  Thread3

              (等待)   (等待)

三、功能对比大战 ⚔️

🏁 功能对比表

🎯 详细功能对比

1️⃣ 可中断锁

// ❌ synchronized不可中断

Thread t = new Thread(() -> {

    synchronized(lock) {

        // 即使调用t.interrupt()，这里也不会响应

        while(true) {

            // 死循环

        }

    }

});



// ✅ ReentrantLock可中断

Thread t = new Thread(() -> {

    try {

        lock.lockInterruptibly();  // 可响应中断

        // ...

    } catch (InterruptedException e) {

        System.out.println("被中断了！");

    }

});

t.start();

Thread.sleep(100);

t.interrupt();  // 可以中断！

2️⃣ 尝试加锁

// ❌ synchronized没有tryLock

synchronized(lock) {

    // 要么拿到锁，要么一直等

}



// ✅ ReentrantLock可以尝试

if (lock.tryLock()) {  // 尝试获取，不阻塞

    try {

        // 拿到锁了

    } finally {

        lock.unlock();

    }

} else {

    // 没拿到，去做别的事

    System.out.println("锁被占用，我去干别的");

}



// ✅ 还支持超时

if (lock.tryLock(3, TimeUnit.SECONDS)) {  // 等3秒

    try {

        // 拿到了

    } finally {

        lock.unlock();

    }

} else {

    // 3秒还没拿到，放弃

    System.out.println("等太久了，不等了");

}

3️⃣ 公平锁

// ❌ synchronized只能是非公平锁

synchronized(lock) {

    // 后来的线程可能插队

}



// ✅ ReentrantLock可选公平/非公平

ReentrantLock fairLock = new ReentrantLock(true);  // 公平锁

ReentrantLock unfairLock = new ReentrantLock(false);  // 非公平锁（默认）

公平锁 vs 非公平锁：

非公平锁（吞吐量高）：

Thread-1持锁 → Thread-2排队 → Thread-3排队

         ↓

    释放锁！

         ↓

Thread-4刚好来了，直接抢！（插队）✂️

虽然Thread-2先来，但Thread-4先抢到



公平锁（先来后到）：

Thread-1持锁 → Thread-2排队 → Thread-3排队

         ↓

    释放锁！

         ↓

Thread-4来了，但要排队到最后！

Thread-2先到先得 ✅

4️⃣ 多个条件变量

// ❌ synchronized只有一个等待队列

synchronized(lock) {

    lock.wait();    // 只有一个等待队列

    lock.notify();  // 随机唤醒一个

}



// ✅ ReentrantLock可以有多个Condition

ReentrantLock lock = new ReentrantLock();

Condition notFull = lock.newCondition();   // 条件1：未满

Condition notEmpty = lock.newCondition();  // 条件2：非空



// 生产者

lock.lock();

try {

    while (queue.isFull()) {

        notFull.await();  // 等待"未满"条件

    }

    queue.add(item);

    notEmpty.signal();  // 唤醒"非空"条件的线程

} finally {

    lock.unlock();

}



// 消费者

lock.lock();

try {

    while (queue.isEmpty()) {

        notEmpty.await();  // 等待"非空"条件

    }

    queue.remove();

    notFull.signal();  // 唤醒"未满"条件的线程

} finally {

    lock.unlock();

}

四、性能对决 🏎️

JDK 1.5时代：ReentrantLock完胜

JDK 1.5性能测试（100万次加锁）：

synchronized:   2850ms  😓

ReentrantLock:  1200ms  🚀



ReentrantLock快2倍多！

JDK 1.6之后：synchronized反击！

JDK 1.6对synchronized做了大量优化：

• ✅ 偏向锁（Biased Locking）


• ✅ 轻量级锁（Lightweight Locking）


• ✅ 自适应自旋（Adaptive Spinning）


• ✅ 锁粗化（Lock Coarsening）


• ✅ 锁消除（Lock Elimination）

JDK 1.8性能测试（100万次加锁）：

synchronized:   1250ms  🚀

ReentrantLock:  1200ms  🚀



几乎一样了！

优化技术解析

1️⃣ 偏向锁

// 同一个线程反复进入

for (int i = 0; i < 1000000; i++) {

    synchronized(obj) {

        // 偏向锁：第一次CAS，后续直接进入

        // 性能接近无锁！✨

    }

}

2️⃣ 锁消除

public String concat(String s1, String s2) {

    // StringBuffer是线程安全的，有synchronized

    StringBuffer sb = new StringBuffer();

    sb.append(s1);

    sb.append(s2);

    return sb.toString();

}



// JVM发现sb是局部变量，不可能有竞争

// 自动消除StringBuffer内部的synchronized！

// 性能大幅提升！🚀

3️⃣ 锁粗化

// ❌ 原代码：频繁加锁解锁

for (int i = 0; i < 1000; i++) {

    synchronized(obj) {

        // 很短的操作

    }

}



// ✅ JVM优化后：锁粗化

synchronized(obj) {  // 把锁提到循环外

    for (int i = 0; i < 1000; i++) {

        // 很短的操作

    }

}

五、使用场景推荐 📝

优先使用synchronized的场景

1️⃣ 简单的同步场景

// 简单的计数器

private int count = 0;



public synchronized void increment() {

    count++;

}

2️⃣ 方法级别的同步

public synchronized void method() {

    // 整个方法同步，简单明了

}

3️⃣ 不需要高级功能

// 只需要基本的互斥，不需要tryLock、Condition等

synchronized(lock) {

    // 业务代码

}

优先使用ReentrantLock的场景

1️⃣ 需要可中断的锁

// 可以响应中断，避免死锁

lock.lockInterruptibly();

2️⃣ 需要尝试加锁

// 拿不到锁就去做别的事

if (lock.tryLock()) {

    // ...

}

3️⃣ 需要公平锁

// 严格按照先来后到

ReentrantLock fairLock = new ReentrantLock(true);

4️⃣ 需要多个条件变量

// 生产者-消费者模式

Condition notFull = lock.newCondition();

Condition notEmpty = lock.newCondition();

5️⃣ 需要获取锁的信息

// 查看等待的线程数

int waiting = lock.getQueueLength();

// 查看是否有线程在等待

boolean hasWaiters = lock.hasQueuedThreads();

六、常见坑点 ⚠️

坑1：ReentrantLock忘记unlock

// ❌ 危险！如果中间抛异常，永远不会释放锁

lock.lock();

doSomething();  // 可能抛异常

lock.unlock();  // 不会执行！💣



// ✅ 正确写法

lock.lock();

try {

    doSomething();

} finally {

    lock.unlock();  // 一定会执行

}

坑2：synchronized锁错对象

// ❌ 每次都是新对象，不起作用！

public void method() {

    synchronized(new Object()) {  // 💣 错误！

        // 相当于没加锁

    }

}



// ✅ 正确写法

private final Object lock = new Object();

public void method() {

    synchronized(lock) {

        // ...

    }

}

坑3：锁的粒度太大

// ❌ 锁的范围太大，性能差

public synchronized void method() {  // 整个方法都锁住

    doA();  // 不需要同步

    doB();  // 需要同步

    doC();  // 不需要同步

}



// ✅ 缩小锁范围

public void method() {

    doA();

    synchronized(lock) {

        doB();  // 只锁需要的部分

    }

    doC();

}

七、面试应答模板 🎤

面试官：synchronized和ReentrantLock有什么区别？

你的回答：

主要从实现层面和功能层面两个角度对比：

实现层面：

功能层面，ReentrantLock更强大：

性能对比：

• JDK 1.6之前ReentrantLock性能更好


• JDK 1.6之后synchronized做了大量优化（偏向锁、轻量级锁、锁消除、锁粗化），性能差不多


• synchronized优化包括：无锁→偏向锁→轻量级锁→重量级锁的升级路径

使用建议：

• 简单场景优先synchronized（代码简洁，自动释放）


• 需要高级功能时用ReentrantLock（可中断、超时、公平锁等）

举个例子：
如果只是简单的计数器，用synchronized即可。但如果是银行转账系统，需要可中断、可超时，就应该用ReentrantLock。

八、总结 🎯

选择决策树：

                   需要同步？

                      │

                     Yes

                      │

        ┌─────────────┴─────────────┐

        │                           │

    简单场景                    复杂场景

 (计数器、缓存等)          (可中断、超时等)

        │                           │

   synchronized                ReentrantLock

        │                           │

    ✅ 简单                      ✅ 功能强

    ✅ 自动释放                  ⚠️ 需手动

    ✅ 性能好                    ✅ 灵活

记忆口诀：

简单场景synchronized，

复杂需求ReentrantLock，

性能现在差不多，

根据场景来选择！🎵

最后一句话：

synchronized是"自动挡"🚗，简单好用；

ReentrantLock是"手动挡"🏎️，灵活强大！

消息队列和事件驱动架构不仅是实现流量削峰的关键技术，它们之间更是一种相辅相成、紧密协作的关系。下面这个表格可以帮您快速把握它们的核心联系与分工。

🔌 消息队列：流量削峰的实现工具

消息队列在流量削峰中扮演着“缓冲区”或“蓄水池”的关键角色 。其工作流程如下：

一个典型的例子是秒杀系统​ 。在短时间内涌入的海量下单请求会被放入消息队列。队列的长度可以起到限制并发数量的作用，超出系统容量的请求可以被快速拒绝，从而保护下游的订单、库存等核心服务不被冲垮，实现削峰填谷 。

🏗️ 事件驱动：流量削峰的指导架构

事件驱动架构是一种从更高层面设计系统交互模式的思想 。当某个重要的状态变化发生时（例如用户下单、订单支付成功），系统会发布一个事件​ 。其他关心此变化的服务会订阅这些事件，并触发相应的后续操作 。这种“发布-订阅”模式天然就是异步的。

在流量削峰的场景下，事件驱动架构的意义在于：

• ​设计上的解耦​：它将“触发动作的服务”和“执行动作的服务”从时间和空间上分离开。下单服务完成核心逻辑后，只需发布一个“订单已创建”的事件，而不需要同步调用库存服务、积分服务等。这本身就为引入消息队列作为事件总线来缓冲流量奠定了基础 。


• ​结果的可达性​：即使某个服务（如积分服务）处理速度较慢，也不会影响核心链路（如扣减库存）。事件会在消息队列中排队，等待积分服务按自己的能力处理，从而实现了服务间的流量隔离和削峰 。

🤝 协同工作场景

消息队列与事件驱动架构协同工作的场景包括：

• ​异步任务处理​：用户注册后，需要发送邮件和短信。注册服务完成核心逻辑后，发布一个“用户已注册”事件到消息队列。邮件服务和短信服务作为订阅者，异步消费该事件，实现异步处理 。


• ​系统应用解耦​：订单系统与库存系统之间通过消息队列解耦。订单系统下单后，将消息写入消息队列即可返回成功，库存系统再根据消息队列中的信息进行库存操作，即使库存系统暂时不可用，也不会影响下单 。


• ​日志处理与实时监控​：使用类似Kafka的消息队列收集应用日志，后续的日志分析、监控报警等服务订阅这些日志流进行处理，解决大量日志传输问题 。

💡 选型与注意事项

在选择和运用这些技术时，需要注意：

• ​技术选型​：不同消息队列有不同特点。​RabbitMQ​ 以消息可靠性见长；Apache Kafka​ 专为高吞吐量的实时日志流和数据管道设计，尤其适合日志处理等场景 ；RocketMQ​ 在阿里内部经历了大规模交易场景的考验 。


• ​潜在挑战​：
  
  
  
  
  • ​复杂性增加​：需要维护消息中间件，并处理可能出现的消息重复、丢失、乱序等问题 。
  
  
  • ​数据一致性​：异步化带来了最终一致性，需要考虑业务是否能接受 。
  
  
  • ​系统延迟​：请求需要排队处理，用户得到最终结果的时间会变长，不适合所有场景。
  
  
  
  

异同分析

Consumer 和 Supplier 是 Java 8 引入的两个重要函数式接口，位于 java.util.function 包中，用于支持函数式编程范式。

相同点

不同点

详细分析与使用场景

Consumer 接口

Consumer 表示接受单个输入参数但不返回结果的操作。

import java.util.function.Consumer;

import java.util.Arrays;

import java.util.List;



public class ConsumerExample {

    public static void main(String[] args) {

        // 基本用法

        Consumer<String> printConsumer = s -> System.out.println(s);

        printConsumer.accept("Hello Consumer!");

        

        // 方法引用方式

        Consumer<String> methodRefConsumer = System.out::println;

        methodRefConsumer.accept("Hello Method Reference!");

        

        // 集合遍历中的应用

        List<String> names = Arrays.asList("Alice", "Bob", "Charlie");

        names.forEach(printConsumer);

        

        // andThen 方法组合多个 Consumer

        Consumer<String> upperCaseConsumer = s -> System.out.println(s.toUpperCase());

        Consumer<String> decoratedConsumer = s -> System.out.println("*** " + s + " ***");

        

        Consumer<String> combinedConsumer = upperCaseConsumer.andThen(decoratedConsumer);

        combinedConsumer.accept("functional interface");

        

        // 在 Optional 中的使用

        java.util.Optional<String> optional = java.util.Optional.of("Present");

        optional.ifPresent(combinedConsumer);

    }

}

Consumer 的使用场景：

Supplier 接口

Supplier 表示一个供应商，不需要传入参数但返回一个值。

import java.util.function.Supplier;

import java.util.List;

import java.util.Random;

import java.util.stream.Stream;



public class SupplierExample {

    public static void main(String[] args) {

        // 基本用法

        Supplier<String> stringSupplier = () -> "Hello from Supplier!";

        System.out.println(stringSupplier.get());

        

        // 方法引用方式

        Supplier<Double> randomSupplier = Math::random;

        System.out.println("Random number: " + randomSupplier.get());

        

        // 对象工厂

        Supplier<List<String>> listSupplier = () -> java.util.Arrays.asList("A", "B", "C");

        System.out.println("List from supplier: " + listSupplier.get());

        

        // 延迟计算/初始化

        Supplier<ExpensiveObject> expensiveObjectSupplier = () -> {

            System.out.println("Creating expensive object...");

            return new ExpensiveObject();

        };

        

        System.out.println("Supplier created but no object yet...");

        // 只有在调用 get() 时才会创建对象

        ExpensiveObject obj = expensiveObjectSupplier.get();

        

        // 在 Stream 中生成无限流

        Supplier<Integer> randomIntSupplier = () -> new Random().nextInt(100);

        Stream.generate(randomIntSupplier)

              .limit(5)

              .forEach(System.out::println);

              

        // 在 Optional 中作为备选值

        java.util.Optional<String> emptyOptional = java.util.Optional.empty();

        String value = emptyOptional.orElseGet(() -> "Default from supplier");

        System.out.println("Value from empty optional: " + value);

    }

    

    static class ExpensiveObject {

        ExpensiveObject() {

            // 模拟耗时操作

            try { Thread.sleep(1000); } catch (InterruptedException e) {}

        }

    }

}

Supplier 的使用场景：

实际应用示例

下面是一个结合使用 Consumer 和 Supplier 的示例：

import java.util.function.Consumer;

import java.util.function.Supplier;

import java.util.logging.Logger;



public class CombinedExample {

    private static final Logger logger = Logger.getLogger(CombinedExample.class.getName());

    

    public static void main(String[] args) {

        // 创建一个数据处理器，结合了 Supplier 和 Consumer

        processData(

            () -> { // Supplier - 提供数据

                // 模拟从数据库或API获取数据

                return new String[] {"Data1", "Data2", "Data3"};

            },

            data -> { // Consumer - 处理数据

                for (String item : data) {

                    System.out.println("Processing: " + item);

                }

            },

            error -> { // Consumer - 错误处理

                logger.severe("Error occurred: " + error.getMessage());

            }

        );

    }

    

    public static <T> void processData(Supplier<T> dataSupplier, 

                                      Consumer<T> dataProcessor, 

                                      Consumer<Exception> errorHandler) {

        try {

            T data = dataSupplier.get(); // 从Supplier获取数据

            dataProcessor.accept(data);  // 用Consumer处理数据

        } catch (Exception e) {

            errorHandler.accept(e);      // 用Consumer处理错误

        }

    }

}