可维护的并发代码关键在于状态管理清晰、责任边界明确、线程模型与业务解耦；应避免共享可变状态，慎用volatile和synchronized，优先使用原子类、CompletableFuture和正确管理ThreadLocal，并通过同步工具+状态断言进行可靠测试。
Java 并发代码难以维护，根本原因往往不是锁用得不对，而是状态管理失控、责任边界模糊、线程模型与业务逻辑耦合太紧。可维护的并发代码不追求“高性能第一”，而优先保证“谁在什么时候修改了什么状态”能被快速定位和推理。
避免共享可变状态：从 volatile 和 synchronized 说起
很多人一写并发就条件反射加 synchronized 或标 volatile，但这两个关键字解决的是不同问题：volatile 只保证可见性，不保证原子性；synchronized 保证原子性和可见性，但容易因锁粒度不当引发阻塞或死锁。
- 用
volatile仅限于简单标志位（如isRunning），且该变量不参与复合操作（比如counter++不行） -
synchronized块应尽量小，只包裹真正需要互斥的代码段，不要把日志、HTTP 调用等 I/O 操作包进去 - 优先用
java.util.concurrent.atomic包下的类（如AtomicInteger、AtomicReference）替代手写同步逻辑，它们封装了 CAS 语义，更安全也更易读
用 CompletableFuture 替代裸线程 + ExecutorService 手动编排
直接 new Thread 或反复调用 executor.submit() 容易导致资源泄漏、异常丢失、回调嵌套过深。而 CompletableFuture 把异步任务建模为可组合的状态机，天然支持链式错误处理和超时控制。
- 用
supplyAsync(..., executor)显式传入线程池，避免依赖默认 ForkJoinPool（尤其在 Web 容器中可能被其他模块干扰） - 所有异步链路结尾务必接
exceptionally()或handle()，否则上游异常会静默吞掉 - 慎用
join()或get()阻塞等待——这会让异步退化为同步，且未设超时会卡死线程
用 ThreadLocal 管理上下文，但必须配合 remove()
ThreadLocal 是隔离线程间状态的利器，常见于传递 traceId、用户身份、事务上下文。但它不是“自动垃圾回收”的魔法容器——在线程复用场景（如 Tomcat 的线程池、ForkJoinPool）下，不手动 remove() 会导致内存泄漏和脏数据残留。
立即学习“Java免费学习笔记（深入）”；
- 在请求入口（如 Filter、Interceptor）初始化
ThreadLocal，并在出口（finally 块或 try-with-resources）调用threadLocal.remove() - 避免将大对象（如 Map、List）存入
ThreadLocal，尤其不要存 Spring Bean 引用（可能持有着整个 ApplicationContext） - 如果使用
TransmittableThreadLocal（阿里 TTL 库），注意它只解决父子线程传递问题，对CompletableFuture等异步线程池仍需显式runAsync(..., executor)透传
测试并发逻辑：别只靠“多跑几次看会不会崩”
并发 bug 往往是偶发的竞态条件（race condition）或时序敏感问题，单元测试里加个 Thread.sleep() 或循环 1000 次并不能稳定复现。真正有效的办法是控制执行顺序 + 观察状态断言。
- 用
CountDownLatch或CyclicBarrier同步多个线程的启动时机，强制制造竞争点 - 用
AtomicBoolean记录关键路径是否被执行，再结合await()等待预期状态，而不是依赖 sleep 猜时序 - 对共享状态做快照断言（例如：在并发更新后，检查最终值是否等于预期总和），比检查中间过程更可靠
最难的不是写出能跑通的并发代码，而是让下一个接手的人能在 5 分钟内看懂“这段逻辑为什么必须加锁”“这个 ThreadLocal 在哪清的”“这个 CompletableFuture 失败后流向哪里”。状态归属清晰、副作用收敛、错误传播明确——这些才是可维护性的底层支点。
