C#中利用委托实现多线程跨线程操作
在使用VS2005的时候，如果你从非创建这个控件的线程中访问这个控件或者操作这个控件的话就会抛出这个异常。这是微软为了保证线程安全以及提高代码的效率所做的改进，但是也给大家带来很多不便。
其实解决这个问题有两种方法：
一，是通过设置
System.Windows.Forms.Control.CheckForIllegalCrossThreadCalls = false;
在你的程序初始化的时候设置了这个属性，而且在你的控件中使用的都是微软Framework类库中的控件的话，系统就不会再抛出你上面所说的这个错误了。
二，就是委托了，个人建议用这种方法
首先在WinForm窗体中拖入ListBox控件，然后参照以下代码：
其实解决这个问题有两种方法：
一，是通过设置
System.Windows.Forms.Control.CheckForIllegalCrossThreadCalls = false;
在你的程序初始化的时候设置了这个属性，而且在你的控件中使用的都是微软Framework类库中的控件的话，系统就不会再抛出你上面所说的这个错误了。
二，就是委托了，个人建议用这种方法
首先在WinForm窗体中拖入ListBox控件，然后参照以下代码：
Thread t1;//声明一个全局线程
delegate void aa();
private void Form1_Load(object sender, EventArgs e)
{
t1 = new Thread(new ThreadStart(BackgroundProcess));
t1.Start(); //开始
}
private void BackgroundProcess()
{
// 将委托实例化
aa a= delegate()
{
for (int i = 0; i < 50; i++)
{
listBox1.Items.Add("Iterations: " + i.ToString());
Thread.Sleep(300);
listBox1.Refresh();
}
};
listBox1.Invoke(a);
}
来源：http://www.huomo.cn/developer/article-1aa8.html
C#多线程操作界面控件的解决方案
我们在做winform应用的时候，大部分情况下都会碰到使用多线程控制界面上控件信息的问题。然而我们并不能用传统方法来做这个问题，下面我将详细的介绍。
首先来看传统方法：
public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { Thread thread = new Thread(ThreadFuntion); thread.IsBackground = true; thread.Start(); } private void ThreadFuntion() { while (true) { this.textBox1.Text = DateTime.Now.ToString(); Thread.Sleep(1000); } } }
运行这段 代码，我们会看到系统抛出一个异常：Cross-thread operation not valid:Control 'textBox1' accessed from a thread other than the thread it was created on . 这是因为.net 2.0以后加强了安全机制，不允许在winform中直接跨线程访问控件的属性。那么怎么解决这个问题呢，下面提供几种方案。
第一种方案，我们在Form1_Load()方法中加一句代码：
private void Form1_Load(object sender, EventArgs e) { Control.CheckForIllegalCrossThreadCalls = false; Thread thread = new Thread(ThreadFuntion); thread.IsBackground = true; thread.Start(); }
加入这句代码以后发现程序可以正常运行了。这句代码就是说在这个类中我们不检查跨线程的调用是否 合法（如果没有加这句话运行也没有异常，那么说明系统以及默认的采用了不检查的方式）。然而，这种方法不可取。我们查看 CheckForIllegalCrossThreadCalls 这个属性的定义，就会发现它是一个static的，也就是说无论我们在项目的什么地方修改了这个值，他就会在全局起作用。而且像这种跨线程访问是否存在异 常，我们通常都会去检查。如果项目中其他人修改了这个属性，那么我们的方案就失败了，我们要采取另外的方案。
下面来看第二种方案，就是使用delegate和invoke来从其他线程中控制控件信息。网上有很多人写了这种控制方式，然而我看了很多这种帖子，表明上看来是没有什么问题的，但是实际上并没有解决这个问题，首先来看网络上的那种不完善的方式：
public partial class Form1 : Form { private delegate void FlushClient();//代理 public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { Thread thread = new Thread(CrossThreadFlush); thread.IsBackground=true; thread.Start(); } private void CrossThreadFlush() { //将代理绑定到方法 FlushClient fc = new FlushClient(ThreadFuntion); this.BeginInvoke(fc);//调用代理 } private void ThreadFuntion() { while (true) { this.textBox1.Text = DateTime.Now.ToString(); Thread.Sleep(1000); } } }
使用这种方式我们可以看到跨线程访问的异常没有了。但是新问题出现了，界面没有响应了。为什么会出现这个问题，我们只是让新开的线程无限循环刷新，理论上 应该不会对主线程产生影响的。其实不然，这种方式其实相当于把这个新开的线程“注入”到了主控制线程中，它取得了主线程的控制。只要这个线程不返回，那么 主线程将永远都无法响应。就算新开的线程中不使用无限循环，使可以返回了。这种方式的使用多线程也失去了它本来的意义。
现在来让我们看看推荐的解决方案：
public partial class Form1 : Form { private delegate void FlushClient();//代理 public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { Thread thread = new Thread(CrossThreadFlush); thread.IsBackground = true; thread.Start(); } private void CrossThreadFlush() { while (true) { //将sleep和无限循环放在等待异步的外面 Thread.Sleep(1000); ThreadFunction(); } } private void ThreadFunction() { if (this.textBox1.InvokeRequired)//等待异步 { FlushClient fc = new FlushClient(ThreadFunction); this.Invoke(fc);//通过代理调用刷新方法 } else { this.textBox1.Text = DateTime.Now.ToString(); } } }
运行上述代码，我们可以看到问题已经被解决了，通过等待异步，我们就不会总是持有主线程的控制，这样就可以在不发生跨线程调用异常的情况下完成多线程对winform多线程控件的控制了。
对于深山老林提出的问题,我最近找到了更优的解决方案,利用了delegate的异步调用，大家可以看看：
public partial class Form1 : Form { private delegate void FlushClient();//代理 public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { Thread thread = new Thread(CrossThreadFlush); thread.IsBackground = true; thread.Start(); } private void CrossThreadFlush() { FlushClient=new FlushClient(ThreadFunction); FlushClient.BeginInvoke(null,null); } private void ThreadFunction() { while (true) { this.textBox1.Text = DateTime.Now.ToString(); Thread.Sleep(1000); } } }
这种方法也可以直接简化为(因为delegate的异步就是开了一个异步线程):
public partial class Form1 : Form { private delegate void FlushClient();//代理 public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { Thread thread = new Thread(CrossThreadFlush); FlushClient=new FlushClient(ThreadFunction); FlushClient.BeginInvoke(null,null); } private void ThreadFunction() { while (true) { this.textBox1.Text = DateTime.Now.ToString(); Thread.Sleep(1000); } } }
public partial class Form1 : Form
{
private delegate void ThreadWork(int i);
Thread thread;
public Form1()
{
InitializeComponent();
// CheckForIllegalCrossThreadCalls = false;
}
private void button1_Click(object sender, EventArgs e)
{
this.richTextBox1.Text = "程序开始： ";
UpdateText();
}
public void UpdateText()
{
thread = new Thread(new ThreadStart(CrossThreadFlush));
thread.IsBackground = true;
thread.Start();
}
private void CrossThreadFlush()
{
while (true)
{ //将sleep和无限循环放在等待异步的外面
for (int i = 1; i < 100; i++)
{
ThreadFunction(i);
Thread.Sleep(500);
}
}
}
private void ThreadFunction(int i)
{
if (this.richTextBox1.InvokeRequired)//等待异步
{
ThreadWork fc = new ThreadWork(ThreadFunction);
// this.Invoke(fc);//通过代理调用刷新方法
this.Invoke(fc, new object[1] { i });
}
else
{
this.richTextBox1.Text = string.Format("第{0}个 {1:mm-ss} ", i, DateTime.Now) + this.richTextBox1.Text;
this.richTextBox1.Refresh();
}
}
}
}
{
private delegate void ThreadWork(int i);
Thread thread;
public Form1()
{
InitializeComponent();
// CheckForIllegalCrossThreadCalls = false;
}
private void button1_Click(object sender, EventArgs e)
{
this.richTextBox1.Text = "程序开始： ";
UpdateText();
}
public void UpdateText()
{
thread = new Thread(new ThreadStart(CrossThreadFlush));
thread.IsBackground = true;
thread.Start();
}
private void CrossThreadFlush()
{
while (true)
{ //将sleep和无限循环放在等待异步的外面
for (int i = 1; i < 100; i++)
{
ThreadFunction(i);
Thread.Sleep(500);
}
}
}
private void ThreadFunction(int i)
{
if (this.richTextBox1.InvokeRequired)//等待异步
{
ThreadWork fc = new ThreadWork(ThreadFunction);
// this.Invoke(fc);//通过代理调用刷新方法
this.Invoke(fc, new object[1] { i });
}
else
{
this.richTextBox1.Text = string.Format("第{0}个 {1:mm-ss} ", i, DateTime.Now) + this.richTextBox1.Text;
this.richTextBox1.Refresh();
}
}
}
}
文章摘自：
C #中的几个线程同步对象方法
- 张小鱼 2010-10-22 08:40
在编写多线程程序时无可避免会遇到线程的同步问题。什么是线程的同步呢？
举 个例子：如果在一个公司里面有一个变量记录某人T的工资count=100，有两个主管A和B（即工作线程）在早一些时候拿了这个变量的值回去 ，过了一段时间A主管将T的工资加了5块，并存回count变量，而B主管将T的工资减去3块，并存回count变量。好了，本来T君可以得到102块的 工资的，现在就变成98块了。这就是线程同步要解决的问题。
在C#里面用于实现线程同步的常用类有如下几类 1、Mutex类（互斥器），Monitor类，lock方法
2、ManualResetEvent类，AutoResetEvent类（这两个都是由EventWaitHandle类派生出来的）
3、ReaderWriterLock类
同 一类的作用都差不多：其中 代码执行为止。就好比一堆人同时上一个公共厕所一样，使用这个方法就可以解决文章一开始时提出的问题：主管A要处理T君的工资之前，先lock一下T君， 然后取出目前的count值，处理完之后再解除T君的锁定。如果主管B在主管A处理工资时也想取出count值，那么它只能是一直地等待A处理完之后才能 继续。使用这个方法的一个缺点就是会降低程序的效率。本来是一个多个线程的操作，一旦遇到lock的语句时，那么这些线程只要排队处理，形同一个单线程操 作。
下面举个例子说明一下这三个方法的使用：
假定有一个Tools类，里面一个int变量，还有Add和Delete方法，其中Add方法会使int变量的值增加，Delete方法使int变量值减少：
public class Tools private int count = 100;
public void Add(int n) count+=n;
}
public void Delete(int n) count-=n;
}
在多个线程同时访问这段代码时，因为一个语句会被编译器编译成多个指令，所以会可能出现这种情况：但某个线程调用Add方法时，这时的count值为 100，而正当要加上n的时候，另外一个线程调用了Delete，它要减去m，结果count加上了n，然后又在原先count=100的值的情况
下减掉了m，最后的结果是count被减去了m,而没有加上n。很明显Add方法和Delete方法是不能同时被调用的，所以必须进行线程同步处理。简单的方法是用lock语句：
public class Tools private object abcde = new object();
private int count = 100;
public void Add(int n) lock(abcde) count+=n;
}
public void Delete(int n) lock(abcde) count-=n; }
其中abcde是一个private级的内部变量，它不表示任何的意义，只是作为一种“令牌”的角色。
当执行Add方法中的lock(abcde)方法时，这个令牌就在Add方法的手中了，如果这时有第二个线程也想拿这个令牌，没门，惟有等待。一旦第一
个lock语句的花括号范围结束之后，这时令牌就被释放了，同时会迅速落到第二个线程的手中，并且排除其他后来的人。
使用Monitor类的方法大致一样：
public class Tools private object abcde = new object();
private int count = 100;
public void Add(int n) Monitor.Enter(abcde);
count+=n;
Monitor.Exit(abcde);
}
public void Delete(int n) Monitor.Enter(abcde);
count-=n;
Monitor.Exit(abcde);
}
Monitor的常用方法：Enter和Exit都是静态方法，作用跟lock语句的两个花括号一样。
而使用 Mutex 就不需声明一个“令牌”对象了，但要实例化之后才可以使用：
public class Tools
{
private Mutex mut = new Mutex();
private int count = 100;
public void Add(int n) mut.WaitOne();
count+=n;
mut.ReleaseMutex();
}
public void Delete(int n) mut.WaitOne();
count-=n;
mut.ReleaseMutex();
}
其中的WaitOne为等待方法，一直等到Mutex 被释放为止。初始的情况下，Mutex 对象是处于释放状态的，而一旦执行了WaitOne方法之后，它 就被捕获了，一直到被调用了ReleaseMutex方法之后才被释放。
使用这三种方法都有一个要注意的问题，就是在独占代码段里面如果引起了异常，可能会使“令牌”对象不被释放，这样程序就会一直地死等下去了。
所以要在独占代码段里面处理好异常。例如下面这样的代码就是错误的：
public void Add(int n) try mut.WaitOne();
count+=n; mut.ReleaseMutex(); catch Console.Writeline("error."); }
上面的代码一旦在try和catch里面发生了异常，那么Mutex就不能被释放，后面的程序就会卡死在WaitOne()一行，而应该改成这样：
public void Add(int n) mut.WaitOne();
try count+=n; }
catch Console.Writeline("error."); mut.ReleaseMutex();
}
现在谈一下第二种：
ManualResetEvent类，AutoResetEvent类
上面这两个类都是由EventWaitHandle类派生出来的，所以功能和调用方法都很相似。 举个例子，你想送花给一个MM，托了一个送花的小伙子送了过去，而你希望当MM收到花之后就立即打个电话过去告诉她。
但问题是你不知道花什么时候才送到MM的手里，打早了打迟了都不好，这时你可以使用ManualResetEvent对象帮忙。
当委托小伙子送花过去的时候，使用ManualResetEvent的WaitOne方法进行等待。当小伙子把花送到MM的手中时，再调用一下ManualResetEvent的Set方法，你就可以准时地打电话过去了。
另外ManualResetEvent还有一个Reset方法，用来重新阻断调用者执行的，情况就好比你委托了这个小伙子送花给N个MM，
而又想准时地给这N个MM打电话的情况一样。
using System;
using System.Threading;
public class TestMain private static ManualResetEvent ent = new ManualResetEvent(false);
public static void Main() Boy sender = new Boy(ent);
Thread th = new Thread(new ThreadStart(sender.SendFlower));
th.Start();
ent.WaitOne(); //等待工作
Console.WriteLine("收到了吧，花是我送嘀:)");
Console.ReadLine();
public class Boy ManualResetEvent ent;
public Boy(ManualResetEvent e) ent = e;
}
public void SendFlower() Console.WriteLine("正在送花的途中");
Thread.Sleep(2000);
Console.WriteLine(" 花已经送到MM手中了,boss");
ent.Set(); //通知阻塞程序
}
而AutoResetEvent类故名思意，就是在每次Set完之后自动Reset。让执行程序重新进入阻塞状态。
即AutoResetEvent.Set() 相当于 ManualResetEvent.Set() 之后又立即 ManualResetEvent.Reset()， 举个送花给N个MM的例子：
using System;
using System.Threading;
public class TestMain private static AutoResetEvent ent = new AutoResetEvent(false);
public static void Main() Boy sender = new Boy(ent);
for (int i = 0; i < 3; i++) Thread th = new Thread(new ThreadStart(sender.SendFlower));
th.Start();
ent.WaitOne(); //等待工作
Console.WriteLine("收到了吧，花是我送嘀:) ");
}
Console.ReadLine();
}
public class Boy AutoResetEvent ent;
public Boy(AutoResetEvent e) ent = e;
}
public void SendFlower() Console.WriteLine("正在送花的途中");
Thread.Sleep(2000);
Console.WriteLine(" 花已送到MM手中了,boss");
//通知阻塞程序,这里的效果相当于 ManualResetEvent的Set()方法+Reset()方法
ent.Set();
}
要注意的是ManualResetEvent和AutoResetEvent 的构造函数都有一个bool的参数，用这个参数可以指定初始情况下，同步对象的处于阻塞（设置为false）还是非阻塞（设置为true）的状态。
另外WaitOne方法也可以带两个参数：
WaitOne (int millisecondsTimeout,bool exitContext)
millisecondsTimeout：等待的毫秒数，或为 Timeout.Infinite (-1)，表示无限期等待。
exitContext：为 true，则等待之前先退出上下文的同步域（如果在同步上下文中），然后在稍后重新获取它；否则为false。
就是说，等待是可以加上一个期限的，如果等待的同步对象一直都不Set()的话，那么程序就会卡死，所以在WaitOne方法里面可以放置一个时间期限，单位是毫秒。
举 个例子：如果在一个公司里面有一个变量记录某人T的工资count=100，有两个主管A和B（即工作线程）在早一些时候拿了这个变量的值回去 ，过了一段时间A主管将T的工资加了5块，并存回count变量，而B主管将T的工资减去3块，并存回count变量。好了，本来T君可以得到102块的 工资的，现在就变成98块了。这就是线程同步要解决的问题。
在C#里面用于实现线程同步的常用类有如下几类 1、Mutex类（互斥器），Monitor类，lock方法
2、ManualResetEvent类，AutoResetEvent类（这两个都是由EventWaitHandle类派生出来的）
3、ReaderWriterLock类
同 一类的作用都差不多：其中 代码执行为止。就好比一堆人同时上一个公共厕所一样，使用这个方法就可以解决文章一开始时提出的问题：主管A要处理T君的工资之前，先lock一下T君， 然后取出目前的count值，处理完之后再解除T君的锁定。如果主管B在主管A处理工资时也想取出count值，那么它只能是一直地等待A处理完之后才能 继续。使用这个方法的一个缺点就是会降低程序的效率。本来是一个多个线程的操作，一旦遇到lock的语句时，那么这些线程只要排队处理，形同一个单线程操 作。
下面举个例子说明一下这三个方法的使用：
假定有一个Tools类，里面一个int变量，还有Add和Delete方法，其中Add方法会使int变量的值增加，Delete方法使int变量值减少：
public class Tools private int count = 100;
public void Add(int n) count+=n;
}
public void Delete(int n) count-=n;
}
在多个线程同时访问这段代码时，因为一个语句会被编译器编译成多个指令，所以会可能出现这种情况：但某个线程调用Add方法时，这时的count值为 100，而正当要加上n的时候，另外一个线程调用了Delete，它要减去m，结果count加上了n，然后又在原先count=100的值的情况
下减掉了m，最后的结果是count被减去了m,而没有加上n。很明显Add方法和Delete方法是不能同时被调用的，所以必须进行线程同步处理。简单的方法是用lock语句：
public class Tools private object abcde = new object();
private int count = 100;
public void Add(int n) lock(abcde) count+=n;
}
public void Delete(int n) lock(abcde) count-=n; }
其中abcde是一个private级的内部变量，它不表示任何的意义，只是作为一种“令牌”的角色。
当执行Add方法中的lock(abcde)方法时，这个令牌就在Add方法的手中了，如果这时有第二个线程也想拿这个令牌，没门，惟有等待。一旦第一
个lock语句的花括号范围结束之后，这时令牌就被释放了，同时会迅速落到第二个线程的手中，并且排除其他后来的人。
使用Monitor类的方法大致一样：
public class Tools private object abcde = new object();
private int count = 100;
public void Add(int n) Monitor.Enter(abcde);
count+=n;
Monitor.Exit(abcde);
}
public void Delete(int n) Monitor.Enter(abcde);
count-=n;
Monitor.Exit(abcde);
}
Monitor的常用方法：Enter和Exit都是静态方法，作用跟lock语句的两个花括号一样。
而使用 Mutex 就不需声明一个“令牌”对象了，但要实例化之后才可以使用：
public class Tools
{
private Mutex mut = new Mutex();
private int count = 100;
public void Add(int n) mut.WaitOne();
count+=n;
mut.ReleaseMutex();
}
public void Delete(int n) mut.WaitOne();
count-=n;
mut.ReleaseMutex();
}
其中的WaitOne为等待方法，一直等到Mutex 被释放为止。初始的情况下，Mutex 对象是处于释放状态的，而一旦执行了WaitOne方法之后，它 就被捕获了，一直到被调用了ReleaseMutex方法之后才被释放。
使用这三种方法都有一个要注意的问题，就是在独占代码段里面如果引起了异常，可能会使“令牌”对象不被释放，这样程序就会一直地死等下去了。
所以要在独占代码段里面处理好异常。例如下面这样的代码就是错误的：
public void Add(int n) try mut.WaitOne();
count+=n; mut.ReleaseMutex(); catch Console.Writeline("error."); }
上面的代码一旦在try和catch里面发生了异常，那么Mutex就不能被释放，后面的程序就会卡死在WaitOne()一行，而应该改成这样：
public void Add(int n) mut.WaitOne();
try count+=n; }
catch Console.Writeline("error."); mut.ReleaseMutex();
}
现在谈一下第二种：
ManualResetEvent类，AutoResetEvent类
上面这两个类都是由EventWaitHandle类派生出来的，所以功能和调用方法都很相似。 举个例子，你想送花给一个MM，托了一个送花的小伙子送了过去，而你希望当MM收到花之后就立即打个电话过去告诉她。
但问题是你不知道花什么时候才送到MM的手里，打早了打迟了都不好，这时你可以使用ManualResetEvent对象帮忙。
当委托小伙子送花过去的时候，使用ManualResetEvent的WaitOne方法进行等待。当小伙子把花送到MM的手中时，再调用一下ManualResetEvent的Set方法，你就可以准时地打电话过去了。
另外ManualResetEvent还有一个Reset方法，用来重新阻断调用者执行的，情况就好比你委托了这个小伙子送花给N个MM，
而又想准时地给这N个MM打电话的情况一样。
using System;
using System.Threading;
public class TestMain private static ManualResetEvent ent = new ManualResetEvent(false);
public static void Main() Boy sender = new Boy(ent);
Thread th = new Thread(new ThreadStart(sender.SendFlower));
th.Start();
ent.WaitOne(); //等待工作
Console.WriteLine("收到了吧，花是我送嘀:)");
Console.ReadLine();
public class Boy ManualResetEvent ent;
public Boy(ManualResetEvent e) ent = e;
}
public void SendFlower() Console.WriteLine("正在送花的途中");
Thread.Sleep(2000);
Console.WriteLine(" 花已经送到MM手中了,boss");
ent.Set(); //通知阻塞程序
}
而AutoResetEvent类故名思意，就是在每次Set完之后自动Reset。让执行程序重新进入阻塞状态。
即AutoResetEvent.Set() 相当于 ManualResetEvent.Set() 之后又立即 ManualResetEvent.Reset()， 举个送花给N个MM的例子：
using System;
using System.Threading;
public class TestMain private static AutoResetEvent ent = new AutoResetEvent(false);
public static void Main() Boy sender = new Boy(ent);
for (int i = 0; i < 3; i++) Thread th = new Thread(new ThreadStart(sender.SendFlower));
th.Start();
ent.WaitOne(); //等待工作
Console.WriteLine("收到了吧，花是我送嘀:) ");
}
Console.ReadLine();
}
public class Boy AutoResetEvent ent;
public Boy(AutoResetEvent e) ent = e;
}
public void SendFlower() Console.WriteLine("正在送花的途中");
Thread.Sleep(2000);
Console.WriteLine(" 花已送到MM手中了,boss");
//通知阻塞程序,这里的效果相当于 ManualResetEvent的Set()方法+Reset()方法
ent.Set();
}
要注意的是ManualResetEvent和AutoResetEvent 的构造函数都有一个bool的参数，用这个参数可以指定初始情况下，同步对象的处于阻塞（设置为false）还是非阻塞（设置为true）的状态。
另外WaitOne方法也可以带两个参数：
WaitOne (int millisecondsTimeout,bool exitContext)
millisecondsTimeout：等待的毫秒数，或为 Timeout.Infinite (-1)，表示无限期等待。
exitContext：为 true，则等待之前先退出上下文的同步域（如果在同步上下文中），然后在稍后重新获取它；否则为false。
就是说，等待是可以加上一个期限的，如果等待的同步对象一直都不Set()的话，那么程序就会卡死，所以在WaitOne方法里面可以放置一个时间期限，单位是毫秒。
C#不同线程间通信，使用Control的Invoke和BeginInvoke的方法
- 张小鱼 2010-10-22 08:41
Control的Invoke和BeginInvoke Control的Invoke和BeginInvoke
近日，被Control的Invoke和BeginInvoke搞的头大，就查了些相关的资料，整理如下。
(一）Control的Invoke和BeginInvoke （1）Control的Invoke和BeginInvoke与Delegate的Invoke和BeginInvoke是不同的。
（2）Control的Invoke和BeginInvoke的参数为delegate，委托的方法是在Control的线程上执行的，也就是我们平时所说的UI线程。
我们以代码(一)来看(Control的Invoke)
private delegate void InvokeDelegate();
private void InvokeMethod(){
//C代码段 private void butInvoke_Click(object sender, EventArgs e) {
//A代码段.......
this.Invoke(new InvokeDelegate(InvokeMethod));
//B代码段...... 你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A------>C---------------->B
解释：(1)A在UI线程上执行完后，开始Invoke，Invoke是同步
(2)代码段B并不执行，而是立即在UI线程上执行InvokeMethod方法，即代码段C。
(3)InvokeMethod方法执行完后，代码段C才在UI线程上继续执行。
看看代码(二)，Control的BeginInvoke
private delegate void BeginInvokeDelegate();
private void BeginInvokeMethod(){
//C代码段 private void butBeginInvoke_Click(object sender, EventArgs e) {
//A代码段.......
this.BeginInvoke(new BeginInvokeDelegate(BeginInvokeMethod));
//B代码段...... 你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A----------->B--------------->C慎重，这个只做参考。。。。。，我也不肯定执行顺序，如果有哪位达人知道的话请告知。
解释：：(1)A在UI线程上执行完后，开始BeginInvoke，BeginInvoke是异步
(2)InvokeMethod方法，即代码段C不会执行，而是立即在UI线程上执行代码段B。
(3) 代码段B执行完后(就是说butBeginInvoke_Click方法执行完后)，InvokeMethod方法，即代码段C才在UI线程上继续执行。 Control的Invoke和BeginInvoke的委托方法是在主线程，即UI线程上执行的。也就是说如果你的委托方法用来取花费时间长的数据，然 后更新界面什么的，千万别在UI线程上调用Control.Invoke和 Control.BeginInvoke，因为这些是依然阻塞UI线程的，造成界面的假死。异步是指相对于调用BeginInvoke的线程异步，而不是 相对于UI线程异步，你在UI线程上调用BeginInvoke ，当然不行了。－－－－摘自"Invoke和BeginInvoke的真正涵义"一文中的评论。
BeginInvoke的原理是将调用的方法Marshal成消息，然后调用Win32 API中的RegisterWindowMessage()向UI窗口发送消息。－－－－摘自"Invoke和BeginInvoke的真正涵义"一文中的评论。
(二)我们用Thread来调用BeginInvoke和Invoke
我们开一个线程，让线程执行一些耗费时间的操作，然后再用Control.Invoke和Control.BeginInvoke回到用户UI线程，执行界面更新。
代码(三) Thread调用Control的Invoke
private Thread invokeThread;
private delegate void invokeDelegate();
private void StartMethod(){
//C代码段......
Control.Invoke(new invokeDelegate(invokeMethod));
//D代码段...... private void invokeMethod(){
//E代码段 private void butInvoke_Click(object sender, EventArgs e) {
//A代码段.......
invokeThread = new Thread(new ThreadStart(StartMethod));
invokeThread.Start();
//B代码段......
你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A------> (Start一开始B和StartMethod的C就同时执行)---->(C执行完了，不管B有没有执行完，invokeThread把消息封送 (invoke)给UI线程，然后自己等待)---->UI线程处理完butInvoke_Click消息后，处理invokeThread封送过 来的消息，执行invokeMethod 方法，即代码段E，处理往后UI线程切换到invokeThread线程。
这个Control.Invoke是相对于invokeThread线程同步的，阻止了其运行。 1。UI执行A
2。UI开线程InvokeThread，B和C同时执行，B执行在线程UI上，C执行在线程invokeThread上。
3。invokeThread封送消息给UI，然后自己等待，UI处理完消息后，处理invokeThread封送的消息，即代码段E
4。UI执行完E后，转到线程invokeThread上，invokeThread线程执行代码段D
代码(四) Thread调用Control的BeginInvoke
private Thread beginInvokeThread;
private delegate void beginInvokeDelegate();
private void StartMethod(){
//C代码段......
Control.BeginInvoke(new beginInvokeDelegate(beginInvokeMethod));
//D代码段...... private void beginInvokeMethod(){
//E代码段 private void butBeginInvoke_Click(object sender, EventArgs e) {
//A代码段.......
beginInvokeThread = new Thread(new ThreadStart(StartMethod));
beginInvokeThread .Start();
//B代码段...... 你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A 在UI线程上执行----->beginInvokeThread线程开始执行，UI继续执行代码段B，并发地invokeThread执行代码段 C-------------->不管UI有没有执行完代码段B，这时 beginInvokeThread线程把消息封送给UI，单自己并不等待，继续向下执行-------->UI处理完 butBeginInvoke_Click消息后，处理beginInvokeThread线程封送过来的消息。解释：
1。UI执行A
2。UI开线程beginInvokeThread，B和C同时执行，B执行在线程UI上，C执行在线程beginInvokeThread上。
3。beginInvokeThread封送消息给UI，然后自己继续执行代码D，UI处理完消息后，处理invokeThread封送的消息，即代码段E
有点疑问：如果UI先执行完毕，是不是有可能过了段时间beginInvokeThread才把消息封送给UI，然后UI才继续执行封送的消息E。如图浅绿的部分。
Control 的BeginInvoke是相对于调用它的线程，即beginInvokeThread相对是异步的。 (1)如果你想阻止调用线程，那么调用代码(三)，代码段D删掉，C改为耗费长时间的操作，因为这个操作是在另外一个线程中做的。代码段E改为更新界面的 方法。
(2)如果你不想阻止调用线程，那么调用代码(四)，代码段D删掉，C改为耗费长时间的操作，因为这个操作是在另外一个线程中做的。代码段E改为更新界面的方法。
http://www.huomo.cn/developer/article-1aa5.html
近日，被Control的Invoke和BeginInvoke搞的头大，就查了些相关的资料，整理如下。
(一）Control的Invoke和BeginInvoke （1）Control的Invoke和BeginInvoke与Delegate的Invoke和BeginInvoke是不同的。
（2）Control的Invoke和BeginInvoke的参数为delegate，委托的方法是在Control的线程上执行的，也就是我们平时所说的UI线程。
我们以代码(一)来看(Control的Invoke)
private delegate void InvokeDelegate();
private void InvokeMethod(){
//C代码段 private void butInvoke_Click(object sender, EventArgs e) {
//A代码段.......
this.Invoke(new InvokeDelegate(InvokeMethod));
//B代码段...... 你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A------>C---------------->B
解释：(1)A在UI线程上执行完后，开始Invoke，Invoke是同步
(2)代码段B并不执行，而是立即在UI线程上执行InvokeMethod方法，即代码段C。
(3)InvokeMethod方法执行完后，代码段C才在UI线程上继续执行。
看看代码(二)，Control的BeginInvoke
private delegate void BeginInvokeDelegate();
private void BeginInvokeMethod(){
//C代码段 private void butBeginInvoke_Click(object sender, EventArgs e) {
//A代码段.......
this.BeginInvoke(new BeginInvokeDelegate(BeginInvokeMethod));
//B代码段...... 你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A----------->B--------------->C慎重，这个只做参考。。。。。，我也不肯定执行顺序，如果有哪位达人知道的话请告知。
解释：：(1)A在UI线程上执行完后，开始BeginInvoke，BeginInvoke是异步
(2)InvokeMethod方法，即代码段C不会执行，而是立即在UI线程上执行代码段B。
(3) 代码段B执行完后(就是说butBeginInvoke_Click方法执行完后)，InvokeMethod方法，即代码段C才在UI线程上继续执行。 Control的Invoke和BeginInvoke的委托方法是在主线程，即UI线程上执行的。也就是说如果你的委托方法用来取花费时间长的数据，然 后更新界面什么的，千万别在UI线程上调用Control.Invoke和 Control.BeginInvoke，因为这些是依然阻塞UI线程的，造成界面的假死。异步是指相对于调用BeginInvoke的线程异步，而不是 相对于UI线程异步，你在UI线程上调用BeginInvoke ，当然不行了。－－－－摘自"Invoke和BeginInvoke的真正涵义"一文中的评论。
BeginInvoke的原理是将调用的方法Marshal成消息，然后调用Win32 API中的RegisterWindowMessage()向UI窗口发送消息。－－－－摘自"Invoke和BeginInvoke的真正涵义"一文中的评论。
(二)我们用Thread来调用BeginInvoke和Invoke
我们开一个线程，让线程执行一些耗费时间的操作，然后再用Control.Invoke和Control.BeginInvoke回到用户UI线程，执行界面更新。
代码(三) Thread调用Control的Invoke
private Thread invokeThread;
private delegate void invokeDelegate();
private void StartMethod(){
//C代码段......
Control.Invoke(new invokeDelegate(invokeMethod));
//D代码段...... private void invokeMethod(){
//E代码段 private void butInvoke_Click(object sender, EventArgs e) {
//A代码段.......
invokeThread = new Thread(new ThreadStart(StartMethod));
invokeThread.Start();
//B代码段......
你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A------> (Start一开始B和StartMethod的C就同时执行)---->(C执行完了，不管B有没有执行完，invokeThread把消息封送 (invoke)给UI线程，然后自己等待)---->UI线程处理完butInvoke_Click消息后，处理invokeThread封送过 来的消息，执行invokeMethod 方法，即代码段E，处理往后UI线程切换到invokeThread线程。
这个Control.Invoke是相对于invokeThread线程同步的，阻止了其运行。 1。UI执行A
2。UI开线程InvokeThread，B和C同时执行，B执行在线程UI上，C执行在线程invokeThread上。
3。invokeThread封送消息给UI，然后自己等待，UI处理完消息后，处理invokeThread封送的消息，即代码段E
4。UI执行完E后，转到线程invokeThread上，invokeThread线程执行代码段D
代码(四) Thread调用Control的BeginInvoke
private Thread beginInvokeThread;
private delegate void beginInvokeDelegate();
private void StartMethod(){
//C代码段......
Control.BeginInvoke(new beginInvokeDelegate(beginInvokeMethod));
//D代码段...... private void beginInvokeMethod(){
//E代码段 private void butBeginInvoke_Click(object sender, EventArgs e) {
//A代码段.......
beginInvokeThread = new Thread(new ThreadStart(StartMethod));
beginInvokeThread .Start();
//B代码段...... 你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A 在UI线程上执行----->beginInvokeThread线程开始执行，UI继续执行代码段B，并发地invokeThread执行代码段 C-------------->不管UI有没有执行完代码段B，这时 beginInvokeThread线程把消息封送给UI，单自己并不等待，继续向下执行-------->UI处理完 butBeginInvoke_Click消息后，处理beginInvokeThread线程封送过来的消息。解释：
1。UI执行A
2。UI开线程beginInvokeThread，B和C同时执行，B执行在线程UI上，C执行在线程beginInvokeThread上。
3。beginInvokeThread封送消息给UI，然后自己继续执行代码D，UI处理完消息后，处理invokeThread封送的消息，即代码段E
有点疑问：如果UI先执行完毕，是不是有可能过了段时间beginInvokeThread才把消息封送给UI，然后UI才继续执行封送的消息E。如图浅绿的部分。
Control 的BeginInvoke是相对于调用它的线程，即beginInvokeThread相对是异步的。 (1)如果你想阻止调用线程，那么调用代码(三)，代码段D删掉，C改为耗费长时间的操作，因为这个操作是在另外一个线程中做的。代码段E改为更新界面的 方法。
(2)如果你不想阻止调用线程，那么调用代码(四)，代码段D删掉，C改为耗费长时间的操作，因为这个操作是在另外一个线程中做的。代码段E改为更新界面的方法。
http://www.huomo.cn/developer/article-1aa5.html
C#多线程编程(4)-多线程与UI操作
- 张小鱼 2010-10-22 09:09
为了让程序尽快响应用户操作，在开发Windows应用程序时经常会使用到线程。对于耗时的操作如果不使用线程将会是UI界面长时间处于停滞状态，这种情况是用户非常不愿意看到的，在这种情况下我们希望使用线程来解决这个问题。
下面是一个使用多线程操作界面UI的代码：
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Threading;
namespacepublicpartialclasspublic ThreadForm()
{
InitializeComponent();
}
privatevoid btnThread_Click(object sender, EventArgs e)
{
Thread thread =new Thread(new ThreadStart(Run));
thread.Start();
}
privatevoidwhile (progressBar.Value < progressBar.Maximum)
{
progressBar.PerformStep();
}
}
}
}
程序的界面如下：
我 们的本意是点击“启动”按钮来启动模拟一个操作，在进度条中显示操作的总体进度。不过如果我们真的点击“启动”按钮会很失望，因为它会抛出一个 System.InvalidOperationException异常，异常描述就是“线程间操作无效: 从不是创建控件‘progressBar’的线程访问它。”
CheckForIllegalCrossThreadCalls属性
之所以 会出现这样的情况是因为在.NET中做了限制，不允许在调试环境下使用线程访问并非它自己创建的UI控件，这么做可能是怕在多线程环境下对界面控件进行操 作会出现不可预知的情况，如果开发者可以确认自己的代码操作界面不会出现问题，可以用比较简单的方法解决，那就是设置 CheckForIllegalCrossThreadCalls这个静态属性，它默认是true，如果将其设为false的话，以后在多线程环境下操作 界面也不会抛出异常了，我们上面的代码可以修改为：
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.Threading;
namespacepublicpartialclasspublic ThreadForm()
{
InitializeComponent();
}
privatevoid btnThread_Click(object//指示是否对错误线程的调用，即是否允许在创建UI的线程之外访问线程
CheckForIllegalCrossThreadCalls =false=new Thread(new ThreadStart(Run));
thread.Start();
}
privatevoidwhile (progressBar.Value < progressBar.Maximum)
{
progressBar.PerformStep();
}
}
}
}
这样再执行程序就不会抛出异常了。
不过使用上面的代码我们可能还有些犯嘀咕，毕竟是不允许直接在线程中直接操作界面的，那么我们还可以用Invoke方法。
Invoke方法来操作界面
下面是一个例子：
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.Threading;
namespacepublicpartialclass//定义delegate以便Invoke时使用
privatedelegatevoid SetProgressBarValue(int value);
public ThreadForm()
{
InitializeComponent();
}
privatevoid btnThread_Click(object sender, EventArgs e)
{
progressBar.Value =0;
//指示是否对错误线程的调用，即是否允许在创建UI的线程之外访问线程
//CheckForIllegalCrossThreadCalls = false;
Thread thread =new Thread(new ThreadStart(Run));
thread.Start();
}
//使用线程来直接设置进度条
privatevoidwhile (progressBar.Value < progressBar.Maximum)
{
progressBar.PerformStep();
}
}
privatevoid btnInvoke_Click(object sender, EventArgs e)
{
progressBar.Value =0=new Thread(new ThreadStart(RunWithInvoke));
thread.Start();
}
//使用Invoke方法来设置进度条
privatevoidint value = progressBar.Value;
while (value<//如果是跨线程调用
ifthis.Invoke(new SetProgressBarValue(SetProgressValue), value++else=++//跟SetProgressBarValue委托相匹配的方法
privatevoid SetProgressValue(int value)
{
progressBar.Value =
这个方法的功能跟上面的操作是一样的，只不过不需要设置CheckForIllegalCrossThreadCalls属性，而且还不会抛出异常，当然除了上面的方法之外，还可以使用BackgroundWorker类来完成同样的功能。
BackgroundWorker类操作界面
因为使用BackgroundWorker类操作UI界面的例子周公博客上已经有过例子，所以这里的例子代码注释比较简单，读者可以看周公以前的示例，这次所使用的代码示例如下：
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.Threading;
namespacepublicpartialclass//定义delegate以便Invoke时使用
privatedelegatevoid SetProgressBarValue(int value);
private BackgroundWorker worker;
public ThreadForm()
{
InitializeComponent();
}
privatevoid btnThread_Click(object sender, EventArgs e)
{
progressBar.Value =0;
//指示是否对错误线程的调用，即是否允许在创建UI的线程之外访问线程
//CheckForIllegalCrossThreadCalls = false;
Thread thread =new Thread(new ThreadStart(Run));
thread.Start();
}
//使用线程来直接设置进度条
privatevoidwhile (progressBar.Value < progressBar.Maximum)
{
progressBar.PerformStep();
}
}
privatevoid btnInvoke_Click(object sender, EventArgs e)
{
progressBar.Value =0=new Thread(new ThreadStart(RunWithInvoke));
thread.Start();
}
//使用Invoke方法来设置进度条
privatevoidint value = progressBar.Value;
while (value<//如果是跨线程调用
ifthis.Invoke(new SetProgressBarValue(SetProgressValue), value++else=++//跟SetProgressBarValue委托相匹配的方法
privatevoid SetProgressValue(int value)
{
progressBar.Value =privatevoid btnBackgroundWorker_Click(object sender, EventArgs e)
{
progressBar.Value =0=new BackgroundWorker();
worker.DoWork +=new DoWorkEventHandler(worker_DoWork);
//当工作进度发生变化时执行的事件处理方法
worker.ProgressChanged +=new ProgressChangedEventHandler(worker_ProgressChanged);
//当事件处理完毕后执行的方法
worker.RunWorkerCompleted +=new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);
worker.WorkerReportsProgress =true;//支持报告进度更新
worker.WorkerSupportsCancellation =false;//不支持异步取消
worker.RunWorkerAsync();//启动执行
btnBackgroundWorker.Enabled =false//当事件处理完毕后执行的方法
void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
btnBackgroundWorker.Enabled=true//当工作进度发生变化时执行的事件处理方法
void worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
//可以在这个方法中与界面进行通讯
progressBar.Value =//开始启动工作时执行的事件处理方法
void worker_DoWork(object sender, DoWorkEventArgs e)
{
int value = progressBar.Value;
while (value < progressBar.Maximum)
{
worker.ReportProgress(++value);//汇报进度
当然，除了BackgroundWorker可以完成上面的功能之外，利用System.Windows.Forms.Timer类也能完场上面的功能，代码如下： 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.Threading;
namespacepublicpartialclass//定义delegate以便Invoke时使用
privatedelegatevoid SetProgressBarValue(int value);
private BackgroundWorker worker;
public ThreadForm()
{
InitializeComponent();
}
privatevoid btnThread_Click(object sender, EventArgs e)
{
progressBar.Value =0;
//指示是否对错误线程的调用，即是否允许在创建UI的线程之外访问线程
//CheckForIllegalCrossThreadCalls = false;
Thread thread =new Thread(new ThreadStart(Run));
thread.Start();
}
//使用线程来直接设置进度条
privatevoidwhile (progressBar.Value < progressBar.Maximum)
{
progressBar.PerformStep();
}
}
privatevoid btnInvoke_Click(object sender, EventArgs e)
{
progressBar.Value =0=new Thread(new ThreadStart(RunWithInvoke));
thread.Start();
}
//使用Invoke方法来设置进度条
privatevoidint value = progressBar.Value;
while (value<//如果是跨线程调用
ifthis.Invoke(new SetProgressBarValue(SetProgressValue), value++else=++//跟SetProgressBarValue委托相匹配的方法
privatevoid SetProgressValue(int value)
{
progressBar.Value =privatevoid btnBackgroundWorker_Click(object sender, EventArgs e)
{
progressBar.Value =0=new BackgroundWorker();
worker.DoWork +=new DoWorkEventHandler(worker_DoWork);
//当工作进度发生变化时执行的事件处理方法
worker.ProgressChanged +=new ProgressChangedEventHandler(worker_ProgressChanged);
//当事件处理完毕后执行的方法
worker.RunWorkerCompleted +=new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);
worker.WorkerReportsProgress =true;//支持报告进度更新
worker.WorkerSupportsCancellation =false;//不支持异步取消
worker.RunWorkerAsync();//启动执行
btnBackgroundWorker.Enabled =false//当事件处理完毕后执行的方法
void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
btnBackgroundWorker.Enabled=true//当工作进度发生变化时执行的事件处理方法
void worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
//可以在这个方法中与界面进行通讯
progressBar.Value =//开始启动工作时执行的事件处理方法
void worker_DoWork(object sender, DoWorkEventArgs e)
{
int value = progressBar.Value;
while (value < progressBar.Maximum)
{
worker.ReportProgress(++value);//汇报进度
//使用System.Windows.Forms.Timer来操作界面能
privatevoid btnTimer_Click(object sender, EventArgs e)
{
progressBar.Value =0;
//注意在.net中有多个命名空间下存在Timer类，为了便于区别，使用了带命名空间形式
System.Windows.Forms.Timer timer =new System.Windows.Forms.Timer();
timer.Interval =1+=new EventHandler(timer_Tick);
timer.Enabled =true//Timer中要定期执行的方法
void timer_Tick(objectint value = progressBar.Value;
if (value < progressBar.Maximum)
{
progressBar.Value = value+100
总结：本篇主要讲述了使用线程操作Windows应用程序界面的方法，这些方法在编写多线程的UI程序时可以参考。
http://www.csharpwin.com/csharpspace/10234r1033.shtml
多线程和异步的一些看法（异步写文件）
- 张小鱼 2010-10-22 09:40
本文章是小弟的处女文章.以前只在园子里看文章.
正方开始
在工作中有一个项目由于写文件操作比较频繁
以前用的是同步写文件方式,有人提出要多线程写文件.
多线程写文件的任务分给别一个同事，
因别一个同事对多线程方面不太熟 我给他提供了下面这种试
//多线程操作同步写文件方法 public ThreadOperate() { Thread t = new Thread(new ThreadStart(ThreadProc)); t.Start(); } //同步写文件方法 public static void ThreadProc() { }
后来看了一些资料 http://dev.yesky.com/135/3030135.shtml(多核时代对并发程序设计的探索)
总结了下面这句：
线程: 需要操作系统投入CPU资源来运行和调度
异步: 无须消耗CPU时间的操作 如 I/O操作不仅包括了直接的文件、网络的读写，还包括数据库操作、Web Service、HttpRequest以及.net Remoting等跨进程的调用。
目前还不能很确定 上面这句是否正确. 请指点.
根据上面那句话我的想法改变了,我认为用异步写文件比多线程更合适于是用了下面方式
//异步写文件 public void WriteFile() { FileStream fs = new FileStream(@"C:Test.txt", FileMode.Create, FileAccess.Write, FileShare.Write); byte[] buffer = new byte[100]; for (int i = 0; i < buffer.Length; i++) { buffer[i] = 2; } fs.BeginWrite(buffer, 0, buffer.Length, FileCallBack, fs); } static void FileCallBack(IAsyncResult asyncResult) { FileStream fs = asyncResult.AsyncState as FileStream; if (fs != null) { fs.EndWrite(asyncResult); fs.Close(); } }
来源：http://www.chenjiliang.com/Article/View.aspx?ArticleID=2295
C#异步多线程(访问主线程控件)
- 张小鱼 2010-10-22 09:42
在多线程的情况下，其它线程无法直接调用到主线程上的控件，只能通过代理来实现主线程上控件的调用。
1、定义委托
// 执行任务的委托声明（解决长任务死假）
delegate void RunTaskDelegate(int seconds);
// 显示进度条的委托声明（跨线程调用控件）
delegate void ShowProgressDelegate(int totalStep, int currentStep);
2、定义方法
private void ShowProgress(int totalStep, int currentStep)
{
progressBar1.Maximum = totalStep;
progressBar1.Value = currentStep;
}
3、定义线程
private void RunTask(int seconds)
{
ShowProgressDelegate showProgress = new ShowProgressDelegate(ShowProgress);
for (int i = 0; i < seconds * 4; i++)
{
Thread.Sleep(250);
// 在基础窗口上调用显示进度条的委托
this.Invoke(showProgress, new object[] { seconds * 4, i + 1 });
}
}
4、执行
RunTaskDelegate runTask = new RunTaskDelegate(RunTask);
// 异步调用执行任务的委托
runTask.BeginInvoke(20, null, null);
.Net多线程完美讲解
- 张小鱼 2010-10-22 09:47
怎样创建一个线程
我只简单列举几种常用的方法,详细可参考.Net多线程总结(一)
一）使用Thread类
ThreadStart threadStart=new ThreadStart(Calculate);//通过ThreadStart委托告诉子线程讲执行什么方法,这里执行一个计算圆周长的方法
Thread thread=new Thread(threadStart);
thread.Start(); //启动新线程
public void Calculate(){
double Diameter=0.5;
Console.Write("The perimeter Of Circle with a Diameter of {0} is {1}"Diameter,Diameter*Math.PI);
}
二）使用Delegate.BeginInvoke
delegate double CalculateMethod(double Diameter); //申明一个委托，表明需要在子线程上执行的方法的函数签名
static CalculateMethod calcMethod = new CalculateMethod(Calculate);//把委托和具体的方法关联起来
static void Main(string[] args)
{
//此处开始异步执行,并且可以给出一个回调函数(如果不需要执行什么后续操作也可以不使用回调)
calcMethod.BeginInvoke(5, new AsyncCallback(TaskFinished), null);
Console.ReadLine();
}
//线程调用的函数,给出直径作为参数,计算周长
public static double Calculate(double Diameter)
{
return Diameter * Math.PI;
}
//线程完成之后回调的函数
public static void TaskFinished(IAsyncResult result)
{
double re = 0;
re = calcMethod.EndInvoke(result);
Console.WriteLine(re);
}
三）使用ThreadPool.QueueworkItem
WaitCallback w = new WaitCallback(Calculate);
//下面启动四个线程,计算四个直径下的圆周长
ThreadPool.QueueUserWorkItem(w, 1.0);
ThreadPool.QueueUserWorkItem(w, 2.0);
ThreadPool.QueueUserWorkItem(w, 3.0);
ThreadPool.QueueUserWorkItem(w, 4.0);
public static void Calculate(double Diameter)
{
return Diameter * Math.PI;
}
下面两条来自于http://www.cnblogs.com/tonyman/archive/2007/09/13/891912.html
受托管的线程与 Windows线程
必 须要了解，执行.NET应用的线程实际上仍然是Windows线程。但是，当某个线程被CLR所知时，我们将它称为受托管的线程。具体来说，由受托管的代 码创建出来的线程就是受托管的线程。如果一个线程由非托管的代码所创建，那么它就是非托管的线程。不过，一旦该线程执行了受托管的代码它就变成了受托管的 线程。
一个受托管的线程和非托管的线程的区别在于，CLR将创建一个System.Threading.Thread类的实例来代表并操作前者。在内部实现中，CLR将一个包含了所有受托管线程的列表保存在一个叫做ThreadStore地方。
CLR确保每一个受托管的线程在任意时刻都在一个AppDomain中执行，但是这并不代表一个线程将永远处在一个AppDomain中，它可以随着时间的推移转到其他的AppDomain中。
从安全的角度来看，一个受托管的线程的主用户与底层的非托管线程中的Windows主用户是无关的。
前台线程与后台线程
启 动了多个线程的程序在关闭的时候却出现了问题，如果程序退出的时候不关闭线程，那么线程就会一直的存在，但是大多启动的线程都是局部变量，不能一一的关 闭，如果调用Thread.CurrentThread.Abort()方法关闭主线程的话，就会出现ThreadAbortException 异常，因此这样不行。
后来找到了这个办法： Thread.IsBackground 设置线程为后台线程。
msdn对前台线程 和后台线程的解释：托管线程或者是后台线程，或者是前台线程。后台线程不会使托管执行环境处于活动状态，除此之外，后台线程与前台线程是一样的。一旦所有 前台线程在托管进程（其中 .exe 文件是托管程序集）中被停止，系统将停止所有后台线程并关闭。通过设置 Thread.IsBackground 属性，可以将一个线程指定为后台线程或前台线程。例如，通过将 Thread.IsBackground 设置为 true，就可以将线程指定为后台线程。同样，通过将 IsBackground 设置为 false，就可以将线程指定为前台线程。从非托管代码进入托管执行环境的所有线程都被标记为后台线程。通过创建并启动新的 Thread 对象而生成的所有线程都是前台线程。如果要创建希望用来侦听某些活动（如套接字连接）的前台线程，则应将 Thread.IsBackground 设置为 true，以便进程可以终止。
所以解决办法就是在主线程初始化的时候，设置：Thread.CurrentThread.IsBackground = true;
这样，主线程就是后台线程，在关闭主程序的时候就会关闭主线程，从而关闭所有线程。但是这样的话，就会强制关闭所有正在执行的线程，所以在关闭的时候要对线程工作的结果保存。
经常看到名为BeginXXX和EndXXX的方法，他们是做什么用的
这是.net的一个异步方法名称规范
.Net 在设计的时候为异步编程设计了一个异步编程模型（APM），这个模型不仅是使用.NET的开发人员使用，.Net内部也频繁用到，比如所有的Stream 就有BeginRead，EndRead，Socket,WebRequet,SqlCommand都运用到了这个模式，一般来讲，调用 BegionXXX的时候，一般会启动一个异步过程去执行一个操作，EndEnvoke可以接收这个异步操作的返回，当然如果异步操作在 EndEnvoke调用的时候还没有执行完成，EndInvoke会一直等待异步操作完成或者超时
.Net的异步编程模型（APM）一般包含BeginXXX，EndXXX，IAsyncResult这三个元素，BeginXXX方法都要返回一个IAsyncResult，而EndXXX都需要接收一个IAsyncResult作为参数，他们的函数签名模式如下
IAsyncResult BeginXXX(...);
<返回类型> EndXXX(IAsyncResult ar)；
BeginXXX 和EndXXX中的XXX，一般都对应一个同步的方法,比如FileStream的Read方法是一个同步方法，相应的 BeginRead(),EndRead()就是他的异步版本，HttpRequest有GetResponse来同步接收一个响应，也提供了 BeginGetResponse和EndGetResponse这个异步版本，而IAsynResult是二者联系的纽带，只有把BeginXXX所返 回的IAsyncResult传给对应的EndXXX，EndXXX才知道需要去接收哪个BeginXXX发起的异步操作的返回值。
这个 模式在实际使用时稍显繁琐,虽然原则上我们可以随时调用EndInvoke来获得返回值,并且可以同步多个线程,但是大多数情况下当我们不需要同步很多线 程的时候使用回调是更好的选择,在这种情况下三个元素中的IAsynResult就显得多余,我们一不需要用其中的线程完结标志来判断线程是否成功完成 (回调的时候线程应该已经完成了),二不需要他来传递数据,因为数据可以写在任何变量里,并且回调时应该已经填充,所以可以看到微软在新的.Net Framework中已经加强了对回调事件的支持,这总模型下,典型的回调程序应该这样写
a.DoWork+=new SomeEventHandler(Caculate);
a.CallBack+=new SomeEventHandler(callback);
a.Run();
（注： 我上面讲的是普遍的用法，然而BeginXXX，EndXXX仅仅是一种模式，而对这个模式的实现完全取决于使用他的开发人员，具体实现的时候你可以使用 另外一个线程来实现异步，也可能使用硬件的支持来实现异步，甚至可能根本和异步没有关系（尽管几乎没有人会这样做）-----比如直接在Beginxxx 里直接输出一个"Helloworld"，如果是这种极端的情况，那么上面说的一切都是废话，所以上面的探讨并不涉及内部实现，只是告诉大家微软的模式， 和框架中对这个模式的经典实现）
异步和多线程有什么关联
有一句话总结的很好：多线程是实现异步的一种手段和工具
我们通常把多线程和异步等同起来，实际是一种误解，在实际实现的时候，异步有许多种实现方法，我们可以用进程来做异步，或者使用纤程，或者硬件的一些特性，比如在实现异步IO的时候,可以有下面两个方案:
1)可以通过初始化一个子线程，然后在子线程里进行IO，而让主线程顺利往下执行，当子线程执行完毕就回调
2)也可以根本不使用新线程，而使用硬件的支持（现在许多硬件都有自己的处理器），来实现完全的异步，这是我们只需要将IO请求告知硬件驱动程序，然后迅速返回，然后等着硬件IO就绪通知我们就可以了
实 际上DotNet Framework里面就有这样的例子，当我们使用文件流的时候，如果制定文件流属性为同步，则使用BeginRead进行读取时，就是用一个子线程来调 用同步的Read方法，而如果指定其为异步，则同样操作时就使用了需要硬件和操作系统支持的所谓IOCP的机制
WinForm多线程编程篇
我的多线程WinForm程序老是抛出InvalidOperationException ，怎么解决？
在WinForm中使用多线程时，常常遇到一个问题，当在子线程（非UI线程）中修改一个控件的值：比如修改进度条进度，时会抛出如下错误
Cross-thread operation not valid: Control ‘XXX‘ accessed from a thread other than the thread it was created on.
在 VS2005或者更高版本中，只要不是在控件的创建线程（一般就是指UI主线程）上访问控件的属性就会抛出这个错误，解决方法就是利用控件提供的 Invoke和BeginInvoke把调用封送回UI线程，也就是让控件属性修改在UI线程上执行，下面列出会报错的代码和他的修改版本
ThreadStart threadStart=new ThreadStart(Calculate);//通过ThreadStart委托告诉子线程讲执行什么方法
Thread thread=new Thread(threadStart);
thread.Start();
public void Calculate(){
double Diameter=0.5;
double result=Diameter*Math.PI;
CalcFinished(result);//计算完成需要在一个文本框里显示
}
public void CalcFinished(double result){
this.TextBox1.Text=result.ToString();//会抛出错误
}
上面加粗的地方在debug的时候会报错，最直接的修改方法是修改Calculate这个方法如下
delegate void changeText(double result);
public void Calculate(){
double Diameter=0.5;
double result=Diameter*Math.PI;
this.BeginInvoke(new changeText(CalcFinished),t.Result);//计算完成需要在一个文本框里显示
}
这样就ok了，但是最漂亮的方法是不去修改Calculate，而去修改CalcFinished这个方法，因为程序里调用这个方法的地方可能很多，由于加了是否需要封送的判断,这样修改还能提高非跨线程调用时的性能
delegate void changeText(double result);
public void CalcFinished(double result){
if(this.InvokeRequired){
this.BeginInvoke(new changeText(CalcFinished),t.Result);
}
else{
this.TextBox1.Text=result.ToString();
}
}
上面的做法用到了Control的一个属性InvokeRequired（这个属性是可以在其他线程里访问的）,这个属性表明调用是否来自另非UI线程,如果是,则使用BeginInvoke来调用这个函数,否则就直接调用,省去线程封送的过程
Invoke，BeginInvoke干什么用的，内部是怎么实现的?
这两个方法主要是让给出的方法在控件创建的线程上执行
Invoke使用了Win32API的SendMessage,
UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
BeginInvoke使用了Win32API的PostMessage
UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
这两个方法向UI线程的消息队列中放入一个消息,当UI线程处理这个消息时,就会在自己的上下文中执行传入的方法,换句话说凡是使用BeginInvoke和Invoke调用的线程都是在UI主线程中执行的,所以如果这些方法里涉及一些静态变量,不用考虑加锁的问题
每个线程都有消息队列吗?
不是,只有创建了窗体对象的线程才会有消息队列(下面给出<Windows 核心编程>关于这一段的描述)
当 一个线程第一次被建立时，系统假定线程不会被用于任何与用户相关的任务。这样可以减少线程对系统资源的要求。但是，一旦这个线程调用一个与图形用户界面有 关的函数（例如检查它的消息队列或建立一个窗口），系统就会为该线程分配一些另外的资源，以便它能够执行与用户界面有关的任务。特别是，系统分配一个T H R E A D I N F O结构，并将这个数据结构与线程联系起来。
这个T H R E A D I N F O结构包含一组成员变量，利用这组成员，线程可以认为它是在自己独占的环境中运行。T H R E A D I N F O是一个内部的、未公开的数据结构，用来指定线程的登记消息队列（posted-message queue）、发送消息队列（ send-message queue）、应答消息队列（ r e p l y -message queue）、虚拟输入队列（virtualized-input queue）、唤醒标志（wake flag）、以及用来描述线程局部输入状态的若干变量。图2 6 - 1描述了T H R E A D I N F O结构和与之相联系的三个线程。
为什么Winform不允许跨线程修改UI线程控件的值
在vs2003下,使用子线程调用ui线程创建的控件的属性是不会有问题的,但是编译的时候会出现警告,但是vs2005及以上版本就会有这样的问题,下面是msdn上的描述
" 当您在 Visual Studio 调试器中运行代码时，如果您从一个线程访问某个 UI 元素，而该线程不是创建该 UI 元素时所在的线程，则会引发 InvalidOperationException。调试器引发该异常以警告您存在危险的编程操作。UI 元素不是线程安全的，所以只应在创建它们的线程上进行访问"
从上面可以看出,这个异常实际是debugger耍的花招,也就是说,如果 你直接运行程序的exe文件,或者利用运行而不调试(Ctrl+F5)来运行你的程序,是不会抛出这样的异常的.大概ms发现v2003的警告对广大开发 者不起作用,所以用了一个比较狠一点的方法.
不过问题依然存在:既然这样设计的原因主要是因为控件的值非线程安全,那么DotNet framework中非线程安全的类千千万万,为什么偏偏跨线程修改Control的属性会有这样严格的限制策略呢?
这个问题我还回答不好,希望博友们能够予以补充
有没有什么办法可以简化WinForm多线程的开发
使用backgroundworker,使用这个组建可以避免回调时的Invoke和BeginInvoke,并且提供了许多丰富的方法和事件
参见.Net多线程总结(二)-BackgroundWorker,我在这里不再赘诉
线程池
线程池的作用是什么
作用是减小线程创建和销毁的开销
创建线程涉及用户模式和内核模式的切换，内存分配，dll通知等一系列过程，线程销毁的步骤也是开销很大的，所以如果应用程序使用了完一个线程，我们能把线程暂时存放起来，以备下次使用，就可以减小这些开销
所有进程使用一个共享的线程池,还是每个进程使用独立的线程池?
每 个进程都有一个线程池,一个Process中只能有一个实例，它在各个应用程序域（AppDomain）是共享的，.Net2.0 中默认线程池的大小为工作线程25个,IO线程1000个,有一个比较普遍的误解是线程池中会有1000个线程等着你去取,其实不然, ThreadPool仅仅保留相当少的线程，保留的线程可以用SetMinThread这个方法来设置，当程序的某个地方需要创建一个线程来完成工作时， 而线程池中又没有空闲线程时,线程池就会负责创建这个线程,并且在调用完毕后,不会立刻销毁,而是把他放在池子里,预备下次使用,同时如果线程超过一定时 间没有被使用,线程池将会回收线程，所以线程池里存在的线程数实际是个动态的过程
为什么不要手动线程池设置最大值?
当我首次看到线程池的时候,脑袋里的第一个念头就是给他设定一个最大值,然而当我们查看ThreadPool的SetMaxThreads文档时往往会看到一条警告:不要手动更改线程池的大小,这是为什么呢?
其 实无论FileStream的异步读写,异步发送接受Web请求,甚至使用delegate的beginInvoke都会默认调用 ThreadPool,也就是说不仅你的代码可能使用到线程池,框架内部也可能使用到,更改的后果影响就非常大,特别在iis中,一个应用程序池中的所有 WebApplication会共享一个线程池，对最大值的设定会带来很多意想不到的麻烦
线程池的线程为何要分类?
线 程池有一个方法可以让我们看到线程池中可用的线程数量:GetAvaliableThread(out workerThreadCount,out iocompletedThreadCount),对于我来说,第一次看到这个函数的参数时十分困惑,因为我期望这个函数直接返回一个整形,表明还剩多少 线程,这个函数居然一次返回了两个变量.
原来线程池里的线程按照公用被分成了两大类:工作线程和IO线程,或者IO完成线程,前者用于 执行普通的操作,后者专用于异步IO,比如文件和网络请求,注意,分类并不说明两种线程本身有差别,线程就是线程,是一种执行单元,从本质上来讲都是一样 的,线程池这样分类,举例来说,就好像某施工工地现在有1000把铁锹,规定其中25把给后勤部门用,其他都给施工部门,施工部门需要大量使用铁锹来挖地 基(例子土了点,不过说明问题还是有效的),后勤部门用铁锹也就是铲铲雪,铲铲垃圾,给工人师傅修修临时住房,所以用量不大，显然两个部门的铁锹本身没有 区别，但是这样的划分就为管理两个部门的铁锹提供了方便
线程池中两种线程分别在什么情况下被使用,二者工作原理有什么不同?
下面这个例子直接说明了二者的区别,我们用一个流读出一个很大的文件(大一点操作的时间长,便于观察),然后用另一个输出流把所读出的文件的一部分写到磁盘上
我们用两种方法创建输出流,分别是
创建了一个异步的流(注意构造函数最后那个true)
FileStream outputfs=new FileStream(writepath, FileMode.Create, FileAccess.Write, FileShare.None,256,true);
创建了一个同步的流
FileStream outputfs = File.OpenWrite(writepath);
然后在写文件期间查看线程池的状况
string readpath = "e:\RHEL4-U4-i386-AS-disc1.iso";
string writepath = "e:\kakakak.iso";
byte[] buffer = new byte[90000000];
//FileStream outputfs=new FileStream(writepath, FileMode.Create, FileAccess.Write, FileShare.None,256,true);
//Console.WriteLine("异步流");
//创建了一个同步的流
FileStream outputfs = File.OpenWrite(writepath);
Console.WriteLine("同步流");
//然后在写文件期间查看线程池的状况
ShowThreadDetail("初始状态");
FileStream fs = File.OpenRead(readpath);
fs.BeginRead(buffer, 0, 90000000, delegate(IAsyncResult o)
{
outputfs.BeginWrite(buffer, 0, buffer.Length,
delegate(IAsyncResult o1)
{
Thread.Sleep(1000);
ShowThreadDetail("BeginWrite的回调线程");
}, null);
Thread.Sleep(500);//this is important cause without this, this Thread and the one used for BeginRead May seem to be same one
},
null);
Console.ReadLine();
public static void ShowThreadDetail(string caller)
{
int IO;
int Worker;
ThreadPool.GetAvailableThreads(out Worker, out IO);
Console.WriteLine("Worker: {0}; IO: {1}", Worker, IO);
}
输出结果
异步流
Worker: 500; IO: 1000
Worker: 500; IO: 999
同步流
Worker: 500; IO: 1000
Worker: 499; IO: 1000
这两个构造函数创建的流都可以使用BeginWrite来异步写数据,但是二者行为不同,当使用同步的流进行异步写时,通过回调的输出我们可以看到,他使用的是工作线程,而非IO线程,而异步流使用了IO线程而非工作线程
其 实当没有制定异步属性的时候,.Net实现异步IO是用一个子线程调用fs的同步Write方法来实现的,这时这个子线程会一直阻塞直到调用完成.这个子 线程其实就是线程池的一个工作线程,所以我们可以看到,同步流的异步写回调中输出的工作线程数少了一,而使用异步流,在进行异步写时,采用了 IOCP方法,简单说来,就是当BeginWrite执行时,把信息传给硬件驱动程序,然后立即往下执行(注意这里没有额外的线程),而当硬件准备就绪, 就会通知线程池,使用一个IO线程来读取
.Net线程池有什么不足
没有提供方法控制加入线程池的线程:一旦加入线程池,我们没有办法挂起,终止这些线程,唯一可以做的就是等他自己执行
1)不能为线程设置优先级
2) 一个Process中只能有一个实例，它在各个AppDomain是共享的。ThreadPool只提供了静态方法，不仅我们自己添加进去的 WorkItem使用这个Pool，而且.net framework中那些BeginXXX、EndXXX之类的方法都会使用此Pool。
3)所支持的Callback不能有返回值。WaitCallback只能带一个object类型的参数，没有任何返回值。
4)不适合用在长期执行某任务的场合。我们常常需要做一个Service来提供不间断的服务（除非服务器down掉），但是使用ThreadPool并不合适。
下面是另外一个网友总结的什么不需要使用线程池,我觉得挺好,引用下来
如果您需要使一个任务具有特定的优先级。
如果您具有可能会长时间运行（并因此阻塞其他任务）的任务。
如果您需要将线程放置到单线程单元中（所有 ThreadPool 线程均处于多线程单元中）。
如果您需要与该线程关联的稳定标识。例如，您应使用一个专用线程来中止该线程、将其挂起或按名称发现它。
锁定与同步
CLR怎样实现lock(obj)锁定?
从原理上讲,lock和Syncronized Attribute都是用Moniter.Enter实现的,比如如下代码
object lockobj=new object();
lock(obj){
//do things
}
在编译时,会被编译为类似
try{
Moniter.Enter(obj){
//do things
}
}
catch{}
finally{
Moniter.Exit(obj);
}
而[MethodImpl(MethodImplOptions.Synchronized)]标记为同步的方法会在编译时被lock(this)语句所环绕
所以我们只简单探讨Moniter.Enter的实现
（注:DotNet并非使用Win32API的CriticalSection来实现Moniter.Enter，不过他为托管对象提供了一个类似的结构叫做Syncblk）
每 个对象实例头部都有一个指针,这个指针指向的结构,包含了对象的锁定信息,当第一次使用Moniter.Enter(obj)时,这个obj对象的锁定结 构就会被初时化,第二次调用Moniter.Enter时,会检验这个object的锁定结构,如果锁没有被释放,则调用会阻塞
WaitHandle是什么,他和他的派生类怎么使用
WaitHandle是Mutex，Semaphore，EventWaitHandler，AutoResetEvent，ManualResetEvent共同的祖先，他们包装了用于同步的内核对象，也就是说是这些内核对象的托管版本。
Mutex:类似于一个接力棒,拿到接力棒的线程才可以开始跑,当然接力棒一次只属于一个线程(Thread Affinity),如果这个线程不释放接力棒(Mutex.ReleaseMutex),那么没办法,其他所有需要接力棒运行的线程都知道能等着看热闹
Semaphore: 类似于一个小桶,里面装了几个小球,凡是拿到小球就可以跑,比如指定小桶里最初有四个小球,那么开始的四个线程就可以直接拿着自己的小球开跑,但是第五个 线程一看,小球被拿光了,就只好乖乖的等着有谁放一个小球到小桶里(Semophore.Release),他才能跑,但是这里的游戏规则比较特殊,我们 可以随意向小桶里放入小球,也就是说我可以拿走一个小球,放回去俩,甚至一个都不拿,放回去5个,这样就有五个线程可以拿着这些小球运行了.我们可以规定 小桶里有开始有几个小球(构造函数的第一个参数),也可以规定最多不能超过多少小球(构造函数的第二个参数)
ManualResetEvent,AutoResetEvent可以参考http://www.cnblogs.com/uubox/archive/2007/12/18/1003953.html
什么是用双锁实现Singleton,为什么要这样做,双锁检验是不安全的吗?
使用双锁检验技巧来实现单件,来自于Java社区
public static MySingleton Instance{
get{
if(_instance!=null)}{
lock(_instance){
if(s_value==null){
_instance= new MySingleton();
}
}
}
}
}
这样做其实是为了提高效率,比起
public static MySingleton Instance{
get{
lock(_instance){
if(s_value==null){
_instance= new MySingleton();
}
}
前一种方法在instance创建的时候不需要用lock同步,从而增进了效率
在java中这种技巧被证明是不安全的详细见http://www.cs.umd.edu/~pugh/java/memoryModel/
但是在.Net下,这样的技巧是成立的,因为.Net使用了改进的内存模型
并且在.Net下,我们可以使用LazyInit来实现单件
private static readonly _instance=new MySingleton()
public static MySingleton Instance{
get{return _instance}
}
当第一此使用_instance时,CLR会生成这个对象,以后再访问这个字段,将会直接返回
互斥对象（Mutex）,信号量(Semaphore),事件（Event）对象与lock语句的比较
首先这里所谓的事件对象不是System.Event，而是一种用于同步的内核机制
互斥对象和事件对象属于内核对象，利用内核对象进行线程同步，线程必须要在用户模式和内核模式间切换，所以一般效率很低，但利用互斥对象和事件对象这样的内核对象，可以在多个进程中的各个线程间进行同步。
lock或者Moniter是.net用一个特殊结构实现的,不涉及模式切换,也就是说工作在用户方式下，同步速度较快,但是不能跨进程同步
什么时候需要锁定?
刚刚接触锁定的程序员往往觉得这个世界非常的危险,每个静态变量似乎都有可能产生竞争
首先锁定是解决竞争条件的,也就是多个线程同时访问某个资源,造成意想不到的结果,比如,最简单的情况,一个计数器,如果两个线程同时加一,后果就是损失了一个计数,但是频繁的锁定又可能带来性能上的消耗,还有最可怕的情况,死锁
到底什么情况下我们需要使用锁,什么情况下不用呢?
只有共享资源才需要锁定
首先,只有可以被多线程访问的共享资源才需要考虑锁定,比如静态变量,再比如某些缓存中的值,属于线程内部的变量不需要锁定
把锁定交给数据库
数据库除了存储数据之外,还有一个重要的用途就是同步,数据库本身用了一套复杂的机制来保证数据的可靠和一致性,这就为我们节省了很多的精力.保证了数据源头上的同步,我们多数的精力就可以集中在缓存等其他一些资源的同步访问上了
了解你的程序是怎么运行的
实 际上在web开发中大多数逻辑都是在单个线程中展开的,无论asp.net还是php,一个请求都会在一个单独的线程中处理,其中的大部分变量都是属于这 个线程的,根本没有必要考虑锁定,当然对于asp.net中的application对象中的数据,我们就要小心一些了
WinForm中凡是使用BeginInvoke和Invoke调用的方法也都不需要考虑同步,因为这用这两个方法调用的方法会在UI线程中执行,因此实际是同步的,所以如果调用的方法中存在某些静态变量,不需要考虑锁定
业务逻辑对事务和线程安全的要求
这 条是最根本的东西,开发完全线程安全的程序是件很费时费力的事情,在电子商务等涉及金融系统的案例中,许多逻辑都必须严格的线程安全,所以我们不得不牺牲 一些性能,和很多的开发时间来做这方面的工作,而一般的应用中,许多情况下虽然程序有竞争的危险,我们还是可以不使用锁定,比如有的时候计数器少一多一, 对结果无伤大雅的情况下,我们就可以不用去管他
计算一下冲突的可能性
我以前曾经谈到过,架构不要过设计,其实在这里也一样,假 如你的全局缓存里的某个值每天只有几百或者几千个访问,并且访问时间很短,并且分布均匀(实际上这是大多数的情况),那么冲突的可能性就非常的少,也许每 500天才会出现一次或者更长,从7*24小时安全服务的角度来看,也完全符合要求,那么你还会为这样万分之一的可能性花80%的精力去设计吗?
请多使用lock,少用Mutex
如 果你一定要使用锁定,请尽量不要使用内核模块的锁定机制,比如.net的 Mutex,Semaphore,AutoResetEvent,ManuResetEvent,使用这样的机制涉及到了系统在用户模式和内核模式间的切 换,所以性能差很多,但是他们的优点是可以跨进程同步线程,所以应该清楚的了解到他们的不同和适用范围
Web和IIS
应用程序池,WebApplication,和线程池之间有什么关系
一个应用程序池是一个独立的进程,拥有一个线程池,应用程序池中可以有多个WebApplication,每个运行在一个单独的AppDomain中,这些WebApplication公用一个线程池
不同的AppDomain保证了每个WebApplication的静态变量不会互相干扰,不同的应用程序池保证了一个网站瘫痪,其他不同进程中的站点还能正常运行
下图说明了他们的关系
Web页面怎么调用异步WebService
把Page的Async属性设置为true,就可以调用异步的方法,但是这样调用的效果可能并不如我们的相像,请参考Web中使用多线程来增强用户体验
我只简单列举几种常用的方法,详细可参考.Net多线程总结(一)
一）使用Thread类
ThreadStart threadStart=new ThreadStart(Calculate);//通过ThreadStart委托告诉子线程讲执行什么方法,这里执行一个计算圆周长的方法
Thread thread=new Thread(threadStart);
thread.Start(); //启动新线程
public void Calculate(){
double Diameter=0.5;
Console.Write("The perimeter Of Circle with a Diameter of {0} is {1}"Diameter,Diameter*Math.PI);
}
二）使用Delegate.BeginInvoke
delegate double CalculateMethod(double Diameter); //申明一个委托，表明需要在子线程上执行的方法的函数签名
static CalculateMethod calcMethod = new CalculateMethod(Calculate);//把委托和具体的方法关联起来
static void Main(string[] args)
{
//此处开始异步执行,并且可以给出一个回调函数(如果不需要执行什么后续操作也可以不使用回调)
calcMethod.BeginInvoke(5, new AsyncCallback(TaskFinished), null);
Console.ReadLine();
}
//线程调用的函数,给出直径作为参数,计算周长
public static double Calculate(double Diameter)
{
return Diameter * Math.PI;
}
//线程完成之后回调的函数
public static void TaskFinished(IAsyncResult result)
{
double re = 0;
re = calcMethod.EndInvoke(result);
Console.WriteLine(re);
}
三）使用ThreadPool.QueueworkItem
WaitCallback w = new WaitCallback(Calculate);
//下面启动四个线程,计算四个直径下的圆周长
ThreadPool.QueueUserWorkItem(w, 1.0);
ThreadPool.QueueUserWorkItem(w, 2.0);
ThreadPool.QueueUserWorkItem(w, 3.0);
ThreadPool.QueueUserWorkItem(w, 4.0);
public static void Calculate(double Diameter)
{
return Diameter * Math.PI;
}
下面两条来自于http://www.cnblogs.com/tonyman/archive/2007/09/13/891912.html
受托管的线程与 Windows线程
必 须要了解，执行.NET应用的线程实际上仍然是Windows线程。但是，当某个线程被CLR所知时，我们将它称为受托管的线程。具体来说，由受托管的代 码创建出来的线程就是受托管的线程。如果一个线程由非托管的代码所创建，那么它就是非托管的线程。不过，一旦该线程执行了受托管的代码它就变成了受托管的 线程。
一个受托管的线程和非托管的线程的区别在于，CLR将创建一个System.Threading.Thread类的实例来代表并操作前者。在内部实现中，CLR将一个包含了所有受托管线程的列表保存在一个叫做ThreadStore地方。
CLR确保每一个受托管的线程在任意时刻都在一个AppDomain中执行，但是这并不代表一个线程将永远处在一个AppDomain中，它可以随着时间的推移转到其他的AppDomain中。
从安全的角度来看，一个受托管的线程的主用户与底层的非托管线程中的Windows主用户是无关的。
前台线程与后台线程
启 动了多个线程的程序在关闭的时候却出现了问题，如果程序退出的时候不关闭线程，那么线程就会一直的存在，但是大多启动的线程都是局部变量，不能一一的关 闭，如果调用Thread.CurrentThread.Abort()方法关闭主线程的话，就会出现ThreadAbortException 异常，因此这样不行。
后来找到了这个办法： Thread.IsBackground 设置线程为后台线程。
msdn对前台线程 和后台线程的解释：托管线程或者是后台线程，或者是前台线程。后台线程不会使托管执行环境处于活动状态，除此之外，后台线程与前台线程是一样的。一旦所有 前台线程在托管进程（其中 .exe 文件是托管程序集）中被停止，系统将停止所有后台线程并关闭。通过设置 Thread.IsBackground 属性，可以将一个线程指定为后台线程或前台线程。例如，通过将 Thread.IsBackground 设置为 true，就可以将线程指定为后台线程。同样，通过将 IsBackground 设置为 false，就可以将线程指定为前台线程。从非托管代码进入托管执行环境的所有线程都被标记为后台线程。通过创建并启动新的 Thread 对象而生成的所有线程都是前台线程。如果要创建希望用来侦听某些活动（如套接字连接）的前台线程，则应将 Thread.IsBackground 设置为 true，以便进程可以终止。
所以解决办法就是在主线程初始化的时候，设置：Thread.CurrentThread.IsBackground = true;
这样，主线程就是后台线程，在关闭主程序的时候就会关闭主线程，从而关闭所有线程。但是这样的话，就会强制关闭所有正在执行的线程，所以在关闭的时候要对线程工作的结果保存。
经常看到名为BeginXXX和EndXXX的方法，他们是做什么用的
这是.net的一个异步方法名称规范
.Net 在设计的时候为异步编程设计了一个异步编程模型（APM），这个模型不仅是使用.NET的开发人员使用，.Net内部也频繁用到，比如所有的Stream 就有BeginRead，EndRead，Socket,WebRequet,SqlCommand都运用到了这个模式，一般来讲，调用 BegionXXX的时候，一般会启动一个异步过程去执行一个操作，EndEnvoke可以接收这个异步操作的返回，当然如果异步操作在 EndEnvoke调用的时候还没有执行完成，EndInvoke会一直等待异步操作完成或者超时
.Net的异步编程模型（APM）一般包含BeginXXX，EndXXX，IAsyncResult这三个元素，BeginXXX方法都要返回一个IAsyncResult，而EndXXX都需要接收一个IAsyncResult作为参数，他们的函数签名模式如下
IAsyncResult BeginXXX(...);
<返回类型> EndXXX(IAsyncResult ar)；
BeginXXX 和EndXXX中的XXX，一般都对应一个同步的方法,比如FileStream的Read方法是一个同步方法，相应的 BeginRead(),EndRead()就是他的异步版本，HttpRequest有GetResponse来同步接收一个响应，也提供了 BeginGetResponse和EndGetResponse这个异步版本，而IAsynResult是二者联系的纽带，只有把BeginXXX所返 回的IAsyncResult传给对应的EndXXX，EndXXX才知道需要去接收哪个BeginXXX发起的异步操作的返回值。
这个 模式在实际使用时稍显繁琐,虽然原则上我们可以随时调用EndInvoke来获得返回值,并且可以同步多个线程,但是大多数情况下当我们不需要同步很多线 程的时候使用回调是更好的选择,在这种情况下三个元素中的IAsynResult就显得多余,我们一不需要用其中的线程完结标志来判断线程是否成功完成 (回调的时候线程应该已经完成了),二不需要他来传递数据,因为数据可以写在任何变量里,并且回调时应该已经填充,所以可以看到微软在新的.Net Framework中已经加强了对回调事件的支持,这总模型下,典型的回调程序应该这样写
a.DoWork+=new SomeEventHandler(Caculate);
a.CallBack+=new SomeEventHandler(callback);
a.Run();
（注： 我上面讲的是普遍的用法，然而BeginXXX，EndXXX仅仅是一种模式，而对这个模式的实现完全取决于使用他的开发人员，具体实现的时候你可以使用 另外一个线程来实现异步，也可能使用硬件的支持来实现异步，甚至可能根本和异步没有关系（尽管几乎没有人会这样做）-----比如直接在Beginxxx 里直接输出一个"Helloworld"，如果是这种极端的情况，那么上面说的一切都是废话，所以上面的探讨并不涉及内部实现，只是告诉大家微软的模式， 和框架中对这个模式的经典实现）
异步和多线程有什么关联
有一句话总结的很好：多线程是实现异步的一种手段和工具
我们通常把多线程和异步等同起来，实际是一种误解，在实际实现的时候，异步有许多种实现方法，我们可以用进程来做异步，或者使用纤程，或者硬件的一些特性，比如在实现异步IO的时候,可以有下面两个方案:
1)可以通过初始化一个子线程，然后在子线程里进行IO，而让主线程顺利往下执行，当子线程执行完毕就回调
2)也可以根本不使用新线程，而使用硬件的支持（现在许多硬件都有自己的处理器），来实现完全的异步，这是我们只需要将IO请求告知硬件驱动程序，然后迅速返回，然后等着硬件IO就绪通知我们就可以了
实 际上DotNet Framework里面就有这样的例子，当我们使用文件流的时候，如果制定文件流属性为同步，则使用BeginRead进行读取时，就是用一个子线程来调 用同步的Read方法，而如果指定其为异步，则同样操作时就使用了需要硬件和操作系统支持的所谓IOCP的机制
WinForm多线程编程篇
我的多线程WinForm程序老是抛出InvalidOperationException ，怎么解决？
在WinForm中使用多线程时，常常遇到一个问题，当在子线程（非UI线程）中修改一个控件的值：比如修改进度条进度，时会抛出如下错误
Cross-thread operation not valid: Control ‘XXX‘ accessed from a thread other than the thread it was created on.
在 VS2005或者更高版本中，只要不是在控件的创建线程（一般就是指UI主线程）上访问控件的属性就会抛出这个错误，解决方法就是利用控件提供的 Invoke和BeginInvoke把调用封送回UI线程，也就是让控件属性修改在UI线程上执行，下面列出会报错的代码和他的修改版本
ThreadStart threadStart=new ThreadStart(Calculate);//通过ThreadStart委托告诉子线程讲执行什么方法
Thread thread=new Thread(threadStart);
thread.Start();
public void Calculate(){
double Diameter=0.5;
double result=Diameter*Math.PI;
CalcFinished(result);//计算完成需要在一个文本框里显示
}
public void CalcFinished(double result){
this.TextBox1.Text=result.ToString();//会抛出错误
}
上面加粗的地方在debug的时候会报错，最直接的修改方法是修改Calculate这个方法如下
delegate void changeText(double result);
public void Calculate(){
double Diameter=0.5;
double result=Diameter*Math.PI;
this.BeginInvoke(new changeText(CalcFinished),t.Result);//计算完成需要在一个文本框里显示
}
这样就ok了，但是最漂亮的方法是不去修改Calculate，而去修改CalcFinished这个方法，因为程序里调用这个方法的地方可能很多，由于加了是否需要封送的判断,这样修改还能提高非跨线程调用时的性能
delegate void changeText(double result);
public void CalcFinished(double result){
if(this.InvokeRequired){
this.BeginInvoke(new changeText(CalcFinished),t.Result);
}
else{
this.TextBox1.Text=result.ToString();
}
}
上面的做法用到了Control的一个属性InvokeRequired（这个属性是可以在其他线程里访问的）,这个属性表明调用是否来自另非UI线程,如果是,则使用BeginInvoke来调用这个函数,否则就直接调用,省去线程封送的过程
Invoke，BeginInvoke干什么用的，内部是怎么实现的?
这两个方法主要是让给出的方法在控件创建的线程上执行
Invoke使用了Win32API的SendMessage,
UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
BeginInvoke使用了Win32API的PostMessage
UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
这两个方法向UI线程的消息队列中放入一个消息,当UI线程处理这个消息时,就会在自己的上下文中执行传入的方法,换句话说凡是使用BeginInvoke和Invoke调用的线程都是在UI主线程中执行的,所以如果这些方法里涉及一些静态变量,不用考虑加锁的问题
每个线程都有消息队列吗?
不是,只有创建了窗体对象的线程才会有消息队列(下面给出<Windows 核心编程>关于这一段的描述)
当 一个线程第一次被建立时，系统假定线程不会被用于任何与用户相关的任务。这样可以减少线程对系统资源的要求。但是，一旦这个线程调用一个与图形用户界面有 关的函数（例如检查它的消息队列或建立一个窗口），系统就会为该线程分配一些另外的资源，以便它能够执行与用户界面有关的任务。特别是，系统分配一个T H R E A D I N F O结构，并将这个数据结构与线程联系起来。
这个T H R E A D I N F O结构包含一组成员变量，利用这组成员，线程可以认为它是在自己独占的环境中运行。T H R E A D I N F O是一个内部的、未公开的数据结构，用来指定线程的登记消息队列（posted-message queue）、发送消息队列（ send-message queue）、应答消息队列（ r e p l y -message queue）、虚拟输入队列（virtualized-input queue）、唤醒标志（wake flag）、以及用来描述线程局部输入状态的若干变量。图2 6 - 1描述了T H R E A D I N F O结构和与之相联系的三个线程。
为什么Winform不允许跨线程修改UI线程控件的值
在vs2003下,使用子线程调用ui线程创建的控件的属性是不会有问题的,但是编译的时候会出现警告,但是vs2005及以上版本就会有这样的问题,下面是msdn上的描述
" 当您在 Visual Studio 调试器中运行代码时，如果您从一个线程访问某个 UI 元素，而该线程不是创建该 UI 元素时所在的线程，则会引发 InvalidOperationException。调试器引发该异常以警告您存在危险的编程操作。UI 元素不是线程安全的，所以只应在创建它们的线程上进行访问"
从上面可以看出,这个异常实际是debugger耍的花招,也就是说,如果 你直接运行程序的exe文件,或者利用运行而不调试(Ctrl+F5)来运行你的程序,是不会抛出这样的异常的.大概ms发现v2003的警告对广大开发 者不起作用,所以用了一个比较狠一点的方法.
不过问题依然存在:既然这样设计的原因主要是因为控件的值非线程安全,那么DotNet framework中非线程安全的类千千万万,为什么偏偏跨线程修改Control的属性会有这样严格的限制策略呢?
这个问题我还回答不好,希望博友们能够予以补充
有没有什么办法可以简化WinForm多线程的开发
使用backgroundworker,使用这个组建可以避免回调时的Invoke和BeginInvoke,并且提供了许多丰富的方法和事件
参见.Net多线程总结(二)-BackgroundWorker,我在这里不再赘诉
线程池
线程池的作用是什么
作用是减小线程创建和销毁的开销
创建线程涉及用户模式和内核模式的切换，内存分配，dll通知等一系列过程，线程销毁的步骤也是开销很大的，所以如果应用程序使用了完一个线程，我们能把线程暂时存放起来，以备下次使用，就可以减小这些开销
所有进程使用一个共享的线程池,还是每个进程使用独立的线程池?
每 个进程都有一个线程池,一个Process中只能有一个实例，它在各个应用程序域（AppDomain）是共享的，.Net2.0 中默认线程池的大小为工作线程25个,IO线程1000个,有一个比较普遍的误解是线程池中会有1000个线程等着你去取,其实不然, ThreadPool仅仅保留相当少的线程，保留的线程可以用SetMinThread这个方法来设置，当程序的某个地方需要创建一个线程来完成工作时， 而线程池中又没有空闲线程时,线程池就会负责创建这个线程,并且在调用完毕后,不会立刻销毁,而是把他放在池子里,预备下次使用,同时如果线程超过一定时 间没有被使用,线程池将会回收线程，所以线程池里存在的线程数实际是个动态的过程
为什么不要手动线程池设置最大值?
当我首次看到线程池的时候,脑袋里的第一个念头就是给他设定一个最大值,然而当我们查看ThreadPool的SetMaxThreads文档时往往会看到一条警告:不要手动更改线程池的大小,这是为什么呢?
其 实无论FileStream的异步读写,异步发送接受Web请求,甚至使用delegate的beginInvoke都会默认调用 ThreadPool,也就是说不仅你的代码可能使用到线程池,框架内部也可能使用到,更改的后果影响就非常大,特别在iis中,一个应用程序池中的所有 WebApplication会共享一个线程池，对最大值的设定会带来很多意想不到的麻烦
线程池的线程为何要分类?
线 程池有一个方法可以让我们看到线程池中可用的线程数量:GetAvaliableThread(out workerThreadCount,out iocompletedThreadCount),对于我来说,第一次看到这个函数的参数时十分困惑,因为我期望这个函数直接返回一个整形,表明还剩多少 线程,这个函数居然一次返回了两个变量.
原来线程池里的线程按照公用被分成了两大类:工作线程和IO线程,或者IO完成线程,前者用于 执行普通的操作,后者专用于异步IO,比如文件和网络请求,注意,分类并不说明两种线程本身有差别,线程就是线程,是一种执行单元,从本质上来讲都是一样 的,线程池这样分类,举例来说,就好像某施工工地现在有1000把铁锹,规定其中25把给后勤部门用,其他都给施工部门,施工部门需要大量使用铁锹来挖地 基(例子土了点,不过说明问题还是有效的),后勤部门用铁锹也就是铲铲雪,铲铲垃圾,给工人师傅修修临时住房,所以用量不大，显然两个部门的铁锹本身没有 区别，但是这样的划分就为管理两个部门的铁锹提供了方便
线程池中两种线程分别在什么情况下被使用,二者工作原理有什么不同?
下面这个例子直接说明了二者的区别,我们用一个流读出一个很大的文件(大一点操作的时间长,便于观察),然后用另一个输出流把所读出的文件的一部分写到磁盘上
我们用两种方法创建输出流,分别是
创建了一个异步的流(注意构造函数最后那个true)
FileStream outputfs=new FileStream(writepath, FileMode.Create, FileAccess.Write, FileShare.None,256,true);
创建了一个同步的流
FileStream outputfs = File.OpenWrite(writepath);
然后在写文件期间查看线程池的状况
string readpath = "e:\RHEL4-U4-i386-AS-disc1.iso";
string writepath = "e:\kakakak.iso";
byte[] buffer = new byte[90000000];
//FileStream outputfs=new FileStream(writepath, FileMode.Create, FileAccess.Write, FileShare.None,256,true);
//Console.WriteLine("异步流");
//创建了一个同步的流
FileStream outputfs = File.OpenWrite(writepath);
Console.WriteLine("同步流");
//然后在写文件期间查看线程池的状况
ShowThreadDetail("初始状态");
FileStream fs = File.OpenRead(readpath);
fs.BeginRead(buffer, 0, 90000000, delegate(IAsyncResult o)
{
outputfs.BeginWrite(buffer, 0, buffer.Length,
delegate(IAsyncResult o1)
{
Thread.Sleep(1000);
ShowThreadDetail("BeginWrite的回调线程");
}, null);
Thread.Sleep(500);//this is important cause without this, this Thread and the one used for BeginRead May seem to be same one
},
null);
Console.ReadLine();
public static void ShowThreadDetail(string caller)
{
int IO;
int Worker;
ThreadPool.GetAvailableThreads(out Worker, out IO);
Console.WriteLine("Worker: {0}; IO: {1}", Worker, IO);
}
输出结果
异步流
Worker: 500; IO: 1000
Worker: 500; IO: 999
同步流
Worker: 500; IO: 1000
Worker: 499; IO: 1000
这两个构造函数创建的流都可以使用BeginWrite来异步写数据,但是二者行为不同,当使用同步的流进行异步写时,通过回调的输出我们可以看到,他使用的是工作线程,而非IO线程,而异步流使用了IO线程而非工作线程
其 实当没有制定异步属性的时候,.Net实现异步IO是用一个子线程调用fs的同步Write方法来实现的,这时这个子线程会一直阻塞直到调用完成.这个子 线程其实就是线程池的一个工作线程,所以我们可以看到,同步流的异步写回调中输出的工作线程数少了一,而使用异步流,在进行异步写时,采用了 IOCP方法,简单说来,就是当BeginWrite执行时,把信息传给硬件驱动程序,然后立即往下执行(注意这里没有额外的线程),而当硬件准备就绪, 就会通知线程池,使用一个IO线程来读取
.Net线程池有什么不足
没有提供方法控制加入线程池的线程:一旦加入线程池,我们没有办法挂起,终止这些线程,唯一可以做的就是等他自己执行
1)不能为线程设置优先级
2) 一个Process中只能有一个实例，它在各个AppDomain是共享的。ThreadPool只提供了静态方法，不仅我们自己添加进去的 WorkItem使用这个Pool，而且.net framework中那些BeginXXX、EndXXX之类的方法都会使用此Pool。
3)所支持的Callback不能有返回值。WaitCallback只能带一个object类型的参数，没有任何返回值。
4)不适合用在长期执行某任务的场合。我们常常需要做一个Service来提供不间断的服务（除非服务器down掉），但是使用ThreadPool并不合适。
下面是另外一个网友总结的什么不需要使用线程池,我觉得挺好,引用下来
如果您需要使一个任务具有特定的优先级。
如果您具有可能会长时间运行（并因此阻塞其他任务）的任务。
如果您需要将线程放置到单线程单元中（所有 ThreadPool 线程均处于多线程单元中）。
如果您需要与该线程关联的稳定标识。例如，您应使用一个专用线程来中止该线程、将其挂起或按名称发现它。
锁定与同步
CLR怎样实现lock(obj)锁定?
从原理上讲,lock和Syncronized Attribute都是用Moniter.Enter实现的,比如如下代码
object lockobj=new object();
lock(obj){
//do things
}
在编译时,会被编译为类似
try{
Moniter.Enter(obj){
//do things
}
}
catch{}
finally{
Moniter.Exit(obj);
}
而[MethodImpl(MethodImplOptions.Synchronized)]标记为同步的方法会在编译时被lock(this)语句所环绕
所以我们只简单探讨Moniter.Enter的实现
（注:DotNet并非使用Win32API的CriticalSection来实现Moniter.Enter，不过他为托管对象提供了一个类似的结构叫做Syncblk）
每 个对象实例头部都有一个指针,这个指针指向的结构,包含了对象的锁定信息,当第一次使用Moniter.Enter(obj)时,这个obj对象的锁定结 构就会被初时化,第二次调用Moniter.Enter时,会检验这个object的锁定结构,如果锁没有被释放,则调用会阻塞
WaitHandle是什么,他和他的派生类怎么使用
WaitHandle是Mutex，Semaphore，EventWaitHandler，AutoResetEvent，ManualResetEvent共同的祖先，他们包装了用于同步的内核对象，也就是说是这些内核对象的托管版本。
Mutex:类似于一个接力棒,拿到接力棒的线程才可以开始跑,当然接力棒一次只属于一个线程(Thread Affinity),如果这个线程不释放接力棒(Mutex.ReleaseMutex),那么没办法,其他所有需要接力棒运行的线程都知道能等着看热闹
Semaphore: 类似于一个小桶,里面装了几个小球,凡是拿到小球就可以跑,比如指定小桶里最初有四个小球,那么开始的四个线程就可以直接拿着自己的小球开跑,但是第五个 线程一看,小球被拿光了,就只好乖乖的等着有谁放一个小球到小桶里(Semophore.Release),他才能跑,但是这里的游戏规则比较特殊,我们 可以随意向小桶里放入小球,也就是说我可以拿走一个小球,放回去俩,甚至一个都不拿,放回去5个,这样就有五个线程可以拿着这些小球运行了.我们可以规定 小桶里有开始有几个小球(构造函数的第一个参数),也可以规定最多不能超过多少小球(构造函数的第二个参数)
ManualResetEvent,AutoResetEvent可以参考http://www.cnblogs.com/uubox/archive/2007/12/18/1003953.html
什么是用双锁实现Singleton,为什么要这样做,双锁检验是不安全的吗?
使用双锁检验技巧来实现单件,来自于Java社区
public static MySingleton Instance{
get{
if(_instance!=null)}{
lock(_instance){
if(s_value==null){
_instance= new MySingleton();
}
}
}
}
}
这样做其实是为了提高效率,比起
public static MySingleton Instance{
get{
lock(_instance){
if(s_value==null){
_instance= new MySingleton();
}
}
前一种方法在instance创建的时候不需要用lock同步,从而增进了效率
在java中这种技巧被证明是不安全的详细见http://www.cs.umd.edu/~pugh/java/memoryModel/
但是在.Net下,这样的技巧是成立的,因为.Net使用了改进的内存模型
并且在.Net下,我们可以使用LazyInit来实现单件
private static readonly _instance=new MySingleton()
public static MySingleton Instance{
get{return _instance}
}
当第一此使用_instance时,CLR会生成这个对象,以后再访问这个字段,将会直接返回
互斥对象（Mutex）,信号量(Semaphore),事件（Event）对象与lock语句的比较
首先这里所谓的事件对象不是System.Event，而是一种用于同步的内核机制
互斥对象和事件对象属于内核对象，利用内核对象进行线程同步，线程必须要在用户模式和内核模式间切换，所以一般效率很低，但利用互斥对象和事件对象这样的内核对象，可以在多个进程中的各个线程间进行同步。
lock或者Moniter是.net用一个特殊结构实现的,不涉及模式切换,也就是说工作在用户方式下，同步速度较快,但是不能跨进程同步
什么时候需要锁定?
刚刚接触锁定的程序员往往觉得这个世界非常的危险,每个静态变量似乎都有可能产生竞争
首先锁定是解决竞争条件的,也就是多个线程同时访问某个资源,造成意想不到的结果,比如,最简单的情况,一个计数器,如果两个线程同时加一,后果就是损失了一个计数,但是频繁的锁定又可能带来性能上的消耗,还有最可怕的情况,死锁
到底什么情况下我们需要使用锁,什么情况下不用呢?
只有共享资源才需要锁定
首先,只有可以被多线程访问的共享资源才需要考虑锁定,比如静态变量,再比如某些缓存中的值,属于线程内部的变量不需要锁定
把锁定交给数据库
数据库除了存储数据之外,还有一个重要的用途就是同步,数据库本身用了一套复杂的机制来保证数据的可靠和一致性,这就为我们节省了很多的精力.保证了数据源头上的同步,我们多数的精力就可以集中在缓存等其他一些资源的同步访问上了
了解你的程序是怎么运行的
实 际上在web开发中大多数逻辑都是在单个线程中展开的,无论asp.net还是php,一个请求都会在一个单独的线程中处理,其中的大部分变量都是属于这 个线程的,根本没有必要考虑锁定,当然对于asp.net中的application对象中的数据,我们就要小心一些了
WinForm中凡是使用BeginInvoke和Invoke调用的方法也都不需要考虑同步,因为这用这两个方法调用的方法会在UI线程中执行,因此实际是同步的,所以如果调用的方法中存在某些静态变量,不需要考虑锁定
业务逻辑对事务和线程安全的要求
这 条是最根本的东西,开发完全线程安全的程序是件很费时费力的事情,在电子商务等涉及金融系统的案例中,许多逻辑都必须严格的线程安全,所以我们不得不牺牲 一些性能,和很多的开发时间来做这方面的工作,而一般的应用中,许多情况下虽然程序有竞争的危险,我们还是可以不使用锁定,比如有的时候计数器少一多一, 对结果无伤大雅的情况下,我们就可以不用去管他
计算一下冲突的可能性
我以前曾经谈到过,架构不要过设计,其实在这里也一样,假 如你的全局缓存里的某个值每天只有几百或者几千个访问,并且访问时间很短,并且分布均匀(实际上这是大多数的情况),那么冲突的可能性就非常的少,也许每 500天才会出现一次或者更长,从7*24小时安全服务的角度来看,也完全符合要求,那么你还会为这样万分之一的可能性花80%的精力去设计吗?
请多使用lock,少用Mutex
如 果你一定要使用锁定,请尽量不要使用内核模块的锁定机制,比如.net的 Mutex,Semaphore,AutoResetEvent,ManuResetEvent,使用这样的机制涉及到了系统在用户模式和内核模式间的切 换,所以性能差很多,但是他们的优点是可以跨进程同步线程,所以应该清楚的了解到他们的不同和适用范围
Web和IIS
应用程序池,WebApplication,和线程池之间有什么关系
一个应用程序池是一个独立的进程,拥有一个线程池,应用程序池中可以有多个WebApplication,每个运行在一个单独的AppDomain中,这些WebApplication公用一个线程池
不同的AppDomain保证了每个WebApplication的静态变量不会互相干扰,不同的应用程序池保证了一个网站瘫痪,其他不同进程中的站点还能正常运行
下图说明了他们的关系
Web页面怎么调用异步WebService
把Page的Async属性设置为true,就可以调用异步的方法,但是这样调用的效果可能并不如我们的相像,请参考Web中使用多线程来增强用户体验
.Net多线程总结(一)
- 张小鱼 2010-10-22 09:48
.Net提供了许多多线程编程工具,可能是因为太多了,所以掌握起来总是有一些头疼,我在这里讲讲我总结的一些多线程编程的经验,希望对大家有帮助
不需要传递参数,也不需要返回参数
我们知道启动一个线程最直观的办法是使用Thread类,具体步骤如下
ThreadStart threadStart=new ThreadStart(Calculate);
Thread thread=new Thread(threadStart);
thread.Start();
public void Calculate(){
double Diameter=0.5;
Console.Write("The perimeter Of Circle with a Diameter of {0} is {1}"Diameter,Diameter*Math.PI);
}
例1
上 面我们用定义了一个ThreadStart类型的委托,这个委托制定了线程需要执行的方法:Calculate,在这个方法里计算了一个直径为0.5的圆 的周长,并输出.这就构成了最简单的多线程的例子,在很多情况下这就够用了,然后ThreadStart这个委托定义为void ThreadStart(),也就是说,所执行的方法不能有参数,这显然是个很大的不足,为了弥补这个缺陷,聪明的程序员想出了许多好的方法,我们将在需 要传递多个参数一节中进行介绍,这里我们先介绍.Net为了解决这个问题而设定的另外一个委托:就是ParameterizedThreadStart ,我会在下面详细讲述
需要传递单个参数
ParameterThreadStart的定义为void ParameterizedThreadStart(object state)??使用这个这个委托定义的线程的启动函数可以接受一个输入参数,具体例子如下
ParameterizedThreadStart threadStart=new ParameterizedThreadStart(Calculate)
Thread thread=new Thread()
thread.Start(0.9);
public void Calculate(object arg){
double Diameter=double(arg);
Console.Write("The perimeter Of Circle with a Diameter of {0} is {1}"Diameter,Diameter*Math.PI);
}
例2
Calculate方法有一个为object类型的参数,虽然只有一个参数,而且还是object类型的,使用的时候尚需要类型转换,但是好在可以有参数了,并且通过把多个参数组合到一个类中,然后把这个类的实例作为参数传递,就可以实现多个参数传递
需要传递多个参数
虽然通过把需要的参数包装到一个类中,委托ParameterizedThreadStart就可以传递多个参数,但是由于这个委托的传入参数是object,所以不可避免的需要进行参数转换,下面还有几个常用的参数传递方法,让我们来一一看来
使用专门的线程类
这 是许多程序员爱使用的经典模式,简单来说,就是把需要另起线程执行的方法,和他需要的参数放到一个类中,参数作为了类的属性,调用时声明此类的实例,然后 初始化属性,方法执行时直接使用类里初始化好的属性来执行,这样方法本身就可以不需要参数,而又起到了多参数传递的效果,于是使用本文最开始提到的不带参 数的ThreadStart委托就可以了,并且由于需要执行的方法和参数都放在一个类中,充分体现了面向对象的特点.具体方法如下
还是计算面积的方法的例子,我们把这个方法用一个类包装起来,输入参数Diameter(直径)是这个类的一个字段
public class MyThread
{
public double Diameter=10;
public double Result=0;
public MyThread(int Diameter)
{
this.Diameter = Diameter;
}
public void Calculate()
{
Console.WriteLine( "Calculate Start");
Thread.Sleep(2000);
Result = Diameter*Math.PI;;
Console.WriteLine("Calculate End, Diameter is {0},Result is {1}" ,this.Diameter, Result);
}
}
MyThread t=new MyThread(5.0);
ThreadStart threadStart=new ThreadStart(t.Calculate)
Thread thread=new Thread(threadStart);
thread.Start();
例3
这种方法把参数传递变成了属性共享,想传递多少个变量都可以,从封装上讲,把逻辑和逻辑涉及的数据封装在一起,也很不错,这个方法还有一个聪明的变体,利用了匿名方法,这种变体连独立的类都省掉了,我现在给出这个方法
double Diameter = 6;
double Result=0;
Thread ta = new Thread(new ThreadStart(delegate()
{
Thread.Sleep(2000);
Result=Diameter * Math.PI;
Console.WriteLine("匿名 Calculate End, Diameter is {0},Result is {1}", Diameter, Result); ;
}));
ta.Start();
例4
这 个方法和上例道理相同,都是把参数传递变成了对变量的调用,从而取消了参数传递,但是,后者充分利用了匿名方法的一个性质,就是可以直接使用当前上下文的 局部变量,比如委托中的Diameter,和Result.当然,这样做的缺点是如果匿名方法太长,程序的可读性会降低,所以一般很少有人这样做,这里给 出这个方法供大家参考,关于匿名委托的资料可以参见
聪明的读者肯定想,既然可以用字段来传入变量,当然也可以用字段传出变量,比如在上面两个例子里我们看到计算结果都写进了一个叫Result(加亮的地方)的变量里,我们直接访问这个变量不就可以得到计算结果了吗?
这样做有一个致命的问题:既然是异步执行,主线程怎么知道分线程什么时候完成了计算呢?比如上两个例子中,我们的线程都睡眠了2000毫秒,然后才进行计算,那么如果主线程在没有完成计算前访问Result,只能得到一个0值.于是我们就有了下面的一系列解决方法.
需要传递参数且需要返回参数
刚才说到主线程需要知道子线程什么时候执行完成,可以使用Thread.ThreadState枚举来判断
当 线程的ThreadState==ThreadState.Stop时,一般就说明线程完成了工作,这时结果就可用了,如果不是这个状态,就继续执行别的 工作,或者等待一会,然后再尝试.倘若需要等有多个子线程需的返回,并且需要用他们的结果来进行进异步计算,那就叫做线程同步了,下面我们介绍另外一种我 比较推荐的方法,能够自定义参数个数,并且返回数据,而且使用起来也相对方便
使用委托的异步调用方法和回调
首先我们要把需要异步调用的方法定义为一个委托,然后利用BeginInvoke来异步调用,BeginInvoke的第一个参数就是直径,第二个是当线程执行完毕后的调用的方法
delegate double CalculateMethod(double Diameter);
static CalculateMethod calcMethod;
double result = 0;
static void Main(string[] args)
{
calcMethod = new CalculateMethod(Calculate);
calcMethod.BeginInvoke(5, new AsyncCallback(TaskFinished), null);
}
///<summary>
///线程调用的函数
///<summary>
public static double Calculate(double Diameter)
{
return Diameter * Math.PI;
}
///<summary>
///线程完成之后回调的函数
///<summary>
public static void TaskFinished(IAsyncResult result)
{
result=calcMethod.EndInvoke(result);
}
例5
注意,再线程执行完毕后执行的方法TaskFinished中,我们使用了EndInvoke来取得这个函数的返回值
线程池
线程虽然是个好东西,但是也是个资源消耗大户,许多时候,我们需要用多线程,但是又不希望线程的数量过多,这就是线程池的作用,.Net为我们提供了现成的线程池ThreadPool,他的使用如下
WaitCallback w = new WaitCallback(Calculate);
ThreadPool.QueueUserWorkItem(w, 1.0);
ThreadPool.QueueUserWorkItem(w, 2.0);
ThreadPool.QueueUserWorkItem(w, 3.0);
ThreadPool.QueueUserWorkItem(w, 4.0);
public static void Calculate(double Diameter)
{
return Diameter * Math.PI;
}
例6
首 先定义一个WaitCallback委托,WaitCallback的格式是void WaitCallback(object state),也就是说你的方法必须符合这个格式,接着调用QueueUserWorkItem,将这个任务加入线程池,当县城池有空闲线时,将会调度并 运行你的代码
每一个进程都有一个线程池,线程池的默认大小是25,我们可以通过SetMaxThreads方法来设置其最大值.
[注]由于每个进程只有一个线程池,所以如果是在iis进程,或者sqlserver的进程中使用线程池,并且需要设置线程池的最大容量的话,会影响到iis进程或sql进程,所以这两种情况下要特别小心
控制权
在 和大家交谈的时候我发现凡是习惯了面向对象思维的同事,总是对多线程情况下的执行上下文很困扰,比如例5中,主程序启动了子线程执行Calculate方 法,执行完毕后回调TaskFinished,假如主线程id是1,子线程id是2,那么Calculate肯定是在id=2的线程中执行,那么他的回调 函数TaskFinished呢? 同样也是在id=2的线程上下文中执行,不信你输出线程id试试,这通常不是什么问题,但是当我们需要在Winform编程中使用子线程时,就有可能会引 起问题了,我们将在下面讲这个问题
窗体程序多线程编程的特殊性
当我们把例5的回调代码稍加修改,搬到winform里面,就可以看到问题所在了
public static void TaskFinished(IAsyncResult result)
{
result=calcMethod.EndInvoke(result);
this.TextBox1.Text=result;
}
程 序的原意是在线程执行完毕后讲结果写入一个TextBox,然而当程序执行到this.TextBox1.Text=result这里的时候就抱错了.原 来WinForm对线程有很严格的要求,除了创建这些控件的线程,其他线程想跨线程访问WinForm上的控件的属性和方法是不允许(除了几个特殊属 性),在有的版本系统上,比如XP,对这个问题进行了处理,跨线程控件访问可以被执行,但是大多数windows系统都是不可以的,那么如果我们确实需要 跨线程修改控件属性,或者调用控件的方法,就必须用到控件的一个方法Invoke,这个方法可以把执行上下文切换回创建这些控件的线程,具体操作如下
delegate void changeText(string result);
public static void TaskFinished(IAsyncResult result)
{
result=calcMethod.EndInvoke(result);
this.BeginInvoke(new changeText(this.textBox1.AppendText),t.Result.ToString())
}
由于委托中必须使用方法,所以我用AppendTex方法t,而不是直接设置Text属性,你如果想设置text属性,就必须自己包装一个方法,然后连接到委托了
不需要传递参数,也不需要返回参数
我们知道启动一个线程最直观的办法是使用Thread类,具体步骤如下
ThreadStart threadStart=new ThreadStart(Calculate);
Thread thread=new Thread(threadStart);
thread.Start();
public void Calculate(){
double Diameter=0.5;
Console.Write("The perimeter Of Circle with a Diameter of {0} is {1}"Diameter,Diameter*Math.PI);
}
例1
上 面我们用定义了一个ThreadStart类型的委托,这个委托制定了线程需要执行的方法:Calculate,在这个方法里计算了一个直径为0.5的圆 的周长,并输出.这就构成了最简单的多线程的例子,在很多情况下这就够用了,然后ThreadStart这个委托定义为void ThreadStart(),也就是说,所执行的方法不能有参数,这显然是个很大的不足,为了弥补这个缺陷,聪明的程序员想出了许多好的方法,我们将在需 要传递多个参数一节中进行介绍,这里我们先介绍.Net为了解决这个问题而设定的另外一个委托:就是ParameterizedThreadStart ,我会在下面详细讲述
需要传递单个参数
ParameterThreadStart的定义为void ParameterizedThreadStart(object state)??使用这个这个委托定义的线程的启动函数可以接受一个输入参数,具体例子如下
ParameterizedThreadStart threadStart=new ParameterizedThreadStart(Calculate)
Thread thread=new Thread()
thread.Start(0.9);
public void Calculate(object arg){
double Diameter=double(arg);
Console.Write("The perimeter Of Circle with a Diameter of {0} is {1}"Diameter,Diameter*Math.PI);
}
例2
Calculate方法有一个为object类型的参数,虽然只有一个参数,而且还是object类型的,使用的时候尚需要类型转换,但是好在可以有参数了,并且通过把多个参数组合到一个类中,然后把这个类的实例作为参数传递,就可以实现多个参数传递
需要传递多个参数
虽然通过把需要的参数包装到一个类中,委托ParameterizedThreadStart就可以传递多个参数,但是由于这个委托的传入参数是object,所以不可避免的需要进行参数转换,下面还有几个常用的参数传递方法,让我们来一一看来
使用专门的线程类
这 是许多程序员爱使用的经典模式,简单来说,就是把需要另起线程执行的方法,和他需要的参数放到一个类中,参数作为了类的属性,调用时声明此类的实例,然后 初始化属性,方法执行时直接使用类里初始化好的属性来执行,这样方法本身就可以不需要参数,而又起到了多参数传递的效果,于是使用本文最开始提到的不带参 数的ThreadStart委托就可以了,并且由于需要执行的方法和参数都放在一个类中,充分体现了面向对象的特点.具体方法如下
还是计算面积的方法的例子,我们把这个方法用一个类包装起来,输入参数Diameter(直径)是这个类的一个字段
public class MyThread
{
public double Diameter=10;
public double Result=0;
public MyThread(int Diameter)
{
this.Diameter = Diameter;
}
public void Calculate()
{
Console.WriteLine( "Calculate Start");
Thread.Sleep(2000);
Result = Diameter*Math.PI;;
Console.WriteLine("Calculate End, Diameter is {0},Result is {1}" ,this.Diameter, Result);
}
}
MyThread t=new MyThread(5.0);
ThreadStart threadStart=new ThreadStart(t.Calculate)
Thread thread=new Thread(threadStart);
thread.Start();
例3
这种方法把参数传递变成了属性共享,想传递多少个变量都可以,从封装上讲,把逻辑和逻辑涉及的数据封装在一起,也很不错,这个方法还有一个聪明的变体,利用了匿名方法,这种变体连独立的类都省掉了,我现在给出这个方法
double Diameter = 6;
double Result=0;
Thread ta = new Thread(new ThreadStart(delegate()
{
Thread.Sleep(2000);
Result=Diameter * Math.PI;
Console.WriteLine("匿名 Calculate End, Diameter is {0},Result is {1}", Diameter, Result); ;
}));
ta.Start();
例4
这 个方法和上例道理相同,都是把参数传递变成了对变量的调用,从而取消了参数传递,但是,后者充分利用了匿名方法的一个性质,就是可以直接使用当前上下文的 局部变量,比如委托中的Diameter,和Result.当然,这样做的缺点是如果匿名方法太长,程序的可读性会降低,所以一般很少有人这样做,这里给 出这个方法供大家参考,关于匿名委托的资料可以参见
聪明的读者肯定想,既然可以用字段来传入变量,当然也可以用字段传出变量,比如在上面两个例子里我们看到计算结果都写进了一个叫Result(加亮的地方)的变量里,我们直接访问这个变量不就可以得到计算结果了吗?
这样做有一个致命的问题:既然是异步执行,主线程怎么知道分线程什么时候完成了计算呢?比如上两个例子中,我们的线程都睡眠了2000毫秒,然后才进行计算,那么如果主线程在没有完成计算前访问Result,只能得到一个0值.于是我们就有了下面的一系列解决方法.
需要传递参数且需要返回参数
刚才说到主线程需要知道子线程什么时候执行完成,可以使用Thread.ThreadState枚举来判断
当 线程的ThreadState==ThreadState.Stop时,一般就说明线程完成了工作,这时结果就可用了,如果不是这个状态,就继续执行别的 工作,或者等待一会,然后再尝试.倘若需要等有多个子线程需的返回,并且需要用他们的结果来进行进异步计算,那就叫做线程同步了,下面我们介绍另外一种我 比较推荐的方法,能够自定义参数个数,并且返回数据,而且使用起来也相对方便
使用委托的异步调用方法和回调
首先我们要把需要异步调用的方法定义为一个委托,然后利用BeginInvoke来异步调用,BeginInvoke的第一个参数就是直径,第二个是当线程执行完毕后的调用的方法
delegate double CalculateMethod(double Diameter);
static CalculateMethod calcMethod;
double result = 0;
static void Main(string[] args)
{
calcMethod = new CalculateMethod(Calculate);
calcMethod.BeginInvoke(5, new AsyncCallback(TaskFinished), null);
}
///<summary>
///线程调用的函数
///<summary>
public static double Calculate(double Diameter)
{
return Diameter * Math.PI;
}
///<summary>
///线程完成之后回调的函数
///<summary>
public static void TaskFinished(IAsyncResult result)
{
result=calcMethod.EndInvoke(result);
}
例5
注意,再线程执行完毕后执行的方法TaskFinished中,我们使用了EndInvoke来取得这个函数的返回值
线程池
线程虽然是个好东西,但是也是个资源消耗大户,许多时候,我们需要用多线程,但是又不希望线程的数量过多,这就是线程池的作用,.Net为我们提供了现成的线程池ThreadPool,他的使用如下
WaitCallback w = new WaitCallback(Calculate);
ThreadPool.QueueUserWorkItem(w, 1.0);
ThreadPool.QueueUserWorkItem(w, 2.0);
ThreadPool.QueueUserWorkItem(w, 3.0);
ThreadPool.QueueUserWorkItem(w, 4.0);
public static void Calculate(double Diameter)
{
return Diameter * Math.PI;
}
例6
首 先定义一个WaitCallback委托,WaitCallback的格式是void WaitCallback(object state),也就是说你的方法必须符合这个格式,接着调用QueueUserWorkItem,将这个任务加入线程池,当县城池有空闲线时,将会调度并 运行你的代码
每一个进程都有一个线程池,线程池的默认大小是25,我们可以通过SetMaxThreads方法来设置其最大值.
[注]由于每个进程只有一个线程池,所以如果是在iis进程,或者sqlserver的进程中使用线程池,并且需要设置线程池的最大容量的话,会影响到iis进程或sql进程,所以这两种情况下要特别小心
控制权
在 和大家交谈的时候我发现凡是习惯了面向对象思维的同事,总是对多线程情况下的执行上下文很困扰,比如例5中,主程序启动了子线程执行Calculate方 法,执行完毕后回调TaskFinished,假如主线程id是1,子线程id是2,那么Calculate肯定是在id=2的线程中执行,那么他的回调 函数TaskFinished呢? 同样也是在id=2的线程上下文中执行,不信你输出线程id试试,这通常不是什么问题,但是当我们需要在Winform编程中使用子线程时,就有可能会引 起问题了,我们将在下面讲这个问题
窗体程序多线程编程的特殊性
当我们把例5的回调代码稍加修改,搬到winform里面,就可以看到问题所在了
public static void TaskFinished(IAsyncResult result)
{
result=calcMethod.EndInvoke(result);
this.TextBox1.Text=result;
}
程 序的原意是在线程执行完毕后讲结果写入一个TextBox,然而当程序执行到this.TextBox1.Text=result这里的时候就抱错了.原 来WinForm对线程有很严格的要求,除了创建这些控件的线程,其他线程想跨线程访问WinForm上的控件的属性和方法是不允许(除了几个特殊属 性),在有的版本系统上,比如XP,对这个问题进行了处理,跨线程控件访问可以被执行,但是大多数windows系统都是不可以的,那么如果我们确实需要 跨线程修改控件属性,或者调用控件的方法,就必须用到控件的一个方法Invoke,这个方法可以把执行上下文切换回创建这些控件的线程,具体操作如下
delegate void changeText(string result);
public static void TaskFinished(IAsyncResult result)
{
result=calcMethod.EndInvoke(result);
this.BeginInvoke(new changeText(this.textBox1.AppendText),t.Result.ToString())
}
由于委托中必须使用方法,所以我用AppendTex方法t,而不是直接设置Text属性,你如果想设置text属性,就必须自己包装一个方法,然后连接到委托了