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

公司内部一个项目是用WPF作为GUI 访问web接口的形式获取数据, 但是由于数据量比较大,也没做分页,于是就需要一个loading的控件,网上查了很多资料但都比较浅.这里完成需求后,总结一下. 首先.loading控件的实现基本上都是1.控件显示:2.后台访问查询:3.UI渲染:4.控件隐藏. 想要实现这部分,需要做到异步,这里使用BackgroundWorker 组件用来执行诸如数据库事务.文件下载等耗时的异步操作. 关于backgroundWorker这里不做过多的记录,已经有很多人进行了

UI卡顿假死问题 误区1:使用不同的线程操作UI控件和耗时操作(即,跨线程操作UI控件CheckForIllegalCrossThreadCalls = false;), 注意:此处只是为了记录...... 原始同步操作如下所示: private void button1_Click(object sender, EventArgs e) { Waintting waitting = new Waintting(); waitting.Show(); Thread.Sleep(5000);//模

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.Data.SqlClient; using System.Text.RegularExpressions;

如果是asp.net页面 public override void VerifyRenderingInServerForm(Control control)    {} 如果是Sharepoint web part: <asp:Button ID="btnExportToExcel" runat="server" Text="Export to Excel" onclick="btnExportToExcel_Click"

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

1    问题源起 上游系统通过公司rpc框架调用我们系统接口超时(默认超时时间为100ms)数量从50次/分突然上涨到2000次/分,在发生变化时间段里我们的系统也没有做过代码变更,但上游系统的调用确发生了变化.由于处于主要链路上,sre同学找过来询问原因,所以开始了问题排查. 2    问题初步定位 排查rpc超时的基本思路是这样的: 1)        服务端处理确实超时 2)        服务端或者客户端由于某种原因卡住 a)         磁盘清理 b)        tr线程池

原因: 一般来说,一个WPF窗口程序,只有一个UI线程, 如果这个线程停在某个函数,UI将会被阻塞,所有其他的界面操作都不能即时响应. 解决方案: 新开一个线程来执行耗时较长的操作,以不阻塞UI.

一.背景 redis慢日志分析平台上线后,随便看了一下,发现onestore使用的缓存集群,存在大量的EXISTS命令慢查询的情况: 平均每个EXISTS命令需要13ms,最大耗时近20ms.这个结果很不科学啊,EXISTS命令只是执行一次hash查找操作,应该是us级别. 和相关同学了解业务背景如下: - 业务是userfeed,存放用户发表的动态 - 使用zset存储一个用户发表的所有动态,key是用户id,集合中对应的是feedid.如果用户发表的动态很多,zset也很大 - redis集

问题   前几天,同事遇到一个浏览器假死的问题.就是浏览器在响应一个请求的时候,就突然不响应时间,进入假死状态,Cup也飙升到100%. 但是这个问题只出现在IE浏览器,chrome和Firefox等其他浏览器正常. 原因 Js 代码里面,看着也没有什么耗时的操作和后台异步调用.没办法,只能从响应事件的最开始一步一步调查.经过一番调试之后,问题定位在setTimeout 函数.当把setTimeout 里面执行的函数去掉之后,立马就不会出现这种情况.查看setTimeout 里面调用的函数,发现

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

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

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

WinForm窗体在使用过程中如果因为程序等待时间太久而导致窗体本身假死无法控制,会严重影响用户的体验,这种情况大多是UI线程被耗时长的代码操作占用所致,可以新开一个线程用来完成耗时长的操作,然后再将结果返回到UI中呈现,这样就不会占用到UI线程了,也就不会假死了,涉及Control的更新需要用到BeginInvoke方法 private void button1_Click(object sender, EventArgs e) { Thread t1 = new Thread(delegat

转载:http://www.cnblogs.com/smartls/archive/2011/04/08/2008981.html 异步调用是CLR为开发者提供的一种重要的编程手段,它也是构建高性能.可伸缩应用程序的关键.在多核CPU越来越普及的今天,异步编程允许使用非常少的线程执行很多操作.我们通常使用异步完成许多计算型.IO型的复杂.耗时操作,去取得我们的应用程序运行所需要的一部分数据.在取得这些数据后,我们需要将它们绑定在UI中呈现.当数据量偏大时,我们会发现窗体变成了空白面板.此时如果用

1.方法一:使用线程 功能描述:在用c#做WinFrom开发的过程中.我们经常需要用到进度条(ProgressBar)用于显示进度信息.这时候我们可能就需要用到多线程,如果不采用多线程控制进度条,窗口很容易假死(无法适时看到进度信息).下面我就简单结合一个我写的例子给大家做一个介绍. 第一步:设计界面,注意需要引用 using System.Threading; 控件名称分别为: progressBar1:label1:textBox1:button1: 第二步:定义一个代理,用于更新Progr

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

服务器配置:linux+tomcat 现象:Linux服务器没有崩,有浏览器中访问页面,出现无法访问的情况,没有报4xx或5xx错误(假死),并且重启tomcat后,恢复正常. 原因:tomcat默认最大连接数(线程数)200个,默认每一个连接的生命周期2小时(7200秒),tomcat使用http 1.1协议,而http1.1默认是长连接.tomcat接受处理完请求后,socket没有主动关闭,因此如果在2小时内,请求数超过200个,服务器就会出现上述假死现象. 解决方案1:及时断开socke

使用Tomcat作为Web服务器的时候偶尔会遇到Tomcat停止响应的情况,通过netstat查看端口情况会发现tomcat的端口出现大量的CLOSE_WAIT,此时Tomcat会停止响应前端请求,同时服务端的日志,操作等将全部停止,而且没有出现任何异常,此时就需要排查是哪方面的原因,此案以以前的解决为例总结排查方案

china_xuhua 原文地址 1.方法一:使用线程 功能描述:在用c#做WinFrom开发的过程中.我们经常需要用到进度条(ProgressBar)用于显示进度信息.这时候我们可能就需要用到多线 程,如果不采用多线程控制进度条,窗口很容易假死(无法适时看到进度信息).下面我就简单结合一个我写的例子给大家做一个介绍. 第一步:设计界面,注意需要引用 using System.Threading; 控件名称分别为: progressBar1:label1:textBox1:button1: 第二