并发案例：CyclicBarrier 使用不当导致死锁问题分析
文章目录
- 引言
- 功能分析
- 单线程调度死锁问题复盘
- 打破死锁的方法
- 编程启示录
引言
前文讲述了 CyclicBarrier 和 CountDownLatch 的基本用法，本文笔者将给大家复盘一个 CyclicBarrier 使用不当导致线程饥饿死锁的踩坑经历。
2019 年早些时候，笔者写过一个简单的应用，功能是对不同 Linux 系统的防火墙的 NAT 文件进行解析，并将 NAT 转换信息解析后存入数据库。本来每个文件都不大，单线程解析也足够了，可是领导却想将线程数做成可控的，可以单线、也可以多线程，线程数由配置文件决定，理由是：万一将来文件数量过多怎么办？
为了这个可能并不存在的 “万一”，只能把应用设计成多线程的了。在协作控制时选择了 CyclicBarrier，本以为是很简单的多线程解析应用，结果脑门一热把线程数设置成 1 后，陷入了单线程调度的死锁问题中了。
功能分析
主流程概述如下：
- 主应用开启一个任务调度线程池，根据 NAT 日志文件个数提交对应个解析任务；
- NAT 解析任务解析对应的文件；
- 主应用等待各个解析任务完成后进行收尾工作：统计解析耗时、关闭调度线程池。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！