靠日志活着

一次看似正常的配置行为，却让我开始怀疑 @ConditionalOnProperty 的判定逻辑是否失效。havingValue="" 在配置为 true 时依然生效，并非 Bug，而是 Spring

大多数系统不是一夜之间变复杂的。 真正的变化，往往发生在某一次非常“正确”的优化之后。 那次优化有充分理由、有数据支撑、甚至还救过一次线上问题。 但几年后回头看，它却成了整个系统复杂度的起点。

限流，本来是为了保护系统。 但在这次事故中，限流器本身成了第一个被拖垮的组件。 更糟的是： 后端服务没来得及崩 网关先失去了响应能力 所有请求卡在入口

在生产环境中，线程池相关的问题往往有一个共同特点： CPU 不高、内存正常、没有明显异常日志，但系统就是“卡死了”。 这类问题排查成本高、定位慢，很多时候直到请求完全堆死，问题才被真正发现。

在微服务架构中，Feign 作为常用的服务间调用组件，开发者往往会通过设置超时和重试机制来增强系统的“稳定性”。 然而，如果参数配置不当，尤其在高并发场景下，超时与重试机制可能会放大流量，反

一、线上事故复盘：任务全卡死，日志一片寂静 几个月前有个定时任务服务，凌晨会并发处理上千个文件。按理说线程池能轻松抗住。 结果那天凌晨，监控报警：任务积压 5 万条，机器 CPU 却只有 3%！ 去看

📘 一、前言 在 Spring 项目中，@Transactional 是最常见的事务注解，但也是最容易被误用的注解之一。 很多时候明明加上了 @Transactional，事务却根本没生效，最后只能靠

在日常开发中，我们几乎离不开泛型：List<String>、Map<Integer, User>、Optional<T>…… 但你知道吗？这些看似“类型安全”的泛型，在运行时其实都被“擦掉”了。 今天

在并发编程中，锁机制是保证线程安全的重要手段。Java 提供了多种锁机制，从最基础的 synchronized 到功能更强大的 ReentrantLock，再到高性能的 StampedLock。本文将