线程池分析
我们知道线程并非越多越好。创建和销毁线程开销大，线程栈占用内存，频繁上下文切换消耗 CPU，大量线程同时唤醒还可能引发系统负载尖峰甚至宕机。
线程池的优势在于：在服务启动时预先创建一定数量的线程，任务到来时直接复用空闲线程执行，任务完成后线程归还而非销毁，从而避免频繁创建/销毁线程的性能损耗，提升系统吞吐与响应能力。因此设计时，采用以下两种模式相结合的方法增加项目可用性。
- Fixed 模式：线程数固定，通常设为 CPU 核心数，适用于负载稳定、任务量可预测的场景。
- Cached 模式：线程数动态伸缩，按需创建但不超过上限；空闲线程超时（如 60 秒）后自动回收，适合突发性、短时任务。
线程池设计
线程池执行流程与核心原理
线程池执行流程：主线程初始化线程池并设置工作模式后，通过submitTask提交任务到共享任务队列；工作线程在ThreadFunc中通过双条件变量机制 （notEmpty_等待任务、notFull_控制队列容量）协调任务消费；任务执行结果通过Result对象的信号量同步机制 （wait/post）返回给调用方；析构时触发停机协议 ，通过exitCnd_条件变量确保所有线程安全退出。核心知识点包括：RAII锁管理 、类型擦除 （Any类存储任意返回类型）、原子操作 以及动态线程伸缩，一起共同构成了一个高性能且线程安全的并发基础设施，解决了多线程编程中的资源竞争、死锁风险和优雅停机等关键挑战。
项目反思
- 析构死锁问题：线程池在析构时等待工作线程退出，因同步逻辑不当导致主线程与工作线程相互等待，进程无法退出。
- 跨平台差异：Windows 下正常运行的代码在 Linux 下出现死锁，源于线程调度和条件变量行为的平台差异。
分析定位问题方法： 主要通过gdb attach到正在运行的进程，通过info threads，thread tid，bt等命令查看各个线程的调用 堆栈信息，结合项目代码，定位到发生死锁的代码片段，分析死锁问题发生的原因，xxxx，以及最终的 解决方案。