优先选 synchronized 块而非方法，精准锁定共享操作；需超时、中断或条件等待时用 ReentrantLock 并在 finally 中释放；共享状态应封装在线程安全容器中，如 ConcurrentHashMap 或 CopyOnWriteArrayList；异步任务优先用 CompletableFuture 链式调用并指定执行器；线程名须具业务含义且配置统一异常处理器。
用 synchronized 还是 ReentrantLock？看锁的粒度和可读性需求
锁本身不难写，但锁的位置和范围直接决定别人能不能一眼看懂你在保护什么。用 synchronized 方法最省事，但容易锁太宽——比如整个 processOrder() 方法加锁，其实只有一行更新库存需要同步。ReentrantLock 虽然多两行代码（lock()/unlock()），却能精准包裹关键段，配合 try-finally 也清晰可控。
- 优先选
synchronized块而非方法：把锁限制在sharedCounter++这类共享操作上，而不是整个业务逻辑 - 若需超时、中断或条件等待，必须用
ReentrantLock；但别为了“高级”而放弃简洁，多数场景synchronized更易读 - 永远在
finally块里释放ReentrantLock，漏掉会导致死锁且难以排查
共享状态尽量封装进线程安全容器，别裸露 ArrayList 或 HashMap
看到 public static List 就该警觉——它几乎必然引发并发修改异常或数据丢失。Java 提供的线程安全替代品不是摆设，关键是选对类型。
-
ConcurrentHashMap替代HashMap：支持高并发读写，且computeIfAbsent()这类原子操作能避免手写双重检查 -
CopyOnWriteArrayList适合读多写少场景（如监听器列表），但写操作会复制整个数组，别用它存高频更新的数据 - 避免自己包装非线程安全集合，比如用
Collections.synchronizedList()后还手动遍历——迭代过程仍可能抛ConcurrentModificationException
用 CompletableFuture 替代裸线程 + join()，让异步流程像同步代码一样可读
手写 Thread t = new Thread(...); t.start(); t.join(); 不仅冗长，还掩盖了任务间的依赖关系。而 CompletableFuture 的链式调用能把“查库 → 转换 → 发通知”这种顺序依赖表达得一目了然。
CompletableFuture.supplyAsync(() -> db.loadUser(id))
.thenApply(user -> user.enrichWithProfile())
.thenAcceptAsync(notifier::send, notificationExecutor)
.exceptionally(ex -> { log.error("failed to notify", ex); return null; });
- 明确指定执行器（如
notificationExecutor），避免所有异步任务挤在ForkJoinPool.commonPool()里互相拖慢 - 慎用
get()阻塞等待——它会破坏异步优势，且未设超时可能永久挂起；优先用thenApply/thenAccept做后续处理 - 异常处理必须显式写
exceptionally()或handle()，否则上游异常会静默吞掉，调试时找不到源头
别让线程名变成 Thread-12，用 ThreadFactory 统一命名和异常处理器
日志里出现 Thread-45 报空指针，你根本不知道这线程干啥的。线程名是最低成本的可读性投资。
立即学习“Java免费学习笔记（深入）”；
- 自定义
ThreadFactory，把业务含义嵌入名称：比如"order-processor-pool-%d"或"cache-refresh-worker-%d" - 在线程工厂里设置
UncaughtExceptionHandler，统一记录未捕获异常，避免某些线程崩溃后悄无声息 - 使用
Executors.threadPoolBuilder()（Java 21+）或new ThreadPoolExecutor(...)时传入该工厂，别依赖默认行为
真正影响可读性的，往往不是语法多复杂，而是变量命名是否暴露意图、锁范围是否窄到只包关键行、异步链条是否能顺着箭头读下去。这些地方一旦妥协，三个月后你自己都得花半小时理清逻辑。
