干了8年Java，我才把这些并发工具捋明白（实战血泪总结）
从被线上OOM支配的恐惧，到如今从容应对高并发，这些
java.util.concurrent里的“老伙计”们，是我最坚实的战友。今天不扯虚的，一篇讲透它们的用法和我踩过的坑。
大家好，我是老张，一个在一线写了8年Java代码的老兵。
刚入行那会儿，我最怕的就是“并发”这俩字。记得有一次，我们一个电商秒杀活动，上线瞬间系统直接卡死，CPU飙到100%，日志里全是OutOfMemoryError。领导急得拍桌子，我盯着满屏的synchronized和wait/notify，冷汗直冒。
后来，我痛定思痛，把java.util.concurrent整个包啃了三遍。从那以后，我才算真正摸到了并发编程的门道。今天，我就结合自己的实战经历，把这里面的核心工具挨个捋一遍，希望能帮你少走弯路。
一、线程池三兄弟：Executor、ExecutorService、ScheduledExecutorService
1. Executor——最朴素的“任务执行器”
Executor就是一个接口，它的职责极其单一：执行一个任务。至于这个任务是新开线程，还是用当前线程，它不管。
我刚学的时候写过这样的代码：
java
Executor executor = command -> command.run(); executor.execute(() -> System.out.println("任务执行了"));这其实就是同步执行，没啥用。但它的设计思想很牛——把“任务的提交”和“任务的执行策略”彻底解耦。后来我们做异步任务编排，就是基于这个思想。
2. ExecutorService——真正的“线程池管家”
这是我工作中用得最多的。它自带一个任务队列，你往里面扔任务，它按线程池的配置来调度。
真实经历：有一年做双11大促的数据清洗，需要处理几百万条日志。我直接用Executors.newFixedThreadPool(10)创建了一个固定大小线程池，把所有任务submit进去，然后shutdown()+awaitTermination()等待完成。那一次，程序稳稳跑了2小时，没出任何差错。
但要注意：newFixedThreadPool和newCachedThreadPool在任务量巨大时，前者队列可能爆内存，后者可能创建过多线程。生产环境强烈建议用ThreadPoolExecutor自定义参数，这个坑我踩过——有一次用newCachedThreadPool，瞬间创建了上万个线程，直接导致服务不可用。
3. ScheduledExecutorService——定时/延迟任务的“闹钟”
我们有个对账系统，需要每天凌晨2点跑批。用ScheduledExecutorService的scheduleAtFixedRate太合适了。
java
ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(() -> { // 对账逻辑 }, 0, 24, TimeUnit.HOURS);区别记住一点：scheduleAtFixedRate是固定频率，不管任务执行多久，都按固定间隔启动；scheduleWithFixedDelay是固定延迟，等上一次执行完再等固定时间才开始下一次。我们用后者更多，因为可以避免任务堆积。
二、Future——异步任务的“结果凭证”
Future就像你在淘宝下单后的物流单号，你可以随时查进度（isDone()），也可以等着收货（get()），或者不想要了取消（cancel()）。
它本身不负责执行任务，而是ExecutorService.submit()返回的一个凭证，让你可以拿它去获取结果或控制任务状态。
踩坑警示：Future.get()是阻塞的！有次我忘了设置超时，一个下游服务挂了，我的线程池所有线程都卡在get()上，导致整个服务雪崩。后来我强制所有get()都带超时参数：
java
future.get(3, TimeUnit.SECONDS);并捕获TimeoutException做降级处理。这个习惯救了我好几次。
三、协作工具箱：CountDownLatch、CyclicBarrier、Semaphore、Phaser
1. CountDownLatch——“倒计时门闩”
适合一个线程等待多个线程完成。比如我们做大数据报表，需要先并行加载A、B、C三张表的数据，都加载完再合并。用CountDownLatch(3)，每个加载线程完成后countDown()，主线程await()等待归零。
简单粗暴，但不能重用，用完就废了。
2. CyclicBarrier——“循环栅栏”
适合多个线程互相等待，都到齐了再一起往下走。我们做过一个模拟并发请求的压测工具，启动N个线程，用CyclicBarrier让它们同时开始，模拟瞬间峰值。
而且它可以重用，reset()之后又能用。有一次我因为忘了检查isBroken()，导致线程永远卡在await()，排查了半天。记住：如果有线程被中断或超时，栅栏就破了，一定要处理。
3. Semaphore——“信号量限流”
这是我最喜欢的限流工具。我们某个开放API，只能支持每秒最多100个并发请求，我就用Semaphore(100)。
java
if (semaphore.tryAcquire(1, TimeUnit.SECONDS)) { try { // 处理请求 } finally { semaphore.release(); } } else { // 返回限流错误 }它比单纯的计数器强大得多，还能支持多资源。有一次我们用它在数据库连接池之上再做一层限流，防止突发流量打崩数据库，效果立竿见影。
4. Phaser——“万能相位器”
Phaser是CountDownLatch和CyclicBarrier的升级版，支持动态注册参与者和多阶段协调。我们做过一个多阶段数据处理流水线，每个阶段参与线程数不同，用Phaser可以灵活控制。不过它比较重，一般场景用前三个就够了。
四、BlockingQueue & DelayQueue——生产者消费者的“传送带”
BlockingQueue
我们日志采集系统就是用BlockingQueue做的。生产者不断往队列里放日志，消费者批量取出并写入ES。ArrayBlockingQueue和LinkedBlockingQueue我常用，前者有界，后者默认无界（要小心OOM）。
经验：一定要用有界队列，并设置合理的拒绝策略。我们曾经因为无界队列导致内存溢出，整整挂了5分钟。
DelayQueue
延时队列，元素必须实现Delayed接口。我们用它做订单超时自动取消，订单创建后放入队列，延迟30分钟，到时间自动取出处理。比轮询数据库高效得多。
五、ThreadFactory——线程的“创建工厂”
ThreadFactory的核心作用是让你可以自定义线程的创建过程。我主要用它来做两件事：
第一，给线程起有意义的名字。以前调试线程池问题时，堆栈里全是pool-1-thread-1这种名字，根本分不清是哪个业务。自定义ThreadFactory后，线程名变成"order-process-thread-1"，一旦出现死锁或CPU飙高，一眼就能定位到具体业务线。
第二，统一设置线程属性，比如把线程设为守护线程（setDaemon(true)），或者设置统一的未捕获异常处理器。
这是个小习惯，但能省你三天时间。
六、Locks——比synchronized更灵活的“锁”
ReentrantLock是我用来替代synchronized的利器。它能尝试加锁（tryLock）、可中断加锁、支持公平/非公平。
有一次，我们用synchronized做缓存更新，结果在锁内调用了远程服务，导致锁持有时间过长，大量请求阻塞。换成ReentrantLock后，用tryLock(100, TimeUnit.MILLISECONDS)，如果拿不到锁就快速失败，系统瞬间恢复了弹性。
记住：一定要在finally里unlock，否则锁永远不释放！
七、总结：这些工具各司其职，组合起来才是并发体系
这么多年下来，我最大的感悟是：并发工具不在于多，而在于用对场景。
我把它们的分工重新梳理了一遍，这次写得准确一些：
Executor系列 = 任务的调度与执行，管的是“谁来跑、怎么跑”Future= 异步任务的结果凭证，管的是“拿到结果、取消任务”CountDownLatch=等待其他线程完成（等别人干完我再干）CyclicBarrier= 多线程互相等待到齐（大家一起出发）Semaphore= 并发访问限流（控制同时能进多少人）BlockingQueue= 线程间的数据传递（生产者消费者管道）DelayQueue=延迟任务处理（时间到了再取）Lock= 共享资源的互斥保护（锁住临界区）ThreadFactory= 线程的创建控制（命名、守护、异常处理器）
如果你能把它们组合起来，就能构建出高可用、高吞吐的系统。当然，前提是多实践、多踩坑。我上面说的每一个坑，都是我熬夜加班换来的，希望你能绕过去。
最后，送大家一句话：并发编程，一半是技术，一半是艺术。工具只是剑，剑法还得自己悟。
如果你觉得有用，点个赞、收个藏，下次遇到高并发问题，回来看一眼，或许就能找到答案。
（本文基于Java 8+，所有代码均经过生产环境验证，欢迎交流指正。）