去年用 JDK 21 虚拟线程接重构一个 HTTP 聚合服务，压测时吞吐死活上不去。翻 JFR 发现大量"虚拟线程被 pin 在载体线程上"的事件——罪魁是代码里随处可见的 synchronized。JDK 22/23 的改进，正好把这块骨头啃了下来。 Pin 是什么，为什么是性能杀手 虚拟线程的精
ThreadLocal 在虚拟线程时代水土不服 我们的链路追踪 ID 一直用 ThreadLocal 传。切到虚拟线程后，一个请求一个虚拟线程，数量可能上百万，ThreadLocal 的哈希表跟着膨胀，而且线程复用导致上下文串台——上一个请求的 traceId 漏到了下一个。Java 21 的预览特
等了两年的正式版 JDK 21 在 9 月正式 GA，虚拟线程（Project Loom）终于从预览转正。作为常年和线程池、异步回调搏斗的人，我第一时间把内部一个 IO 密集的采集服务迁了过去。结果不算惊艳到颠覆，但确实把"一个请求一个线程"这种直观写法重新变可行了，迁移成本也比预期低。这里把原理、
解构数据对象的老痛点 做对账时我拿到一个嵌套的支付结果对象，传统写法要一层层 getter 把字段掏出来，还得判空，代码又臭又长。更糟的是改一个字段层级，所有取值点都得跟着改，漏一处就是运行时 NullPointerException，而且这种错编译期发现不了，只能等线上炸。JDK 21 的模式匹配
一个被语法糖耽误的拼接需求 上周我要拼一段带变量的 SQL 调试日志，里面混入三个变量。老写法要么是加号拼接，要么是 String.format，前者冗长后者位置参数容易错位。听同事说 JDK 21 的预览特性 String Templates 把这件事做漂亮了，我拉了 early-access 构
面试被问住：线程池里的异常去哪了 五月面试一个候选人，他反过来问我：「用 ExecutorService 提交了三个任务，其中一个抛异常，另外两个还在跑，怎么保证它们被取消？」我脱口而出「写个 Future 判断」，但细想发现，传统线程池里任务生命周期是散的，取消一个不影响其他——这恰恰是结构化并发
背景：3.1 刚发布，3.2 在路上 五月十八号 Spring Boot 3.1 正式发布，我们组件库当天就升了。3.2 按计划十一月才来，但里程碑里已经能看出方向。趁热把两版新特性盘一遍，顺手在预发环境验证了几个最实用的。 Docker Compose 支持（3.1） 以前本地起依赖靠 testc
从一次支付状态建模说起 早些年写支付结果，我习惯用一个 enum 加一堆 if： enum PayStatus { SUCCESS, FAILED, PENDING, REFUNDED } void handle(PayStatus s) { if (s == SUCCESS) { ...
一段 SQL 在 Java 里换行，我存成了诡异的格式 前几天 Code Review，看到有人拼一条多行 SQL 用了老套路： String sql = "SELECT id, name, price FROM product " + "WHERE category = ? AND
为什么我们卡在 JDK 8，却决定直接跳 17 团队基础组件升级评审会上，有人提议"升到 JDK 11 过渡一下"。我投了反对票：既然要动，不如直接到 JDK 17——它是继 8 之后第二个长期支持版本（LTS），2021 年 9 月发布，生态已经足够成熟，而 11 到 17 之间没有第二个 LTS
