创建大量系统线程并等待MRE的影响
本文关键字：等待 MRE 影响 线程 系统 创建 | 更新日期: 2023-09-27 18:02:43
我正在尝试修复一个非常大的应用程序中的内存峰值。虽然我不确定这会对内存产生多大的影响，但我注意到以下几点:
- 应用程序使用自定义线程池来完成所有开销较大的任务
- 应用程序将执行所有传入的任务
- 任务可以由数千个子任务组成
- 虽然线程池一次只执行{T}个任务，并且在开始一个新任务之前完全完成一个任务，但它确实创建一个新的系统线程(线程类)并为添加到它的每个子任务启动它
- 子任务系统线程以线程启动时立即阻塞在手动重置事件(MRE)上，等待线程池插槽释放
所以，这个线程池可以创建数千个线程，但除了30个(或任何您配置的)线程外，所有线程都将在MRE上阻塞，而其他任务完成。
我的问题:
阻塞在MREs上的一千个线程对内存/处理器有什么影响?我没有太多的时间来修复这个尖峰，所以如果它是最小的，我宁愿离开这个问题，在我有更多时间的时候在以后的补丁中修复它。
另外，这种行为在线程池中是典型的吗?或者这听起来有缺陷吗?(我倾向于有缺陷，但我没有足够好的背景来确定)
阻塞在MREs上的一千个线程对内存/处理器有什么影响?我没有太多的时间来修复这个尖峰，所以如果它是最小的，我宁愿离开这个问题，在我有更多时间的时候在以后的补丁中修复它。
每个线程，当手工创建时，有它自己的堆栈分配给它。默认情况下，这将是每个线程1MB，尽管可以通过构造函数参数使线程具有更小的堆栈。
你最好重新设计这个，从你的问题的描述，使用标准的ThreadPool，和一个类，如BlockingCollection<T>来处理你的节流。这是设计来直接允许边界输入，与阻塞。创建一个包含无限数量线程的自定义"线程池"将远远低于使用框架中包含的高度调优的线程池。
还有，这种行为在线程池中是典型的吗，或者这听起来有缺陷吗(我倾向于有缺陷，但我没有足够好的背景来确定)。
这绝对是有缺陷的。ThreadPool的全部意义在于避免为每个请求创建一个线程，并为多个请求"池化"线程(重用它们)而不必重新创建它们。