c# 来自计时器句柄的新线程问题
我正在尝试以下代码
private void timer1_Tick(object sender, EventArgs e)
{
Thread nT = new Thread(new ThreadStart (checkThread));
nT.Start();
}
。cheackThread() 函数执行网络请求，计时器的滴答属性为 2000 毫秒。 checkThread() 中的所有对象在使用后都会被丢弃。当程序长时间运行（例如 3 小时）时，操作系统会抱怨资源不足。我注意到在 ctrl-alt-delete 中，应用程序运行时句柄计数正在增加。一旦线程执行完所有代码，线程是否不会自动释放其内存，或者这是允许 gc.collect 的次数之一？
Im experimenting with the following code
private void timer1_Tick(object sender, EventArgs e)
{
Thread nT = new Thread(new ThreadStart (checkThread));
nT.Start();
}
The cheackThread() function carries out a web-request and the timer's tick property is 2000ms. All objects in the checkThread() are disposed of after use. When the program is run for long periods e.g 3 hours the OS complains about low resources. I notices that in ctrl-alt-delete the handle count is increasing when the app runs. Does the thread not release its memory automatically once it has executed all its code or is this one of those times gc.collect is permitted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，您的计时器不会遵守这一点。分辨率约为 20 毫秒。
但对于 Web 请求来说，即使 20 毫秒也不是很长。如果您的 checkThread 超过 20 毫秒（时不时地），那么您启动线程的速度将比它们完成的速度快。所以它们堆积起来。需要几个小时的事实让我认为这是最有可能的原因。
您可以使用调试器或简单的计数器
activeThreads（使用 Interlocked）来诊断此问题。使用 ThreadPool 或 TPL (Fx4) 可以解决一些问题，但您仍然需要检查和限制同时请求的数量。
First, your timer will not honor this. The resolution is ~20 ms.
But even 20 ms is not very long for a Webrequest. If your checkThread exceeds 20ms (every now and then) then you would be starting Threads quicker than they can finish. And so they pile up. The fact that it takes a few hours makes me think this is the most likely cause.
You could use a debugger, or a simple counter
activeThreads(use Interlocked) to diagnose this.Using the ThreadPool or the TPL (Fx4) would solve some of your issues but you would still need to check and limit the number of simultaneous requests.
您应该让框架处理线程，而不是使用 ThreadPool.QueueUserWorkItem
You should let the Framework handle the threads, instead of using
Threadgo for ThreadPool.QueueUserWorkItem