文章目录
引言
前文讲述了 CyclicBarrier 和 CountDownLatch 的基本用法，本文笔者将给大家复盘一个 CyclicBarrier 使用不当导致线程饥饿死锁的踩坑经历。
2019 年早些时候，笔者写过一个简单的应用，功能是对不同 Linux 系统的防火墙的 NAT 文件进行解析，并将 NAT 转换信息解析后存入数据库。本来每个文件都不大，单线程解析也足够了，可是领导却想将线程数做成可控的，可以单线、也可以多线程，线程数由配置文件决定，理由是：万一将来文件数量过多怎么办？
为了这个可能并不存在的 “万一”，只能把应用设计成多线程的了。在协作控制时选择了 CyclicBarrier，本以为是很简单的多线程解析应用，结果脑门一热把线程数设置成 1 后，陷入了单线程调度的死锁问题中了。
功能分析
主流程概述如下：
- 主应用开启一个任务调度线程池，根据 NAT 日志文件个数提交对应个解析任务；
- NAT 解析任务解析对应的文件；
- 主应用等待各个解析任务完成后进行收尾工作：统计解析耗时、关闭调度线程池。
线程池启动时，工作线程的个数从配置文件中读取，解析线程之间的协作工具选择了最近常用的 CyclicBarrier