C#的System.Timer之BUG，已想法避免，大家遇到过没有？？？？

Question

System.Timer，通常执行正常。但是在系统资源（CPU）占用比较厉害的时候，有可能System.Timer.Enabled=true后，并不产生作用。
也有可以执行几次后，就不再执行了。出现在几率大概在0.5%左右我的程序中还有Form.Timer，现在用Form.Timer附带做了对此System.timer的监视，发现问题，则写日志，并执行：System.Timer.Enabled=false
System.Timer.Enabled=true;暂时避免了此BUG带来的不良影响，正在测试发生此种问题的根源，以找到更好的方式来避免。但是，还不知道form.timer是否也会存在这种BUG，目前我还没有遇到过。有没有遇到类式问题的朋友？？？？ 给点参考意见啊两天之内，无论如何，结贴，希望在结贴之前能有更好的处理方案

Answer 1

如果此问题无法避免，打算在程序中开三个专用timer： 来自System，Thread,Form3个timer互相监视，并统一触犯事件，检测系统中的所有timer的状态，发现问题，重启。虽然感觉这种方式有点弱智

Answer 2

为什么不用Thread来代替呢。
Timer需要Message来响应，即是被动触发，当系统cpu资源紧张的时候，就会出现你上面的现象。

Answer 3

回愚翁：用Timer，感觉写代码要方便一些。 当Timer的指针丢失的时候，Timer执行会自动被干掉，而Thread的运行，必须要想办法对它停止才行。当然，使用起来，关闭Thread也没有程序难度。用（Timer间隔调用），或是（用Thread，通过循环并且Sleep进行调用），当资源（比如CPU）占用高的时候，都会出现实际间隔比指定的间隔时间大很多的情况。这个我在很久以前就测试过了但是在实际使用中，这个影响不会很大。 比如，指定5秒的间隔，实际上由于资源方面的情况，间隔了50秒，也不会影响程序的正常运行，完全可以接受。但是，居然Timer会执行停，比如：
1、timer在start之后，一次事件都不触发
2、timer在start之后，触发几次之后，就不再触发事件了这就是我以前完全没有考虑到的问题。 现在的程序中有十多个System.Timer，全部用保护代码做重启动timer处理，代码量还是比较大的。打算先写的个循环测试System.timer开启的程序，看看有无办法在开timer时的代码方面做一些改动，杜绝这种情况的发生。现在手动一次一次开程序测试，面对差不多0.5%的出错记录，今天下午点鼠标都要点疯了:(

Answer 4

to lw8122(随风)线程写多了，你会发现它的好处，其实处理并不复杂，而且控制权在你手中。

Answer 5

to： 愚翁线程，我已经用得非常多了，并且在手动制造的最恶劣的环境（不停止的疯狂连接，导致未执行完的线程不断堆积）中出现了BUG。于是做测试代码，测试结果：在一个程序中（也可能是一个主线程中，但我没试两个主线程中大量开线程），开启线程的最大数量为1800多个（注：这里我所说的线程，是指开启，并且未执行完毕的线程），然后再开就会失败。但把这个程序开N个，那么N个程序都会在1800多个子线程时出错。于是，做了容错代码，在线程达到500个的时候，不再允许连接。 直到线程低于500个时，再继续允许连接:)

Answer 6

基本有了结论。System.timer的确有可能在资源过大的情况下停掉， Thread.timer和form.timer目前都没有停过。今天再继续测试，如果到下班form.timer都还无问题，以后就全部改用form.timer了以下是我花1小时写的测试timer开启情况的源代码，一台PC上开10个，然后监视三种timer的启动情况每一个timer，在执行3次后，将被重启。 tmTotal用于统计每个timer重新开启的次数，当一个timer不执行时，就说明出问题了代码基本无注释，大家有兴趣就研究一下吧。http://supermail.263.net/cgi-bin/supermail.fcg?func=downfile&ip=MTQ5ODg5Mg==&ipfrom=bGl1d2VpMjAwMA==

Answer 7

用程序做了测试，结论：System.timer是最不稳定的，在系统资源大的时候，有可能会在开启的时候失效，几率不大，几千分之一。而Form.timer和Thread.timer，则没有任何问题，开启一定成功。将把程序中的System.timer全部换为Form.timer，解决些问题。结贴