C#多线程解决界面卡死问题的完美解决方案 文章下最方有源码下载 问题描述:当我们的界面需要在程序运行中不断更新数据时, 当一个textbox的数据需要变化时, 对于这个问题可以先参考下我的另外一个文章 C#多线程|匿名委托传参数|测试您的网站能承受的压力|附源代码--升级版 为了让程序执行中不出现界面卡死的现像,最好的方法就是多线程来解决一个主线程来创建界面,使用一个子线程来执行程序并更新主界面这样就不会出现卡死的现像了这肯定是没有问题的,但是为什么在使用的过程中一样会有很多地方会出现卡死呢,而

用DataGridView无分页绑定一个几千条数据的查询,查询的时候界面直接卡死十几秒,用户体验非常不好,因此用异步操作解决界面卡死的问题原本场景:点击[查询]后,界面直接卡死优化场景:点击[查询]后,界面可以随意移动,感觉不到后台在做大量数据的读取和绑定 private void btnQuery_Click(object sender, EventArgs e) { // 查询按钮点击后,按钮文本由"查询"改为"加载中",并把按钮状态改为不可点击 btnQuer

QThread的常见特性: run()是线程的入口,就像main()对于应用程序的作用.QThread中对run()的默认实现调用了exec(),从而创建一个QEventLoop对象,由其处理该线程事件队列(每一个线程都有一个属于自己的事件队列)中的事件.简单用代码描述如下: 1 int QThread::exec() 2 { 3 //... 4 QEventLoop eventLoop; 5 int returnCode = eventLoop.exec(); 6 //... 7 return

原文:C# Winform 窗体界面"假死"后台线程阻塞 解决办法–BeginInvoke 这个方法可以用在任何后台任务耗时较长,造成界面“假死”界面控件不更新的情况. 比如要要执行的数据库操作是几十万条的update语句,如果在click事件里阻塞或者做Thread.Sleep或一个耗时很长的操作,窗口就会无响应点不动了.故需要用this.BeginInvoke方法来异步执行UI线程的操作,更新界面显示. //导入按钮点击事件 private void btn_import_Clic

c#中可以用BeginInvoke去启动异步调用,但是有两个BeginInvoke一个是controller的BeginInvoke还有一个是委托的BeginInvoke. 主要区别是controller的BeginInvoke会返回到主线程中执行.如果在Winform中使用了controller得BeginInvoke去执行一些费时的操作任然会使界面假死. controller的BeginInvoke使用方法是先定义一个委托 如 delegate void UpdateUI(string s)

故事的开端是这样的,小白是一个程序员,他确实也是一个小白,目前还在程序员发展的道路上,兢兢业业的小心求学. 有一天,小白接到一个任务,完成一个Winform程序,附加一个功能就是可以读IC卡. 小白终于有机会一展身手了!!不免内心兴奋. 再联系了IC卡厂家,拿到开发SDK后,小白不久就碰到了以下难题: 1.厂家的读卡器是通过API给定的事件ReadCard()驱动的,而读卡器在ReadCard事件驱动以后,可以在往后的3s以内侦测是否有IC卡片在附近: (1)3s内,有IC卡在设备附近,立即读卡

最近一个项目需求中的一个功能是需要用progressBar反映处理文件的进度. 研究了Invoke和BeginInvoke方法. Control.Invoke 方法 (Delegate) :在拥有此控件的基础窗口句柄的线程上执行指定的委托. Control.BeginInvoke 方法 (Delegate) :在创建控件的基础句柄所在线程上异步执行指定委托. 我开始的想法是开一个线程处理,代码如下: private delegate void DoDataDelegate(object numb

http://www.cnblogs.com/Charltsing/p/publisher.html 最近测试task并发任务的效率与线程池的区别,发现了另外一个问题.task建立任务的速度很快,输出到UI的信息过频,导致UI假死. private void TestMakeTasks(object obj) { string msg = ""; //循环创建task for (int i = 0; i < 3000; i++) { //主线程(winform)--子线程(Thr

首先要检查那些滥用 Timer.Dispacher Timer 或者滥用什么“线程+死循环+阻塞”轮询的代码. 这种是编程大忌,有些人不会设计事件驱动程序,而是滥用轮询. 若是:触发事件后的假死,搜WPF  Dispatcher

当有大量数据需要计算.显示在界面或者调用sleep函数时,容易导致界面卡死,可以采用多线程加委托的方法解决. using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using Syste

当有大量数据需要计算.显示在界面或者调用sleep函数时,容易导致界面卡死,可以采用多线程加委托的方法解决 using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System

用户控件中有一个树,窗体使用了这个控件,但是重命名时执行node.text="XXXX" 执行了很长时间,大约9s,在此期间winform界面假死,尝试过多线程异步委托的方式来操作, 还是假死 再次单步调试,虽然树节点绑定了很多事件,但都是很快就执行完毕的,树是一次加载的,数据量比较大,大约7w个节点,用dot trace跟踪了一下,得到如下结果 -9,309ms System.Windows.Forms.TreeNode.set_Text(String) --9,309ms Syst

1. 问题的出现过程 最近博主自己用的 windows10 系统就碰到了这个问题. 一开始出现这个问题的征兆是鼠标会时不时地卡顿,一出现卡顿就会等个 1-3秒才能动.然后频繁卡顿(注意,这里根据经验就怀疑是硬盘读写有问题,但不一定是物理损坏,而有可能是驱动) 然后这个现象持续了大概有20分钟左右(此时我电脑上还跑着虚拟机任务,大量浏览器窗口,编辑器 和 SSH等等),终于卡的不能动了,然后就屏幕一黑. 注意,此时千万不要心急直接长按关机键重启,即使系统出了点问题也不代表就是不可恢复的问题,而如果

最近一直在写一个winform程序,对各类文档文件,以及压缩包的内容进行关键字检测. 模型出来之后,执行了一下,发现连续测试后,会有内存不足的问题,导致程序面假死.脑袋懵逼了两天. 回头看我的变量容器List,使用的是静态变量,思路如下: 上图是修改之后的  最初为  : private static List<Inform_Model> Model_List =new List<Inform_Model>(); 但是! static静态全局变量的生命周期是跟随程序结束而GG的:

在GIS数据处理中,数据量大是一个非常伤脑筋的问题.最近,在写一个CAD注记转Shapefile文件时,又遇到这个问题. 曾经处理一次数据,达130万个点,即测试区域内的栅格转成点全部处理,程序是写好了,但速度之慢啊,关键问题是处理到一半报奇怪的错误,最后只好将数据分成6份,去实验室开了6台机子来分别处理,最后合成在一起.经历过这件事后,我就去请教老师,他们在用程序处理GIS大数据时(特别是当数据带有空间信息),怎么来解决类似的问题?他总结了两方面:一是硬件上,配置要高,对于特别大的数据考虑使用

原文地址:https://www.cnblogs.com/wangchuang/archive/2013/02/20/2918858.html .c# Invoke和BeginInvoke 区别 Control.Invoke 方法 (Delegate):在拥有此控件的基础窗口句柄的线程上执行指定的委托. Control.BeginInvoke 方法 (Delegate) :在创建控件的基础句柄所在线程上异步执行指定委托. 以下为实际应用中碰到的问题,在主线程中启动一个线程,然后在这个线程中启动s

1.问题描述 在使用net-snmp对交换机进行扫描的时候经常会出现进程假死的情况(就是进程并没有死掉,但是看不到它与外界进行任何的数据交互).这时候不知道进程内部发生了什么,虽然有日志信息,但进程已经很长时间没有动静,根本不知道这段时间做了什么.用gdb att进去发现,进行snmp发送的线程已经被阻塞了.但是阻塞的情况并不是每次都发生,而是经常发生,这就导致很难捕捉问题.通过观察日志和 tcpdump 抓包,发现这种情况只在v3版本的时候出现,那就是v3版本有什么特别的地方. 2.调试跟踪

转自:http://www.cnblogs.com/smartls/archive/2011/04/08/2008981.html#2457370   引言 在之前的<创建无阻塞的异步调用>中,已经介绍过异步调用的编写步骤和实施原理.异步调用是CLR为开发者提供的一种重要的编程手段,它也是构建高性能.可伸缩应用程序的关键.在多核CPU越来越普及的今天,异步编程允许使用非常少的线程执行很多操作.我们通常使用异步完成许多计算型.IO型的复杂.耗时操作,去取得我们的应用程序运行所需要的一部分数据.在

异步调用是CLR为开发者提供的一种重要的编程手段,它也是构建高性能.可伸缩应用程序的关键.在多核CPU越来越普及的今天,异步编程允许使用非常少的线程执行很多操作.我们通常使用异步完成许多计算型.IO型的复杂.耗时操作,去取得我们的应用程序运行所需要的一部分数据.在取得这些数据后,我们需要将它们绑定在UI中呈现.当数据量偏大时,我们会发现窗体变成了空白面板.此时如果用鼠标点击,窗体标题将会出现”失去响应”的字样,而实际上UI线程仍在工作着,这对用户来说是一种极度糟糕的体验.如果你希望了解其中的原因

大部分半卡死的现象是因为Dynamic Tick的一个Bug.Dynamic Tick是NT 6.2内核的一个新功能(其实Linux早就有了),原理的话大概是在空闲的时候把CPU完全暂停,来节省电量.但是貌似这个技术还不是很成熟,对“空闲”的判断有时候会出错,所以正常使用的时候CPU也可能会暂停,出现假死.RP出过一个补丁修复过一次,但是貌似还是没有完全修复. 解决办法就是把它关掉,关掉之后内核的行为就回到Win7的样子了.所以还是会和Win7一样费电,但是应该就不会假死了. 关闭的方法:用管理

使用windows server 2008 r2解决回收假死的问题. 具体做法是: 打开应用程序池 -> 高级设置 ->在“禁止重叠回收”里选择“true”,这样就有效避免了应用程序池回收假死问题.