我们有个 WebFlux 服务，没人愿意改它 我们有个网关服务是 2021 年用 WebFlux 写的，三个接口、两千多行，但组里除了我没人愿意碰它。原因很简单：那套 Mono/Flux 的链式调用，加上 .flatMap() 里嵌套 .zip() 的写法，改起来要花两倍时间，而且出错后堆栈完全看不
凌晨告警：服务起不来了，日志只有一行 一个深夜，我们的风控服务在发布后反复重启失败。Pod 日志最后一行永远是这句话： java.lang.OutOfMemoryError: unable to create new native thread at java.base/java.lang.
商品详情页 P99 1.8 秒，五个 RPC 串行调用 12 月中旬，前端同学甩过来一张截图：商品详情页首屏白屏 2 秒多，用户投诉"点商品没反应"。我去看 SkyWalking 的拓扑，这个接口平均 690 ms，P99 1.8 s，P999 3.2 s。 接口干的事很简单，串着调了 5 个下游：
压测数据：同样的计数，快了 6 倍 十一月中旬做网关的埋点统计改造，需要统计每个接口的调用次数和总耗时。我一开始用的 AtomicLong： private final Map<String, AtomicLong> counters = new ConcurrentHashMap<>(); pu
面试官追问"ABA 具体怎么解决"，我卡住了 12 月中的一次面试。聊到 CAS，我说"它有个 ABA 问题"，面试官问"什么场景下真的会遇到 ABA？怎么解决？" 我答"加版本号"，他又追了一句"JDK 里加版本号的那个类，你知道它的 compareAndSet 是怎么实现的吗？" 答不上来。回去
那个 CPU 100% 的现场，和我熬夜复现的死循环 12 月初，隔壁组的老服务（跑在 JDK 7 上的一套结算系统，JDK 一直没升）CPU 突然跑满。监控上 CPU 从 30% 直接顶到 100%，而且是持续的，降不下来。接口全部超时，重启之后几分钟又上去。 我过去帮忙看，抓了现场。这篇记录整个
商品详情页 800 毫秒，我把它改成了 180 毫秒 10 月底做性能优化，商品详情页是重点。这个页面要聚合 6 个数据源，原来的代码是串行调的： public ProductDetailVO getDetail(Long skuId) { ProductVO product = produ
对账少了 3.7 万元：一行 parallelStream 惹的祸 10 月 8 号，财务来找我，说 9 月 30 号的日报表金额对不上，系统算出来 148.2 万，实际银行流水 151.9 万，少了 3.7 万。而且奇怪的是，同一个任务重跑一遍，出来的数字还不一样：第二次是 149.6 万。 同样
Code Review 时发现同事用 CyclicBarrier 写了个一次性等待 9 月中的一次 code review，我看到同事写了这么一段：一个接口要并行查三个数据源然后汇总，他用 CyclicBarrier 做同步。功能是对的，但读起来很别扭——CyclicBarrier 那套 await
读 ThreadPoolExecutor 源码时，我顺手压测了三种队列 9 月份啃线程池源码，看到构造函数里那个 BlockingQueue<Runnable> workQueue 参数，我才意识到自己从来没认真选过它——一直是 Executors.newFixedThreadPool(20) 一路
