问题描述
环境是windowsserver2008r2+.net2.0运行了一个服务器程序(winform的)该程序是多线程运行的将请求转换成消息分发到不同的消息队列,队列中使用自动复位信号量做同步可是该程序会随机性的出现问题.问题描述:1.表象上感觉像是cpu不够用了,工作线程没有得到cpu时间片,消息队列一直在增长2.界面线程有略卡的现象,本来有一个500ms的定时器,定时刷新界面数据,出现问题时,会出现3-4s的间隔才刷新数据3.不像是线程死循环(因为cpu占用率不高)4.重启程序就恢复了求有经验的大神指点一下,怎么查找问题.现在感觉无从下手了
解决方案
解决方案二：
检查一下内存占用，看看是否内存过高，导致停顿
解决方案三：
什么情况？看到你这么一点文字描述中仍处一大堆“恐怖的”字眼：什么“队列”、什么“自动复位信号量”，什么“界面线程”（服务器程序跟winform程序，你到底能不能清楚呢？），什么“定时器刷新数据时”，什么线程中“循环”。似乎凡是多线程编程的大忌，你都当作听时髦的技术给用了。不知道你堆砌这么多“阻塞自己、循环等待、排队、定时轮询”之类的东西这还算是设计多线程程序吗？想让多线程程序有好的性能，不应该乱用什么信号量、什么中间队列（直接注册给线程池去进行最终处理就行了）、什么定时轮询（你怎知这时候需要干扰人家繁忙操作一次？有怎知这时候是不是有点晚了？），不应该有循环。
解决方案四：
不用“查找问题”，多线程下的调试和阻塞问题足够让许多人感觉眼花缭乱无可奈何的。放下这些时髦的“机制”，少去考虑什么技术吧。
解决方案五：
引用1楼bdmh的回复:
检查一下内存占用，看看是否内存过高，导致停顿
内存占用近1G会导致停顿吗？
解决方案六：
引用2楼sp1234的回复:
什么情况？看到你这么一点文字描述中仍处一大堆“恐怖的”字眼：什么“队列”、什么“自动复位信号量”，什么“界面线程”（服务器程序跟winform程序，你到底能不能清楚呢？），什么“定时器刷新数据时”，什么线程中“循环”。似乎凡是多线程编程的大忌，你都当作听时髦的技术给用了。不知道你堆砌这么多“阻塞自己、循环等待、排队、定时轮询”之类的东西这还算是设计多线程程序吗？想让多线程程序有好的性能，不应该乱用什么信号量、什么中间队列（直接注册给线程池去进行最终处理就行了）、什么定时轮询（你怎知这时候需要干扰人家繁忙操作一次？有怎知这时候是不是有点晚了？），不应该有循环。
这个服务程序是用winform写的然后这个服务程序会处理很多不同类型的请求所以把这些不同类型的请求都生成一个标准的消息发送加入到不同的队列然后有很多线程去取不同队列的消息来处理数据
解决方案七：
引用1楼bdmh的回复:
检查一下内存占用，看看是否内存过高，导致停顿
我以前没听过说内存过高会导致停顿的有没有资料什么的我去了解一下
解决方案八：
引用6楼juzzs004的回复:
Quote: 引用1楼bdmh的回复:
检查一下内存占用，看看是否内存过高，导致停顿我以前没听过说内存过高会导致停顿的有没有资料什么的我去了解一下
内存过高时，GC会频繁的垃圾回收（需要挂起所以的线程），对性能的影响是非常大的！
解决方案九：
引用7楼lineages的回复:
Quote: 引用6楼juzzs004的回复:
Quote: 引用1楼bdmh的回复:
检查一下内存占用，看看是否内存过高，导致停顿我以前没听过说内存过高会导致停顿的有没有资料什么的我去了解一下
内存过高时，GC会频繁的垃圾回收（需要挂起所以的线程），对性能的影响是非常大的！
有没有什么检测机制来检测当前是否在进行垃圾回收呢？
解决方案十：
引用8楼juzzs004的回复:
有没有什么检测机制来检测当前是否在进行垃圾回收呢？
GC你是没法干预的，也不要试图去规避，而该找到其根本原因；为什么占用那么大的内存，队列里面存的都是什么，可否考虑struct？为什么要用大量的线程，并不是线程越多就越快；尽量少用甚至不用同步，阻塞自己什么也不干，能快到哪去？
解决方案十一：
引用8楼juzzs004的回复:
Quote: 引用7楼lineages的回复:
Quote: 引用6楼juzzs004的回复:
Quote: 引用1楼bdmh的回复:
检查一下内存占用，看看是否内存过高，导致停顿我以前没听过说内存过高会导致停顿的有没有资料什么的我去了解一下
内存过高时，GC会频繁的垃圾回收（需要挂起所以的线程），对性能的影响是非常大的！
有没有什么检测机制来检测当前是否在进行垃圾回收呢？
1，就是在3-4秒不能刷数据的时候抓dump，然后stack中有没有gc的线程做collection.可以用procdump或ADPlus来抓http://support.microsoft.com/kb/286350ADPlus-hang-pnmyapp.exehttp://technet.microsoft.com/en-us/sysinternals/dd996900.aspxprocdump-mapid但是就算你看到GC在collection也不会说明什么问题,,可能是正常情况下的一次GC活动，这个时候你要看一下performancecount"%TimeinGC",看看在那段3-4秒时间内GC花了多少时间。2,CPU不高似乎UI线程在等待什么，但并不能排除“死循环”（长时间的循环也算作死循环），除非你是单核的机子。AAnyway,这个时候用上面的DUMP看一下UI线程在做什么。
解决方案十二：
tippler59hgg
解决方案十三：
我也是这样练习多线程的。。。。不过，写完虽然正常，但我感觉下，这不是真正的“多线程”，如sp123所说。为实现功能造成很多的阻塞状态，，
解决方案十四：
这个问题还没有解决要是有类似经验的人希望可以指点一下谢谢了自己顶一下给我的感觉就是感觉系统资源不够用了因一开始卡的时候界面操作都很卡
解决方案十五：
一般来说cpu占用不高，如果不是IO密集型程序，说明你的程序工作效率低。即使用了很多线程，可能大家都是懒懒地等在那里不工作。所谓死锁，可以理解成互相扯皮，谁都说要先等别人做了什么什么自己才肯往下干。这种情况可能是由于过度设计、系统过于错综复杂，给了每个线程不工作的借口，或者一个线程的错误造成对整个系统的影响。如果是这种器质性问题，应当重新简化设计，让每个线程的工作不依赖其它线程的协作。可以先做一些性能测试：在vs中选ANALYZE->Profiler->NewPerformanceSession。先找到时间都消耗在哪些地方，然后再分析原因。如果最耗时的是Wait这样的方法，就说明大部分时间是磨洋工空耗掉的。应该不用或慎用lock，wait这样的方法。
其他方案：
其他方案：
之前在学校做过一个类似的。Winform监听某个端口，作为服务端。然后通过线程进行处理。优化的话你直接去优化线程的逻辑吧
其他方案：
看你这个描述代码有问题。
其他方案：
多线程的程序出问题，是很难查的，错综复杂的调用，跟踪都是问题。我的经验是打日志，带上线程号，然后整理日志文件，这样可以看出某个线程执行方法的轨迹和其他信息。另外，你可以用一些profile的监控工具，看看性能耗损在哪些方法上
其他方案：
写日志，跟踪每一步
其他方案：
或许有可能是你的机器中毒啦，某个硬件过热啦，正好碰到有些软件自动更新自动安装程序自动发送数据啦，这些程序外的因素也有可能发生。
其他方案：
按我的做法是，如果要做多线程，那么就保证每个线程的数据都是自己的，不要让多个线程共同读写同一个数据，死锁是非常非常郁闷的事。测试的话，一个是打log，另一个就是暂停不相干的线程，单独测试。尽可能保证线程的独立，这样安全才有保证
其他方案：
一般来说cpu占用不高，如果不是IO密集型程序，说明你的程序工作效率低。即使用了很多线程，可能大家都是懒懒地等在那里不工作。所谓死锁，可以理解成互相扯皮，谁都说要先等别人做了什么什么自己才肯往下干。这种情况可能是由于过度设计、系统过于错综复杂，给了每个线程不工作的借口，或者一个线程的错误造成对整个系统的影响。如果是这种器质性问题，应当重新简化设计，让每个线程的工作不依赖其它线程的协作。可以先做一些性能测试：在vs中选ANALYZE->Profiler->NewPerformanceSession。先找到时间都消耗在哪些地方，然后再分析原因。如果最耗时的是Wait这样的方法，就说明大部分时间是磨洋工空耗掉的。应该不用或慎用lock，wait这样的方法。
其他方案：
你的线程有操作界面的化，界面不单止会卡，还有可能随时崩溃的，要用委托实现跨线程调用
其他方案：
如果内存没有快到物理内存的上限,那十有八九是程序的逻辑问题
其他方案：
1.使用线程池,而不是自己开N多线程去处理,这样你不需要自己维护队列2.如果非要自己开线程,不要用什么"信号量"来做同步,多线程访问队列加锁控制即可
其他方案：
没代码贴出来都是瞎说
其他方案：
vs有自带的性能分析工具，你程序跑一段时间，抓一个快照文件下来打开看看，哪个地方占用cpu了，一目了然，这种问题光凭猜测是没得用得
其他方案：
没有性能图表...不好分析,没有程序背景介绍..1.你是否用了线程池,2.每个任务(可能是IO长时间任务)是否新启一个线程3.线程里是否有循环状态查看,一直等待情况.5.可以用procexp之类的.看一下程序状态.然后分析.或者让大家帮你看看.6.多线程性能低,一般是IO操作挂起,号时线程数很多.导致的.