统计C++程序可用线程数的该实现方案是否合理？

你的实现完全不是合理的可用线程数统计方案，存在多处严重问题：

• 统计目标完全错位：你测出来的是当前环境下操作系统允许你单个进程创建的最大线程数量，和程序性能优化需要用到的「CPU可用逻辑核心数」没有任何关系。前者受系统资源配额、当前整机负载影响，动辄可达数千甚至上万，而后者是固定的硬件参数，一般等于你的CPU逻辑核心总数。
• 代码存在严重资源泄漏：你创建的std::thread对象既没有调用join()等待执行结束，也没有调用detach()脱离管理，同时自定义链表节点全是动态申请未释放，程序运行后会留下大量僵尸线程和内存垃圾，甚至会影响计数结果的准确性。
• 结果完全不可靠：测试结果受系统用户进程限制（比如Linux下的ulimit nproc配置）、当前整机已占用线程数、程序自身内存占用等多重随机因素影响，每次运行得到的数值都可能发生变化，没有参考价值。

C++标准库已经提供了原生的硬件并发数获取接口，直接调用std::thread::hardware_concurrency()即可得到当前系统的可用逻辑核心数，这也是绝大多数场景下程序创建工作线程的最优参考值，完全不需要自行实现探测逻辑。

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