来源于:http://topic.csdn.net/t/20060413/14/4684297.html
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,目前我还没有遇到过。
有没有遇到类式问题的朋友???? 给点参考意见啊
两天之内,无论如何,结贴,希望在结贴之前能有更好的处理方案
--
如果此问题无法避免,打算在程序中开三个专用timer: 来自System,Thread,Form
3个timer互相监视,并统一触犯事件,检测系统中的所有timer的状态,发现问题,重启。
虽然感觉这种方式有点弱智
--
为什么不用Thread来代替呢。
Timer需要Message来响应,即是被动触发,当系统cpu资源紧张的时候,就会出现你上面的现象。
--
回愚翁:
用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%的出错记录,今天下午点鼠标都要点疯了:(
--
to lw8122(随风)
线程写多了,你会发现它的好处,其实处理并不复杂,而且控制权在你手中。
--
to: 愚翁
线程,我已经用得非常多了,并且在手动制造的最恶劣的环境(不停止的疯狂连接,导致未执行完的线程不断堆积)中出现了BUG。
于是做测试代码,测试结果:在一个程序中(也可能是一个主线程中,但我没试两个主线程中大量开线程),开启线程的最大数量为1800多个(注:这里我所说的线程,是指开启,并且未执行完毕的线程),然后再开就会失败。
但把这个程序开N个,那么N个程序都会在1800多个子线程时出错。
于是,做了容错代码,在线程达到500个的时候,不再允许连接。 直到线程低于500个时,再继续允许连接:)
--
基本有了结论。
System.timer的确有可能在资源过大的情况下停掉, Thread.timer和form.timer目前都没有停过。
今天再继续测试,如果到下班form.timer都还无问题,以后就全部改用form.timer了
以下是我花1小时写的测试timer开启情况的源代码,一台PC上开10个,然后监视三种timer的启动情况
每一个timer,在执行3次后,将被重启。tmTotal用于统计每个timer重新开启的次数,当一个timer不执行时,就说明出问题了
代码基本无注释,大家有兴趣就研究一下吧。
--
用程序做了测试,结论:
System.timer是最不稳定的,在系统资源大的时候,有可能会在开启的时候失效,几率不大,几千分之一。
而Form.timer和Thread.timer,则没有任何问题,开启一定成功。
将把程序中的System.timer全部换为Form.timer,解决些问题。
结贴
----
system.timer没有 System.Threading.Timer 好用
来源于:http://blog.sina.com.cn/s/blog_62c501440100fog1.html
System.Threading.Timer 是一个非常常用的定时器类,关于这个类的使用,我们需要注意以下几点: