什么是联合索引？

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

• 单列索引：只针对一个表列创建的索引。例如，为 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处理错误

        }

    }

}

总结

• Consumer 用于表示接受输入并执行操作但不返回结果的函数，常见于需要处理数据并产生副作用的场景


• Supplier 用于表示无需输入但返回结果的函数，常见于延迟计算、提供数据和工厂模式场景


• 两者都是函数式编程中的重要构建块，可以组合使用创建灵活的数据处理管道


• 在 Stream API、Optional 和现代 Java 框架中广泛应用

理解这两个接口的差异和适用场景有助于编写更简洁、更表达力的 Java 代码，特别是在使用 Stream API 和函数式编程范式时。

缓存是性能优化的利器，但如何保证线程安全、支持过期、防止内存泄漏？让我们从零开始，打造一个生产级缓存！

一、开场：缓存的核心需求🎯

基础需求

生活类比：

缓存像冰箱🧊：

• 存储食物（数据）


• 定期检查过期（过期策略）


• 空间有限（容量限制）


• 多人使用（线程安全）

二、版本1：基础线程安全缓存

public class SimpleCache<K, V> {

    

    private final ConcurrentHashMap<K, CacheEntry<V>> cache = 

        new ConcurrentHashMap<>();

    

    // 缓存项

    static class CacheEntry<V> {

        final V value;

        final long expireTime; // 过期时间戳

        

        CacheEntry(V value, long ttl) {

            this.value = value;

            this.expireTime = System.currentTimeMillis() + ttl;

        }

        

        boolean isExpired() {

            return System.currentTimeMillis() > expireTime;

        }

    }

    

    /**

     * 存入缓存

     */

    public void put(K key, V value, long ttlMillis) {

        cache.put(key, new CacheEntry<>(value, ttlMillis));

    }

    

    /**

     * 获取缓存

     */

    public V get(K key) {

        CacheEntry<V> entry = cache.get(key);

        

        if (entry == null) {

            return null;

        }

        

        // 检查是否过期

        if (entry.isExpired()) {

            cache.remove(key); // 惰性删除

            return null;

        }

        

        return entry.value;

    }

    

    /**

     * 删除缓存

     */

    public void remove(K key) {

        cache.remove(key);

    }

    

    /**

     * 清空缓存

     */

    public void clear() {

        cache.clear();

    }

    

    /**

     * 缓存大小

     */

    public int size() {

        return cache.size();

    }

}

使用示例：

SimpleCache<String, User> cache = new SimpleCache<>();



// 存入缓存，5秒过期

cache.put("user:1", new User("张三"), 5000);



// 获取缓存

User user = cache.get("user:1"); // 5秒内返回User对象



Thread.sleep(6000);



User expired = cache.get("user:1"); // 返回null（已过期）

问题：

• ❌ 过期数据需要访问时才删除（惰性删除）


• ❌ 没有容量限制，可能OOM


• ❌ 没有定时清理，内存泄漏

三、版本2：支持定时清理🔧

public class CacheWithCleanup<K, V> {

    

    private final ConcurrentHashMap<K, CacheEntry<V>> cache = 

        new ConcurrentHashMap<>();

    

    private final ScheduledExecutorService cleanupExecutor;

    

    static class CacheEntry<V> {

        final V value;

        final long expireTime;

        

        CacheEntry(V value, long ttl) {

            this.value = value;

            this.expireTime = System.currentTimeMillis() + ttl;

        }

        

        boolean isExpired() {

            return System.currentTimeMillis() > expireTime;

        }

    }

    

    public CacheWithCleanup() {

        this.cleanupExecutor = Executors.newSingleThreadScheduledExecutor(

            new ThreadFactoryBuilder()

                .setNameFormat("cache-cleanup-%d")

                .setDaemon(true)

                .build()

        );

        

        // 每秒清理一次过期数据

        cleanupExecutor.scheduleAtFixedRate(

            this::cleanup, 

            1, 1, TimeUnit.SECONDS

        );

    }

    

    public void put(K key, V value, long ttlMillis) {

        cache.put(key, new CacheEntry<>(value, ttlMillis));

    }

    

    public V get(K key) {

        CacheEntry<V> entry = cache.get(key);

        

        if (entry == null || entry.isExpired()) {

            cache.remove(key);

            return null;

        }

        

        return entry.value;

    }

    

    /**

     * 定时清理过期数据

     */

    private void cleanup() {

        cache.entrySet().removeIf(entry -> entry.getValue().isExpired());

    }

    

    /**

     * 关闭缓存

     */

    public void shutdown() {

        cleanupExecutor.shutdown();

        cache.clear();

    }

}

改进：

• ✅ 定时清理过期数据


• ✅ 不依赖访问触发删除

问题：

• ❌ 还是没有容量限制


• ❌ 没有LRU淘汰策略

四、版本3：完整的缓存实现（LRU+过期）⭐

import java.util.concurrent.*;

import java.util.concurrent.atomic.AtomicInteger;



public class AdvancedCache<K, V> {

    

    // 缓存容量

    private final int maxSize;

    

    // 存储：ConcurrentHashMap + LinkedHashMap（LRU）

    private final ConcurrentHashMap<K, CacheEntry<V>> cache;

    

    // 定时清理线程

    private final ScheduledExecutorService cleanupExecutor;

    

    // 统计信息

    private final AtomicInteger hitCount = new AtomicInteger(0);

    private final AtomicInteger missCount = new AtomicInteger(0);

    

    // 缓存项

    static class CacheEntry<V> {

        final V value;

        final long expireTime;

        volatile long lastAccessTime; // 最后访问时间

        

        CacheEntry(V value, long ttl) {

            this.value = value;

            this.expireTime = System.currentTimeMillis() + ttl;

            this.lastAccessTime = System.currentTimeMillis();

        }

        

        boolean isExpired() {

            return System.currentTimeMillis() > expireTime;

        }

        

        void updateAccessTime() {

            this.lastAccessTime = System.currentTimeMillis();

        }

    }

    

    public AdvancedCache(int maxSize) {

        this.maxSize = maxSize;

        this.cache = new ConcurrentHashMap<>(maxSize);

        

        this.cleanupExecutor = Executors.newSingleThreadScheduledExecutor(

            new ThreadFactoryBuilder()

                .setNameFormat("cache-cleanup-%d")

                .setDaemon(true)

                .build()

        );

        

        // 每秒清理过期数据

        cleanupExecutor.scheduleAtFixedRate(

            this::cleanup, 

            1, 1, TimeUnit.SECONDS

        );

    }

    

    /**

     * 存入缓存

     */

    public void put(K key, V value, long ttlMillis) {

        // 检查容量

        if (cache.size() >= maxSize) {

            evictLRU(); // LRU淘汰

        }

        

        cache.put(key, new CacheEntry<>(value, ttlMillis));

    }

    

    /**

     * 获取缓存

     */

    public V get(K key) {

        CacheEntry<V> entry = cache.get(key);

        

        if (entry == null) {

            missCount.incrementAndGet();

            return null;

        }

        

        // 检查过期

        if (entry.isExpired()) {

            cache.remove(key);

            missCount.incrementAndGet();

            return null;

        }

        

        // 更新访问时间

        entry.updateAccessTime();

        hitCount.incrementAndGet();

        

        return entry.value;

    }

    

    /**

     * 带回调的获取（类似Guava Cache）

     */

    public V get(K key, Callable<V> loader, long ttlMillis) {

        CacheEntry<V> entry = cache.get(key);

        

        // 缓存命中且未过期

        if (entry != null && !entry.isExpired()) {

            entry.updateAccessTime();

            hitCount.incrementAndGet();

            return entry.value;

        }

        

        // 缓存未命中，加载数据

        try {

            V value = loader.call();

            put(key, value, ttlMillis);

            return value;

        } catch (Exception e) {

            throw new RuntimeException("加载数据失败", e);

        }

    }

    

    /**

     * LRU淘汰：移除最久未访问的

     */

    private void evictLRU() {

        K lruKey = null;

        long oldestAccessTime = Long.MAX_VALUE;

        

        // 找出最久未访问的key

        for (Map.Entry<K, CacheEntry<V>> entry : cache.entrySet()) {

            long accessTime = entry.getValue().lastAccessTime;

            if (accessTime < oldestAccessTime) {

                oldestAccessTime = accessTime;

                lruKey = entry.getKey();

            }

        }

        

        if (lruKey != null) {

            cache.remove(lruKey);

        }

    }

    

    /**

     * 定时清理过期数据

     */

    private void cleanup() {

        cache.entrySet().removeIf(entry -> entry.getValue().isExpired());

    }

    

    /**

     * 获取缓存命中率

     */

    public double getHitRate() {

        int total = hitCount.get() + missCount.get();

        return total == 0 ? 0 : (double) hitCount.get() / total;

    }

    

    /**

     * 获取统计信息

     */

    public String getStats() {

        return String.format(

            "缓存统计: 大小=%d, 命中=%d, 未命中=%d, 命中率=%.2f%%",

            cache.size(),

            hitCount.get(),

            missCount.get(),

            getHitRate() * 100

        );

    }

    

    /**

     * 关闭缓存

     */

    public void shutdown() {

        cleanupExecutor.shutdown();

        cache.clear();

    }

}

五、完整使用示例📝

public class CacheExample {

    

    public static void main(String[] args) throws InterruptedException {

        

        // 创建缓存：最大100个，5秒过期

        AdvancedCache<String, User> cache = new AdvancedCache<>(100);

        

        // 1. 基本使用

        cache.put("user:1", new User("张三", 20), 5000);

        User user = cache.get("user:1");

        System.out.println("获取缓存: " + user);

        

        // 2. 带回调的获取（自动加载）

        User user2 = cache.get("user:2", () -> {

            // 模拟从数据库加载

            System.out.println("从数据库加载 user:2");

            return new User("李四", 25);

        }, 5000);

        System.out.println("加载数据: " + user2);

        

        // 3. 再次获取（命中缓存）

        User cached = cache.get("user:2");

        System.out.println("命中缓存: " + cached);

        

        // 4. 等待过期

        Thread.sleep(6000);

        User expired = cache.get("user:1");

        System.out.println("过期数据: " + expired); // null

        

        // 5. 查看统计

        System.out.println(cache.getStats());

        

        // 6. 关闭缓存

        cache.shutdown();

    }

}

输出：

获取缓存: User{name='张三', age=20}

从数据库加载 user:2

加载数据: User{name='李四', age=25}

命中缓存: User{name='李四', age=25}

过期数据: null

缓存统计: 大小=1, 命中=2, 未命中=1, 命中率=66.67%

六、实战：用户Session缓存🔐

public class SessionCache {

    

    private final AdvancedCache<String, UserSession> cache;

    

    public SessionCache() {

        this.cache = new AdvancedCache<>(10000); // 最大1万个session

    }

    

    /**

     * 创建Session

     */

    public String createSession(Long userId) {

        String sessionId = UUID.randomUUID().toString();

        UserSession session = new UserSession(userId, LocalDateTime.now());

        

        // 30分钟过期

        cache.put(sessionId, session, 30 * 60 * 1000);

        

        return sessionId;

    }

    

    /**

     * 获取Session

     */

    public UserSession getSession(String sessionId) {

        return cache.get(sessionId);

    }

    

    /**

     * 刷新Session（延长过期时间）

     */

    public void refreshSession(String sessionId) {

        UserSession session = cache.get(sessionId);

        if (session != null) {

            // 重新设置30分钟过期

            cache.put(sessionId, session, 30 * 60 * 1000);

        }

    }

    

    /**

     * 删除Session（登出）

     */

    public void removeSession(String sessionId) {

        cache.remove(sessionId);

    }

    

    static class UserSession {

        final Long userId;

        final LocalDateTime createTime;

        

        UserSession(Long userId, LocalDateTime createTime) {

            this.userId = userId;

            this.createTime = createTime;

        }

    }

}

七、与Guava Cache对比📊

Guava Cache的使用

LoadingCache<String, User> cache = CacheBuilder.newBuilder()

    .maximumSize(1000)               // 最大容量

    .expireAfterWrite(5, TimeUnit.MINUTES) // 写入后过期

    .expireAfterAccess(10, TimeUnit.MINUTES) // 访问后过期

    .recordStats()                   // 记录统计

    .build(new CacheLoader<String, User>() {

        @Override

        public User load(String key) throws Exception {

            return loadUserFromDB(key); // 加载数据

        }

    });



// 使用

User user = cache.get("user:1"); // 自动加载

功能对比

建议：

• 简单场景：自定义实现


• 生产环境：用Guava Cache或Caffeine

八、性能优化技巧⚡

技巧1：分段锁

public class SegmentedCache<K, V> {

    

    private final int segments = 16;

    private final AdvancedCache<K, V>[] caches;

    

    @SuppressWarnings("unchecked")

    public SegmentedCache(int totalSize) {

        this.caches = new AdvancedCache[segments];

        int sizePerSegment = totalSize / segments;

        

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

            caches[i] = new AdvancedCache<>(sizePerSegment);

        }

    }

    

    private AdvancedCache<K, V> getCache(K key) {

        int hash = key.hashCode();

        int index = (hash & Integer.MAX_VALUE) % segments;

        return caches[index];

    }

    

    public void put(K key, V value, long ttl) {

        getCache(key).put(key, value, ttl);

    }

    

    public V get(K key) {

        return getCache(key).get(key);

    }

}

技巧2：异步加载

public class AsyncCache<K, V> {

    

    private final AdvancedCache<K, CompletableFuture<V>> cache;

    private final ExecutorService loadExecutor;

    

    public CompletableFuture<V> get(K key, Callable<V> loader, long ttl) {

        return cache.get(key, () -> 

            CompletableFuture.supplyAsync(() -> {

                try {

                    return loader.call();

                } catch (Exception e) {

                    throw new CompletionException(e);

                }

            }, loadExecutor),

            ttl

        );

    }

}

九、常见陷阱⚠️

陷阱1：缓存穿透

// ❌ 错误：不存在的key反复查询数据库

public User getUser(String userId) {

    User user = cache.get(userId);

    if (user == null) {

        user = loadFromDB(userId); // 每次都查数据库

        if (user != null) {

            cache.put(userId, user, 5000);

        }

    }

    return user;

}



// ✅ 正确：缓存空对象

public User getUser(String userId) {

    User user = cache.get(userId);

    if (user == null) {

        user = loadFromDB(userId);

        // 即使是null也缓存，但设置短过期时间

        cache.put(userId, user != null ? user : NULL_USER, 1000);

    }

    return user == NULL_USER ? null : user;

}

陷阱2：缓存雪崩

// ❌ 错误：所有key同时过期

for (String key : keys) {

    cache.put(key, value, 5000); // 5秒后同时过期

}



// ✅ 正确：过期时间随机化

for (String key : keys) {

    long ttl = 5000 + ThreadLocalRandom.current().nextInt(1000);

    cache.put(key, value, ttl); // 5-6秒随机过期

}

十、面试高频问答💯

Q1: 如何保证缓存的线程安全？

A:

• 使用ConcurrentHashMap


• volatile保证可见性


• CAS操作保证原子性

Q2: 如何实现过期淘汰？

A:

• 惰性删除：访问时检查过期


• 定时删除：定时任务扫描


• 两者结合

Q3: 如何实现LRU？

A:

• 记录访问时间


• 容量满时淘汰最久未访问的

Q4: 缓存穿透/击穿/雪崩的区别？

A:

• 穿透：查询不存在的key，缓存和DB都没有


• 击穿：热点key过期，大量请求打到DB


• 雪崩：大量key同时过期

十一、总结🎯

核心要点

生产建议

• 简单场景：自己实现


• 复杂场景：用Guava Cache


• 极致性能：用Caffeine

下期预告： 为什么双重检查锁定（DCL）是错误的？指令重排序的陷阱！🔐

是否好奇过，这样一行代码，编译器背后做了什么？

auto lambda = [](int x) { return x * 2; };

本文将带你深入 Lambda 的底层

一、Lambda回顾

    auto lambda = [](int x) { return x + 1; };

    int result = lambda(5);

lambda我们很熟悉，是一个对象。

完整语法:[捕获列表] (参数列表) mutable 异常说明->返回类型{函数体}

基本的用法就不说，说几个用的时候注意的点

class MyClass {

    int value = 42;

public:

    auto getLambda() {

        return [this]() { return value; };  //捕获 this 指针

    }

};



MyClass* obj = new MyClass();

auto lambda = obj->getLambda();

delete obj;

lambda();  //this 指针悬垂

C++17解决:*this捕获，直接拷贝整个对象

return [*this]() { return value; };  // 拷贝整个对象

3.每个lambda都是唯一的

auto l1 = []() { return 1; };

auto l2 = []() { return 1; };



// l1 和 l2 类型不同！

// typeid(l1) != typeid(l2)

4.转换为函数指针

// 不捕获变量→可以转换

auto l1 = [](int x) { return x + 1; };

int (*fp)(int) = l1;//正确



// 捕获变量→不能转换

int a = 10;

auto l2 = [a](int x) { return a + x; };

int (*fp2)(int) = l2;  //编译错误

记住这句话:函数指针=纯粹的代码地址，你一旦有成员变量，operator()就会依赖对象状态(a)，无法转换为函数指针，函数指针调用时，不知道a的值从哪里来。

简单来说:lambda本质是对象+代码，而函数指针只能表示纯代码

解决方式:function(可以直接存储Lambda对象)

5.混淆了[=] 和 [&]

class MyClass {

    int value = 100;

public:

    void test() {

        auto lambda = [=]() {  //看起来按值捕获

            std::cout << value << std::endl;

        };

        //等价于 [this],捕获的是this指针

        //等价于this->value

    }

};

6.lambda递归

auto factorial = [](int n) {  //无法递归调用自己

    return n <= 1 ? 1 : n * factorial(n - 1);  // 错误:factorial 未定义

};



//正确做法:C++23显式对象参数

auto factorial = [](this auto self, int n) {  // C++23

    return n <= 1 ? 1 : n * self(n - 1);

};

7.移动捕获

void process(std::unique_ptr<int>&& ptr) {

    auto lambda = [p = std::move(ptr)]() {  //移动到 Lambda

        std::cout << *p << std::endl;

    };

    //错误做法

    //auto lambda = [&ptr]() {  //捕获的是引用

    //std::cout << *ptr << std::endl;

    //可能导致ptr移动后lambda失效.

    lambda();

}

二、Lambda 的本质

Lambda不是普通的函数，也不是普通的对象，它是一个重载了operator()的类对象。
现在来证明一下:代码如下

#include <iostream>



int main() {

    auto lambda = [](int x) { return x * 2; };

    int result = lambda(5);

    std::cout << result << std::endl;

    return 0;

}

gdb证明:


观察到lambda是一个结构体，且大小为1字节

引申出几个问题

问题1:为什么这里是一个空的结构体？

我们来按值捕获参数试试:

    int main() {

    int y=2;

    auto lambda = [=](int x) { return x * 2+y * 3; };

    int result = lambda(5);

    std::cout << result << std::endl;

    return 0;

}

gdb:



哦，原来捕获对象会存在这个结构体中，同时我们发现大小为4字节，就为数据的大小。

那我们捕获引用试试呢？



同样也是引用数据类型，但是由于引用底层是存着对象的地址，所以它的大小为8字节，是一个指针的大小。

回到上面，为什么我们一开始的结构体什么数据都没有还是为1字节呢，C++规定了空类大小不为0，最小为1字节（保证每个对象都有唯一的地址）

总结:引用或按值捕获的数据被存在lambda对象内部

问题2：证明他是一个重载了operator()的对象

(1)gdb继续调试:

可以看到,确实是调用了一个operator()

(2)我们在用C++ Insights验证一下

访问：cppinsights.io/
可以查看编译器实际生成的完整类定义

关注到operator()后面是一个const，说明不可以修改捕获的变量,mutable加上后const消失，可自行验证

引言

在实际开发中，很多工程师依然停留在“用 for 循环遍历集合”的思维模式。但在大型项目、复杂业务中，这种写法往往显得冗余、难以扩展，也不符合函数式编程的趋势。

Stream API 的出现，不只是“简化集合遍历”，而是把 声明式编程思想 带入了 Java，使我们能以一种更优雅、更高效、更可扩展的方式处理集合与数据流。

如果你还把 Stream 仅仅理解为 list.stream().map(...).collect(...)，那就大错特错了。本文将从 高级用法、底层原理、业务实践、性能优化 四个维度，带你重新认识 Stream —— 让它真正成为你架构设计和代码表达的利器。

一、为什么要用 Stream？

在真实业务场景中，Stream 的价值不仅仅体现在“更少的代码量”，而在于：

// 传统方式

List<String> result = new ArrayList<>();

for (User u : users) {

    if (u.getAge() > 18) {

        result.add(u.getName());

    }

}



// Stream 写法：表达意图更清晰

List<String> result = users.stream()

                           .filter(u -> u.getAge() > 18)

                           .map(User::getName)

                           .toList();

后者的代码阅读体验更接近“业务规则”，而非“算法步骤”。

• 可扩展性 —— 同样的链式调用，可以无缝切换到 并行流（parallelStream）以提升性能，而无需修改核心逻辑。


• 契合函数式编程趋势 —— 在 Java 8 引入 Lambda 后，Stream 彻底释放了函数式编程的潜力。

二、Stream 的核心思想

Stream API 的设计核心可以用一句话概括：

把数据操作抽象成流水线，每一步都是一个中间操作，最终由终止操作触发执行。

• 数据源（Source） ：集合、数组、I/O、生成器等。


• 中间操作（Intermediate Operations） ：filter、map、flatMap、distinct、sorted …，返回一个新的 Stream（惰性求值）。


• 终止操作（Terminal Operations） ：collect、forEach、reduce、count …，触发实际计算。

关键点：Stream 是惰性的。中间操作不会立即执行，直到遇到终止操作才会真正运行。

三、高级用法与最佳实践

1. 多级分组与统计

真实业务中，常见的场景是“按条件分组统计”。

// 按部门分组，并统计每个部门的人数

Map<String, Long> groupByDept = employees.stream()

    .collect(Collectors.groupingBy(Employee::getDepartment, Collectors.counting()));



// 多级分组：按部门 -> 按职位

Map<String, Map<String, List<Employee>>> group = employees.stream()

    .collect(Collectors.groupingBy(Employee::getDepartment,

             Collectors.groupingBy(Employee::getTitle)));

2. flatMap 的威力

flatMap 可以把多层集合打平成单层流。

// 一个学生对应多个课程，如何获取所有课程的去重列表？

List<String> courses = students.stream()

    .map(Student::getCourses)      // Stream<List<String>>

    .flatMap(List::stream)         // Stream<String>

    .distinct()

    .toList();

3. reduce 高阶聚合

Stream 的 reduce 方法提供了更灵活的聚合方式。

// 求所有订单的总金额

BigDecimal total = orders.stream()

    .map(Order::getAmount)

    .reduce(BigDecimal.ZERO, BigDecimal::add);

相比 Collectors.summingInt 等方法，reduce 更加灵活，适合需要自定义聚合逻辑的场景。

4. 结合 Optional 优雅处理空值

Stream 与 Optional 配合，可以消除 if-null 的丑陋写法。

// 找到第一个满足条件的用户

Optional<User> user = users.stream()

    .filter(u -> u.getAge() > 30)

    .findFirst();

与传统的 null 判断相比，这种写法更安全、更符合函数式语义。

5. 并行流与 ForkJoinPool

只需一行代码，就能让 Stream 自动并行处理

long count = bigList.parallelStream()

                    .filter(item -> isValid(item))

                    .count();

注意点：

• 并行流基于 ForkJoinPool，默认线程数 = CPU 核心数。


• 不适合小数据量，启动线程开销可能大于收益。


• 不适合有共享资源的场景（容易产生锁竞争）。

四、Stream 的底层原理

理解底层机制，才能在性能和架构上做出正确决策。

五、业务场景中的最佳实践

1. 日志分析系统

日志按时间、级别分组统计：

Map<LogLevel, Long> logCount = logs.stream()

    .filter(log -> log.getTimestamp().isAfter(start))

    .collect(Collectors.groupingBy(Log::getLevel, Collectors.counting()));

2. 电商系统订单处理

对订单进行聚合，计算 GMV（成交总额）：

BigDecimal gmv = orders.stream()

    .filter(o -> o.getStatus() == OrderStatus.FINISHED)

    .map(Order::getAmount)

    .reduce(BigDecimal.ZERO, BigDecimal::add);

3. 权限系统多对多关系处理

用户-角色-权限的映射去重：

Set<String> permissions = users.stream()

    .map(User::getRoles)

    .flatMap(List::stream)

    .map(Role::getPermissions)

    .flatMap(List::stream)

    .collect(Collectors.toSet());

六、性能优化与陷阱

List<String> result = new ArrayList<>();

list.stream().forEach(e -> result.add(e)); //违反函数式编程

应该用 collect。

• 适度使用并行流
  
  
  
  
  • 小集合别用并行流。
  
  
  • 线程池可通过 ForkJoinPool.commonPool() 自定义。
  
  
  
  


• 避免链式调用过长
  
  虽然优雅，但可读性会下降，必要时拆分。


• Stream 不是万能的
  
  
  
  
  • 对于简单循环，普通 for 循环更直观。
  
  
  • 对性能敏感的底层操作（如数组拷贝），直接用原生循环更高效。
  
  
  
  

总结

Stream 并不是一个“语法糖”，而是 Java 向函数式编程迈进的重要里程碑。

它让我们能以声明式、可扩展、可并行的方式处理数据流，提升代码表达力和业务抽象能力。

对于中高级开发工程师来说，Stream 的价值在于：

• 提升业务逻辑的可读性和可维护性


• 利用底层并行能力提升性能


• 契合函数式思维，帮助团队写出更现代化的 Java 代码

未来的你，写业务逻辑时，应该少考虑“怎么遍历”，多去思考“我要表达的业务规则是什么”。

在数据通信与网络技术中，信道的“方向性”是一个基础而核心的概念。它定义了信息在通信双方之间流动的方向与方式。根据其特性，我们通常将其归纳为三种基本模式：单工、半双工和全双工。清晰理解这三种模式，是掌握众多通信协议与网络技术的基石。

一、单工通信

单工通信代表了最单一、最直接的数据流向。

• 定义：数据只能在一个方向上传输，通信的一方固定为发送端，另一方则固定为接收端。


• 核心特征：方向不可改变。就像一条单行道，数据流只有一个固定的方向。


• 经典比喻：
  
  
  
  • 广播电台：电台负责发送信号，广大听众的收音机只能接收信号，无法通过收音机向电台发送数据。
  
  
  • 电视信号传输：电视台到家庭电视的信号传输。
  
  
  • 键盘到计算机（在传统概念中）：数据从键盘单向传入计算机。
  
  
  
  

单工通信模式简单、成本低，但交互性为零，无法实现双向信息交流。

二、半双工通信

半双工通信允许了双向交流，但增加了“轮流”的规则。

• 定义：数据可以在两个方向上传输，但在任一时刻，只能有一个方向在进行传输。它需要一种“切换”机制来改变数据传输的方向。


• 核心特征：双向交替，不能同时。


• 经典比喻：
  
  
  
  • 对讲机：一方需要按下“通话键”说话，说完后必须说“完毕”并松开按键，切换到接收状态，才能听到对方的回复。双方不能同时讲话。
  
  
  • 独木桥：同一时间只能允许一个人从一个方向通过。
  
  
  
  

半双工的局限性：
由于其交替通信的本质，半双工存在几个固有缺陷：

三、全双工通信

全双工通信实现了最自然、最高效的双向交互。

• 定义：数据可以在两个方向上同时进行传输。


• 核心特征：同时双向传输。


• 经典比喻：
  
  
  
  • 电话通话：双方可以同时说话和聆听，交流过程自然流畅，无需等待。
  
  
  • 双向多车道公路：两个方向的车流拥有各自独立的车道，可以同时、高速、互不干扰地行驶。
  
  
  
  

技术实现：全双工通常需要两条独立的物理信道（如网线中的两对线），或通过频分复用等技术在一条信道上逻辑地划分出上行和下行通道。其最大优势在于彻底避免了半双工中固有的碰撞问题。

三种模式对比总结

结论

从单工的“只读”模式，到半双工的“轮流对话”，再到全双工的“自由交谈”，通信模式的演进体现了人们对更高效率和更自然交互的不懈追求。全双工凭借其高吞吐量、低延迟和无碰撞的特性，已成为当今主流有线与无线网络（如交换式以太网、4G/5G移动通信）的标配。而半双工和单工则在物联网、传感器网络、广播等特定应用场景中，因其成本或功能需求，依然保有一席之地。理解这三种基础模式，是步入更复杂通信世界的第一步。

TL;DR

场景：要做高并发低延迟 OLAP，且不想上整套 Hadoop/湖仓。
结论：ClickHouse 的核心在列式+向量化+MergeTree+近似统计；适合即席分析与近实时写入，不适合强事务与高频行级更新。
产出：选型决策表 + 分区/排序键速查卡 + 5 条查询模板（安装/集群放到下一章）。

简要概述

ClickHouse 是一个快速开源的OLAP数据库管理系统，它是面向列的，允许使用SQL查询实时生成分析报告。

随着物联网IOT时代的来临，IOT设备感知和报警存储数据越来越大，有用的价值数据需要数据分析师去分析。大数据分析成了非常重要的环节，开源也为大数据分析工程师提供了十分丰富的工具，但这也增加了开发者选择适合的工具的难度，尤其是新入行的开发者来说。

框架的多样化和复杂度成了很大的难题，例如：Kafka、HDFS、Spark、Hive等等组合才能产生最后的分析结果，把各种开源框架、工具、库、平台人工整合到一起所需的工作之复杂，是大数据领域开发和数据分析师常有的抱怨之一，也就是他们支持大数据分析简化和统一化的首要原因。

从业务维度来分析，用户需求会反向促使技术发展。

简要选型

• 需要强事务/OLTP → 不是 CH


• OLAP + 近实时 + 自建机房成本敏感 → CH 优先


• 只做离线、成本不敏感且现有湖仓成熟 → SparkSQL/Trino 也行


• 预计算立方体 + 报表固化 → Druid/Kylin 也可

OLTP

OLTP：Online Transaction Processing：联机事务处理过程。

应用场景

• ERP：Enterprise Resource Planning 企业资源计划


• CRM：Customer Relationship Management 客户关系管理

流程审批、数据录入、填报等

具体特点

线下工作线上化，数据保存在各自的系统中，互不相同（数据孤岛）

OLAP

OLAP：On-Line Analytical Processing：联机分析系统

分析报表、分析决策等。

应用场景

方案1：数仓

如上图所示，数据实时写入HBase，实时的数据更新也在HBase完成，为了应对OLAP需求，我们定时（通常是T+1或者T+H）将HBase数据写成静态的文件（如：Parquet）导入到 OLAP引擎（如HDFS，比较常见的是Impala操作Hive）。这一架构又能满足随机读写，又可以支持OLAP分析的场景，但是有如下缺点：

• 架构复杂：从架构上看，数据在HBase、消息队列、HDFS间流转，涉及到的环节过多，运维成本也很高，并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控都提出了挑战。


• 时效性低：数据从HBase导出静态文件是周期性的，一般这个周期一天（或者一小时），有时效性上不是很高。


• 难以应对后续的更新：真实场景中，总会有数据是延迟到达的，如果这些数据之前已经从HBase导出到HDFS，新到的变更数据更难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。

方案2：ClickHouse、Kudu

实现方案2就是 ClickHouse、Kudu

发展历史
Yandex在2016年6月15日开源了一个数据分析数据库，叫做ClickHouse，这对保守的俄罗斯人来说是个特大事件。更让人惊讶的是，这个列式数据库的跑分要超过很多流行的商业MPP数据库软件，例如Vertica。如果你没有Vertica，那你一定听过Michael Stonebraker，2014年图灵奖的获得者，PostgreSQL和Ingres发明者（Sybase和SQL Server都是继承Ingres而来的），Paradigm4和SciDB的创办者。Micheal StoneBraker于2005年创办的Vertica公司，后来该公司被HP收购，HP Vertica成为MPP列式存储商业数据库的高性能代表，Facebook就购买了Vertica数据用于用户行为分析。

ClickHouse技术演变之路

Yandex公司在2011年上市，它的核心产品是搜索引擎。
我们知道，做搜索引擎的公司营收非常依赖流量和在线广告，所以做搜索引擎公司一般会并行推出在线流量分析产品，比如说百度的百度统计，Google的Google Analytics等，Yandex的Yandex.Metricah。ClickHouse就是在这种背景下诞生的。

• ROLAP：传统关系型数据库OLAP，基于MySQL的MyISAM表引擎


• MOLAP：借助物化视图的形式实现数据立方体，预处理的结果存在HBase这类高性能的分布式数据库中


• HOLAP：R和M的结合体H


• ROLAP：ClickHouse

ClickHouse 的核心特点

超高的查询性能

• 列式存储：只读取查询所需的列，减少了磁盘 I/O。


• 向量化计算：批量处理数据，提高了 CPU 使用效率。


• 数据压缩：高效的压缩算法，降低了存储成本。