最近在做站时发现，线程池的问题很棘手，所以总结了一篇关于线程池的文章，原文地址：http://www.shuonar.com/blog/ac16496b-87ec-4790-a9ea-d69bbffa1a87.html
在C#编程语言中，使用线程池可以并行地处理工作，.NETFramework提供了包含ThreadPool类的System.Threading 空间，这是一个可直接访问的静态类，该类对线程池是必不可少的。它是公共“线程池”设计样式的实现。对于后台运行许多各不相同的任务是有用的。对于单个的后台线程而言有更好的选项。
线程的最大数量。这是完全无须知道的。在.NET中ThreadPool的所有要点是它自己在内部管理线程池中线程。多核机器将比以往的机器有更多的线程。微软如此陈述“线程池通常有一个线程的最大数量，如果所有的线程都忙，增加的任务被放置在队列中直到它们能被服务，才能作为可用的线程。”
用法位置
线程池类型能被用于服务器和批处理应用程序中，线程池有更廉价的得到线程的内部逻辑，因为当需要时这些线程已被形成和刚好“连接”，所以线程池风格代码被用在服务器上。
MSDN表述：“线程池经常用在服务器应用程序中，每一个新进来的需求被分配给一个线程池中的线程，这样该需求能被异步的执行，没有阻碍主线程或推迟后继需求的处理。”
虽然线程池能大大提高服务器的并发性能，但使用它也会存在一定风险。与所有多线程应用程序一样，用线程池构建的应用程序容易产生各种并发问题，如对共享资源的竞争和死锁。此外，如果线程池本身的实现不健壮，或者没有合理地使用线程池，还容易导致与线程池有关的死锁、系统资源不足和线程泄漏等问题。
1．死锁
任何多线程应用程序都有死锁风险。造成死锁的最简单的情形是，线程A持有对象X的锁，并且在等待对象Y的锁，而线程B持有对象Y的锁，并且在等待对象X的锁。线程A与线程B都不释放自己持有的锁，并且等待对方的锁，这就导致两个线程永远等待下去，死锁就这样产生了。
虽然任何多线程程序都有死锁的风险，但线程池还会导致另外一种死锁。在这种情形下，假定线程池中的所有工作线程都在执行各自任务时被阻塞，它们都在等待某个任务A的执行结果。而任务A依然在工作队列中，由于没有空闲线程，使得任务A一直不能被执行。这使得线程池中的所有工作线程都永远阻塞下去，死锁就这样产生了。
2．系统资源不足
如果线程池中的线程数目非常多，这些线程会消耗包括内存和其他系统资源在内的大量资源，从而严重影响系统性能。
3．并发错误
线程池的工作队列依靠wait()和notify()方法来使工作线程及时取得任务，但这两个方法都难于使用。如果编码不正确，可能会丢失通知，导致工作线程一直保持空闲状态，无视工作队列中需要处理的任务。因此使用这些方法时，必须格外小心，即便是专家也可能在这方面出错。最好使用现有的、比较成熟的线程池。例如，直接使用java.util.concurrent包中的线程池类。
4．线程泄漏
使用线程池的一个严重风险是线程泄漏。对于工作线程数目固定的线程池，如果工作线程在执行任务时抛出 RuntimeException 或Error，并且这些异常或错误没有被捕获，那么这个工作线程就会异常终止，使得线程池永久失去了一个工作线程。如果所有的工作线程都异常终止，线程池就最终变为空，没有任何可用的工作线程来处理任务。
导致线程泄漏的另一种情形是，工作线程在执行一个任务时被阻塞，如等待用户的输入数据，但是由于用户一直不输入数据（可能是因为用户走开了），导致这个工作线程一直被阻塞。这样的工作线程名存实亡，它实际上不执行任何任务了。假如线程池中所有的工作线程都处于这样的阻塞状态，那么线程池就无法处理新加入的任务了。
5．任务过载
当工作队列中有大量排队等候执行的任务时，这些任务本身可能会消耗太多的系统资源而引起系统资源缺乏。
综上所述，线程池可能会带来种种风险，为了尽可能避免它们，使用线程池时需要遵循以下原则。
（1）如果任务A在执行过程中需要同步等待任务B的执行结果，那么任务A不适合加入到线程池的工作队列中。如果把像任务A一样的需要等待其他任务执行结果的任务加入到工作队列中，可能会导致线程池的死锁。
（2）如果执行某个任务时可能会阻塞，并且是长时间的阻塞，则应该设定超时时间，避免工作线程永久的阻塞下去而导致线程泄漏。在服务器程序中，当线程等待客户连接，或者等待客户发送的数据时，都可能会阻塞。可以通过以下方式设定超时时间：
调用ServerSocket的setSoTimeout(int timeout)方法，设定等待客户连接的超时时间，参见本章3.5.1节（SO_TIMEOUT选项）；
对于每个与客户连接的Socket，调用该Socket的setSoTimeout(inttimeout)方法，设定等待客户发送数据的超时时间，参见本书第2章的2.5.3节（SO_TIMEOUT选项）。
（3）了解任务的特点，分析任务是执行经常会阻塞的I/O操作，还是执行一直不会阻塞的运算操作。前者时断时续地占用CPU，而后者对CPU具有更高的利用率。预计完成任务大概需要多长时间？是短时间任务还是长时间任务？
根据任务的特点，对任务进行分类，然后把不同类型的任务分别加入到不同线程池的工作队列中，这样可以根据任务的特点，分别调整每个线程池。
（4）调整线程池的大小。线程池的最佳大小主要取决于系统的可用CPU的数目，以及工作队列中任务的特点。假如在一个具有 N 个CPU的系统上只有一个工作队列，并且其中全部是运算性质（不会阻塞）的任务，那么当线程池具有 N 或 N+1 个工作线程时，一般会获得最大的 CPU 利用率。
如果工作队列中包含会执行I/O操作并常常阻塞的任务，则要让线程池的大小超过可用CPU的数目，因为并不是所有工作线程都一直在工作。选择一个典型的任务，然后估计在执行这个任务的过程中，等待时间（WT）与实际占用CPU进行运算的时间（ST）之间的比例WT/ST。对于一个具有N个CPU的系统，需要设置大约N×(1+WT/ST)个线程来保证CPU得到充分利用。
当然，CPU利用率不是调整线程池大小过程中唯一要考虑的事项。随着线程池中工作线程数目的增长，还会碰到内存或者其他系统资源的限制，如套接字、打开的文件句柄或数据库连接数目等。要保证多线程消耗的系统资源在系统的承载范围之内。
（5）避免任务过载。服务器应根据系统的承载能力，限制客户并发连接的数目。当客户并发连接的数目超过了限制值，服务器可以拒绝连接请求，并友好地告知客户：服务器正忙，请稍后再试。
本文链接：http://www.cnblogs.com/shuonar/p/3164591.html，转载请注明。
一、引言
之前一直都是写一些C#基础知识的内容的，然而有些初学者可能看完了这些基础知识之后，会有这样一个疑惑的——我了解了这些基础知识之后，我想做一些工具怎么还是不会做的呢？那些基础知识到底有什么用的了？然而我刚开始写这个系列的初衷主要是我想系统地去研究下C#各个阶段的特性的，及时有些特性我知道它是怎么用的，但是每次遇到问题的时候确实百度可以可以解决很多问题，但是自己总是觉得有点“虚”，然而通过写完这个系列之后，我很多知识点都可以串起来了，可以做到一个举一反三的一个效果的，当我遇到实际问题的也不可能完全自己写出来，同样也会百度找解决方案，但是此时我却没有 “虚”的感觉，因为我知道这个东西，并且我也知道如何正确的百度这个问题。所以对于基础知识的学习还是很有必要的，因为系统学完之后，你可以更好地找到你遇到问题的答案，因为我有时候会看到一些朋友在QQ群中提到，遇到某个问题都不知道百度什么的，然而系统地学习基础完全可以帮助你快速地百度，（其实找答案也是一种能力），然而对于第一个疑惑的解答就是——系统学习完，确实刚开始的确开发工具不会做，但是实际写代码是很简单，并且现在大部分应用你百度下都可以找到的，所以代码并不是问题，主要是解决问题的思路，并且实际工具的开发也是对一个基础知识的巩固，从而对问题达到一个举一反三的效果。
上面说了这么多的（可能说的有点多），主要是让大家明白，系统学习C#基础知识是很有必要的，系统学习完C#基础知识之后就是代码量的积累了，也就是自己做一些小工具，积累到一定代码量之后，就可以尝试写写一些大的项目或开源项目等，所以在后面的系列中将会分享一些具体工具的开发，同时这也是我自己的一个学习的计划，这里分享给大家希望对一些迷茫的朋友有所帮助。如果你现在还没有明确或更好地目标，并且也是从事.NET工作或学习的朋友，那就和我一起静下心来学编程，下面是我的一个学习方向图（可能多少有点偏差，相信大致意图大家可以明白）：
二、实现思路
�嗦了这么多，下面就具体介绍下实现截图工具的实现思路。
为了让大家更清楚地知道如何去实现自己的截图工具，首先我来描述下截图的一个过程——我们使用QQ的截图工具和Windows 自带的截图工具都可以发现，当我们点击QQ窗体中的截图按钮时，此时我们将看到一个全屏图片，然后我们可以在其上截图,当鼠标左键按下时，即代表开始截图，并我们可以移动鼠标来改变截图的大小，鼠标弹起时即代表结束截图，此时我们可以双击矩形区域完全截图，并且可以通过粘贴操作把截取的图片粘贴到聊天窗口的发送区，鼠标右键点击则是退出截图。这样我们截图的过程描述就是这样的，从这个描述中我们就可以抽象出实现我们截图工具的思路来：
- 从 “此时我们将看到一个全屏图片”这句话描述我们应该抽象为——对于QQ截图工具的实现来说，我们看到的这个全屏图片其实并不是一张“图片”(这里最好不要钻空子)，而是一个窗体，这个窗体我们命名为 “截图窗体”，只是把窗体的背景图片设置为全屏图片。说到这里，一些没有研究过QQ截图工具的人开始有疑问了——我们看到的是窗体？那为什么边框的，即没有最大化按钮，最下化按钮的呢？（对于这点的解释就是，程序中可以设置Form的BorderStyle属性为none的方式来隐藏掉边框）。
- 既然要设置窗体的背景图片为全屏图片，我们知道设置背景图片只需要设置窗体的BackgroundImage属性就好了，但是全屏图片怎么获取呢？既然是全屏图片，自然我就应该使窗体最大化话了，不然我们看到只是一个没有边框的“小图片”了，而不是一个全屏的图片。下面是具体实现这个分析的代码：
// 拷贝完成之后，CatchBmp就是全屏图片的拷贝了，然后指定为截图窗体背景图片就好了。
// 新建一个和屏幕大小相同的图片
Bitmap CatchBmp = new Bitmap(Screen.AllScreens[0].Bounds.Width, Screen.AllScreens[0].Bounds.Height);
// 创建一个画板，让我们可以在画板上画图
// 这个画板也就是和屏幕大小一样大的图片
// 我们可以通过Graphics这个类在这个空白图片上画图
Graphics g = Graphics.FromImage(CatchBmp);
// 把屏幕图片拷贝到我们创建的空白图片 CatchBmp中
g.CopyFromScreen(new Point(0, 0), new Point(0, 0), new Size(Screen.AllScreens[0].Bounds.Width, Screen.AllScreens[0].Bounds.Height));
// 创建截图窗体
cutter = new Cutter();
// 指示窗体的背景图片为屏幕图片
cutter.BackgroundImage = CatchBmp;
3. 从 “然后我们可以在其上截图”这句话中我们抽象为——其实我们截图操作，从程序角度来说就是我们在这个最大化的窗体中画图，可能这个对一些不了解GDI+画图的朋友有些难理解，这里做个比喻——我们会拿笔在纸上画图，我们可以用比画三角形，矩形已经各种图形，此时纸就是我们一个画板，笔是用来画图图形的，同时笔也是有颜色和粗细的，我们可以用红色水笔画，画出来的图就是红色的了，也可以用黑色水笔画，自然画出来的就是黑色的了，同样，在GDI+也就是Graphics Device Interface Plus也就是图形设备接口，在.NET 中也提供了一些这样的类来让我们实现对图像的访问，也就是我们可以使用.NET中提供的类来进行 “画画”，要画画当然必须要有画板吧（我们开始比喻中纸就是画板）,在.NET 类中Graphics类就是对画板的抽象，画板可以由三种方式创建：（1）从图片或继承自图像对象中创建；（2）从窗体或控件的Paint事件中创建；（3）利用窗体或控件的CreateGraphics方法创建。有了画板之后，当然就需要笔来画画了，在.NET 中Pen类就是起到笔的作用，在构造函数中可以指定笔的颜色和粗细，有了笔之后就是开始画图了，在.NET中也同样提供了一些方法来完成画图，如DrawRectangle方法——画矩形
4. 从 “当鼠标左键按下时，即代表开始截图，并我们可以移动鼠标来改变截图的大小，鼠标弹起时即代表结束截图，此时我们可以双击矩形区域完全截图，并且可以通过粘贴操作把截取的图片粘贴到聊天窗口的发送区，鼠标右键点击则是退出截图”这些描述中可以抽象为——鼠标的移动，按下，弹起等操作，在程序角度来说，也就是实现截图窗体的MouseMove事件（对应于鼠标移动），MouseDown事件（对应于鼠标左键按下），MouseClick事件（对应于鼠标右键结束截图）、MouseUp(对应于鼠标弹起结束截图)和MouseDoubleClick(鼠标双击矩形区域完全截图，并可以通过粘贴操作把截取的图片粘贴到聊天窗口的发送区，既然可以进行粘贴操作来获得截取图片，所以必须在该事件中对剪切板设置截图图片)，3和4的分析过程也是截图功能的核心实现，对应于下面的代码（代码中有详细解释，并且大家理解的时候可以结合3和4的分析）：
/// 鼠标右键点击结束截图
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void Cutter_MouseClick(object sender, MouseEventArgs e)
{
if (e.Button == MouseButtons.Right)
{
this.DialogResult = DialogResult.OK;
this.Close();
}
}
/// <summary>
/// 鼠标按下事件处理程序
/// </summary>
/// <param name="sender"></param>
///阅读更多内容
没有评论:
发表评论