MinGW环境下多线程导致OpenGL渲染主循环帧率下降问题求助

核心问题1：主循环阻塞逻辑错误 #

你当前代码在每帧末尾创建线程后立即调用join()，会直接阻塞整个渲染主线程，直到所有子线程执行、销毁完成才能进入下一帧。不管线程任务多简单，每帧都要承担线程创建、调度、销毁的全链路开销，相当于主动给主循环加了额外延迟。
你在MacOS上没有明显感知是因为MacOS的原生pthread实现线程创建/销毁开销极低，相同逻辑下延迟被掩盖，而MinGW的pthread实现开销更高，所以卡顿会被放大。

核心问题2：MinGW pthread实现的额外开销 #

MinGW的posix线程模型是在Windows原生线程API上封装的兼容层，相比Win32线程模型的MinGW版本、或者MSVC的std::thread实现，线程创建、上下文切换、锁的开销都要高很多，频繁创建销毁线程的场景下性能差距会非常明显。

核心问题3：不必要的IO与锁开销 #

你测试用的std::cout本身是全局同步对象，即使加了std::lock_guard保证线程安全，Windows控制台输出本身的开销也远高于普通计算任务，进一步放大了线程执行的延迟。

解决方案 #

• 重构线程逻辑，完全放弃每帧创建销毁线程的写法：提前创建固定数量的线程池（建议大小为CPU核心数-1，预留1个核心给渲染线程），用线程安全的任务队列传递区块生成需求，子线程生成完区块后将结果写入安全队列，主渲染线程每帧仅需消耗极短时间拉取队列中已完成的结果即可，全程不要调用join阻塞主循环。
• 更换编译工具链配置：换用Win32线程模型的MinGW版本重新编译，或者直接使用MSVC编译器编译代码，彻底避开posix线程封装层的额外开销。
• 移除工作线程中的控制台IO操作，所有调试输出可以统一收集后在主线程低频率批量输出，避免IO操作占用工作线程时间、引入不必要的锁开销。
• 测试阶段如果要验证多线程本身的开销，可以暂时将测试线程detach（正式项目不要随意使用detach避免资源泄漏），确认去掉join阻塞后帧率是否恢复正常。

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