递归创建worker threads做多线程文件解析，如何等待全部完成后再执行后续逻辑

方案可行性判断 #

这个优化方案完全可行。你的场景属于典型的IO密集型任务，单线程运行时大部分时间都在等待文件IO返回，多线程可以并行处理多个文件的读取和解析逻辑，能大幅提升复杂引用树场景下的处理效率，性能收益通常可以达到单线程的3~8倍，和你的CPU核心数、磁盘IO性能正相关。

核心问题解决方案 #

1. 线程安全的去重存储 #

你之前对HashSet的安全假设确实不成立：多线程同时写入非线程安全的集合，大概率会出现数据丢失、集合结构损坏甚至程序崩溃的问题，两种低成本解决方案可以选：

• 轻量锁方案：给HashSet的写入操作加互斥锁，比如C#的lock、Java的synchronized、Go的sync.Mutex，每次写入元素前先获取锁，确认元素不存在再执行写入。因为你的写入操作仅存储文件路径这类轻量数据，锁竞争的开销极低，完全可以接受。
• 免开发方案：直接使用编程语言标准库提供的线程安全集合，比如C#的ConcurrentHashSet、Java的ConcurrentHashMap.newKeySet()、Go的sync.Map，不需要自己处理锁逻辑，出错概率更低。

2. 多线程任务调度与全任务等待实现 #

不要手动为每个文件创建线程，用线程池+任务计数的方案最稳定，通用实现逻辑如下：

1. 初始化三个核心组件：
   • 线程安全的去重集合（就是存所有唯一引用的集合）
   • 线程安全的任务队列，用于存储待解析的文件路径
   • 任务同步计数器：对应不同语言可选CountDownLatch(Java)、CountdownEvent(C#)、sync.WaitGroup(Go)，初始值设为1（对应根文件解析任务）
2. 把根文件路径放入任务队列，启动固定数量的worker线程（线程数设为CPU核心数的2~4倍即可，太多会导致线程切换开销抵消收益），所有worker循环执行以下逻辑：
   • 从任务队列取到待解析的文件路径，先尝试加入去重集合，如果元素已存在，直接将同步计数器减1，跳过当前任务
   • 如果是新增元素，读取文件内容，解析出所有引用的子文件路径
   • 当前文件解析完成后，先将同步计数器减1，再把所有解析得到的子文件路径加入任务队列，每加入1个新任务，同步计数器加1
3. 主线程阻塞等待同步计数器归0，此时所有文件解析任务全部完成，可直接执行后续业务逻辑。

避坑和优化建议 #

• 提前做文件路径标准化：比如相对路径转绝对路径、Windows系统统一大小写，避免同一个文件因为路径写法不同被识别为不同资源，导致重复解析
• 去重集合天然解决循环引用问题：如果出现A引用B、B又引用A的循环场景，只要子文件路径加入去重集合失败就会直接跳过，不会出现无限递归
• 不要提前给子任务加计数：必须等当前文件解析完成、确认要新增子任务的时候再给同步计数器加值，避免出现计数器提前归0、后续任务还没执行的问题

内容的提问来源于stack exchange，提问作者Doctor Gurke