Java多线程代码可读性提升技巧

优先选 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 cache = new ArrayList<>(); 就该警觉——它几乎必然引发并发修改异常或数据丢失。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 报空指针，你根本不知道这线程干啥的。线程名是最低成本的可读性投资。

• 自定义 ThreadFactory，把业务含义嵌入名称：比如 "order-processor-pool-%d" 或 "cache-refresh-worker-%d"
• 在线程工厂里设置 UncaughtExceptionHandler，统一记录未捕获异常，避免某些线程崩溃后悄无声息
• 使用 Executors.threadPoolBuilder()（Java 21+）或 new ThreadPoolExecutor(...) 时传入该工厂，别依赖默认行为

真正影响可读性的，往往不是语法多复杂，而是变量命名是否暴露意图、锁范围是否窄到只包关键行、异步链条是否能顺着箭头读下去。这些地方一旦妥协，三个月后你自己都得花半小时理清逻辑。