其实早在两年前，笔者就耳闻博锐技术基于“软硬兼施”的安全与管理解决方案，碍于无缘体验，一直是扑朔迷离。

2009年4月17日，笔者有幸参与了2009英特尔博锐技术应用宣讲会，期间，英特尔解决方案部中国大区技术部经理梁岩分享了博锐技术的最新应用和成功经验，而来自联想公司的代表更是在现场演示了联想基于博锐平台的创新应用。终于,在了解博锐技术知识的同时，更使笔者享受到一次身心愉悦的博锐应用之旅。

博锐技术应用之旅——商用电脑新高峰

在会上,厂商为我们展示了基于英特尔迅驰2博锐处理器平台和英特尔酷睿2博锐处理器平台关于安全性与可管理性的宣讲和演示。这一基于硬件的技术在重大IT挑战面前，无疑是一个里程碑式的事件。过去，企业诸如系统在关机时难以管理、企业防火墙外的笔记本电脑之间的通信不安全、不断增加的昂贵的现场访问费用支出、未受保护或者难以发现的硬件资产损失、难以实现的配置一致性、耗时耗力的人工盘点等问题给企业造成了很多不便和经营障碍……透过联想基于博锐平台的创新应用的现场演示过程，笔者看到这些难题在博锐技术面前，已不再是难题。

博锐技术应用体验——一个典型的示例

我们知道，诸如Netman、Remote Administrator、PcAnywhere等远程控制软件，已经将远程控制技术发挥得淋漓尽致。随着技术的发展，远程控制从传统的使用NETBEUI、NETBIOS、IPX/SPX、TCP/IP等协议来实现操控，到通过Web页面以Java技术来控制远程电脑；从对等操作系统间到跨越平台的远程控制，技术的发展越见成熟。

但是，基于软件的远程控制技术，其局限性是很明显的。一、在某些情况下，如，当被控端处于关机或系统崩溃状态时，主控端发出的远程控制指令很难得到任何的反馈；二：主控端能够取得控制权的host数量一般都是很有限的，大多数情况下也是不安全的；三：大多数软件，主控端施予被控端的操作是一对一的，很难统一集群操作；四：主控端能够实现的远程操作类别受诸多因素影响，非常有限；五、基于软件的远程控制缺乏主动性。

下面，我们来看一个联想基于博锐平台的应用演示：

如上图，在博锐技术的支持下，演示人员通过图中的IT控制台（VPRO控制台），对一台无法启动系统的客户机进行系统检测和修复，并对其执行开机操作。

如果我们将这个演示过程简单理解成是基于硬件的远程控制，那么，这种远程控制的突破就在于，通过对虚拟技术的支持以及英特尔主动管理技术，它跨越了传统的基于软件的远程控制技术的局限：不受客户机系统因素影响导致操控失败、不受host数量限制、对客户机完整的集群操作、管理台能够完成几乎所有的等同于客户机本机操作的计算机操作、管理台主动操作、基于处理器的内建安全性等等。

这项技术的应用将是企业IT管理的革命。试想，在一个传统的企业办公网络内，一旦某一机子出现系统故障，IT管理人员面对的将是喋喋不休的电话问询，问询无法解决的更是只能亲临现场排查故障。企业规模越大，IT管理人员现场访问的次数也就越多，为此，企业不得不支付高昂的IT管理费用。而当企业部署了计算机群都处于博锐技术的控制之下后，上述问题将迎刃而解。

当然，以上的例子只是博锐技术展示中的一个典型示例。 整个会议过程中 ,笔者都有很深的感慨和体会。 毋庸置疑，博锐技术的应用将会成为企业商务化管理的一个重要体现和趋势性发展的必然结果。 当然这里也很荣幸的被邀请参与到体验的过程中,见证酷睿2博锐时代的发展和辉煌时刻的到来。 今后，我将以使用或体验者的身份，等待真正近距离接触博锐的机会。 拭目以待。

Concurrency and Python

http://www.ddj.com/linux-open-source/206103078

Python Threads and the Global Interpreter Lock

http://jessenoller.com/2009/02/01/python-threads-and-the-global-interpreter-lock/

 
本来是应该从并行、多线程、竞争、锁这些东西谈起，不过我想一般大家都该挺熟的，不熟悉的话也很容易找到资料，这里就偷懒略过了。

Python的多线程模型基本上是Java多线程模型的简化版，提供了线程基类、锁、信号量，事件等待组件，虽然也少了一些功能，比如线程不能被销毁、中止、暂停、恢复等待，基本上可以让程序员比较方便的进行多线程编程。在CPython解释器中，存在一个叫Global Interpreter Lock(GIL)的东西，直译就是全局解释器锁，它的作用在于让同一时刻只能有一个线程对于python对象进行操作。Python已经提供了各种机制让我们进行多线程同步，为什么又要整这个GIL呢？这是因为程序员控制的同步是对各个程序中可见的变量，而GIL同步的是解释器后台的不可见变量，比如为了进行垃圾回收而维护的引用计数。如果没有GIL，有可能出现由于线程切换导致的对同一个对象释放两次的情况。

因此，任何一个CPython线程如果要执行，就必须先获取这个GIL。后果？就是在CPython中，本质上几乎是没有线程并行的，不论你开多少个线程，同一时刻只有获取GIL的那个线程能够执行。为什么要说几乎呢，这是因为提供给python的C库中，还是有解决方案的，比如

这段代码是sleep的代码，在执行sleep之前，通过一个宏来释放GIL，然后在睡眠结束执行其他代码前又获取GIL。其他一下操作，比如IO，也会有类似的操作，这样就使得对于IO密集型的程序，或者是使用C库进行计算的程序，还是可以在很大程度上避开GIL来取得线程并行的效果的。但对于纯python代码的程序，GIL恐怕还是躲不过去的。

还有一个问题，就是GIL怎么释放，我们看到在python/C API中提供了宏来进行释放，那么对于普通的python语句呢？解释器会在执行一百条python代码后强制释放GIL，这就使得其它线程得以执行。

最后需要说明的，就是这个GIL的问题是解释器相关的，而不是语言相关的。也就是说它只是对于python语言解释器的一种实现，并不是语言本身的特性。事实上，GIL就是解释器的一个非常粗粒度的锁，我们完全可以采用更细粒度的锁来增加并行性，而且Gindo就写过一个patch来取消GIL，不过好像最后的结果是细粒度锁导致了单线程程序的性能下降了两倍，所以最后还是决定优先保证单线程程序的性能，继续保留GIL。但是python的其他两个分支，Jython和IronPython，却都没有GIL的问题，从而可以实现线程的并行。为什么呢？你知道了麻烦给我说说。。。

今天在测试一个东西时发现，谷歌浏览器与IE浏览器可能在多线程处理方面有根本差别。我是指，如果浏览器在等待一个请求的响应时，如果有一部分已经输出到了浏览器中，那么对于这一部分的展现是否可以并行处理？

例如，我需要等待一个很长时间的页面，为了减少用户的焦虑，我们可能会用一个进度条的方式。这个进度条可能是一个gif图片。我发现在谷歌浏览器中，gif图片可以正常工作（即便浏览器当前还在等待更多的响应），而IE却不行。傲游也不行（因为它也是IE内核）

可以看到那个进度条在动。

而同样的页面，如果用IE打开，则一动不动。

作者：陈希章
出处：http://blog.csdn.net/chen_xizhang

最近在看北电代码的时候，发现，系统中大部分模块都采用的是一个进程/一个线程的设计方式，一个大的功能模块由多个进程构成。因为系统是运行在Linux平台上，一开始，我觉得这种设计是有问题，追溯根源，以为是北电之前使用的操作系统是vxworks,那帮北美的开发人员把vxworks中task的概念生搬硬套到linux中，在linux中提供了比进程性能更高的线程，他们并没有充分的利用起来。之后认真思考了一下，发现，他们这样设计是有道理的。分析如下，我们先来说说进程和线程的区别吧。

区别:

1. 进程是资源拥有的基本单位，线程是调度的基本单位，在CPU上调度的是线程，当任务切换的时候，需要将资源进行保存。

2. 在一个进程内部可以运行多个线程，线程切换不需要资源保存，这些线程共享进程的资源，地址空间。进程切换需要资源保存。

3. 进程之间的同步是可以通过各种IPC，各种进程锁，信号量，信号来实现，比如文件锁，自旋锁，RCU等。而线程之间的同步可以通过进程内部锁来实现，比如互斥锁，读写锁等。

在设计中为什么要使用多进程单线程的这种模式呢？我的理解如下:

1. 增加整个系统的健壮性，比如一个进程做两件事情，任何一件事情做失败都会导致另外一件事情不能做。如果将这个进程里的功能解耦，系统的健壮性自然也随之增强。单点故障的几率减小。

2. 从开发角度讲，这种解耦也便于系统升级，对其中的某一个模块升级变得更加容易而不会影响到其他功能模块。

3. 虽然性能不如多线程，但是多线程编程适用于高级程序员，对编程技巧要求高。使用多进程其实性能差别就在于进程切换资源保存部分，多线程模型会把进程间数据传递的开销转到锁开销上。

4. 减小整个会话阻塞在单个进程中，使得整个系统的吞吐量增大。

以上理解，是我对多进程/单线程模型的一点心得。

2台液晶，1X15, 1X24
HP彩色激光打印机1台，HP彩喷一体机1台

硬盘若干，内存若干。

底板若干。CPU若干－后两项可以忽略。卖废品的都不要。。。悲剧阿。。。

不过底板和CPU都不能用了。硬盘和内存倒是能利用起来。网上有不少双屏显的贴子。看着我也动心，打算这么干了。计算了下，如果利用旧机再加钱买点新配件。花费并不高。所以我正式决心开始干了，没想到这是折磨的开始

再放些图片。是为这次升级而购买的器材的一些箱子，大家可能注意到，那些箱子大部分是DELL的。其实最初不是的。前面到的一些货我没来得及在退货前拍下来。是一些散件。至于为什么会有退货的过程。也是一个故事了。这次我分包从新蛋和京东都定了货。也顺便比较了他们的服务。当然也包括退货的服务了。。

列出下面我会写的部分。看看大家是否有兴趣。有兴趣就继续写下去。咔咔
大户室构思篇和方案篇
寻找有缘分的配件之路
第一批货到了！折磨开始了
烤机失败！退货！灾难第一重
支架的DIY
各显示器，CPU和显卡的对比与选择
组装！起航！

打造家庭大户室之路系列专题：
打造家庭大户室之路:预告片
打造家庭大户室之路:起步篇I
打造家庭大户室之路:没有最贵,只有更贵的构思和方案

这款3G机其实是中兴和广讯通的合作产品。广讯通的EKING I1大家应该知道吧。带BT+WIFI.但是唯独少了3G.实际硬件内是预留了SIM卡槽的。而现在，中兴和它的合作弥补了这个缺陷

先看看他的配置
INTEL ATOM芯片－－INTEL啊INTEL. 我的最爱了。。我是INTEL的FANS..

1G内存－偏小了
XP HOME－软件应用广了
摄像头130W像素－在某些评测里面将这个摄像头夸的花好稻好。。我就不说了。。我尝试了拍了几张。。拍的象鬼就不说了。。还都拍糊了。。
WIFI,BT

EKING的外形，注意右侧那张白色小胶布，上面写着的就是中兴3G 测试机的字样

各位再看看韩国的WIBRAIN吧。是不是完全一样？

EKING的接口。接口还是比较全的。但是做工真是很差。有点廉价的感觉。为什么不能用点金属质感强的塑料件呢？我甚至能感觉到表面的毛刺

多线程概述

　　进程和线程都是操作系统的概念。进程是应用程序的执行实例，每个进程是由私有的虚拟地址空间、代码、数据和其它各种系统资源组成，进程在运行过程中创建的资源随着进程的终止而被销毁，所使用的系统资源在进程终止时被释放或关闭。
　　线程是进程内部的一个执行单元。系统创建好进程后，实际上就启动执行了该进程的主执行线程，主执行线程以函数地址形式，比如说main或WinMain函数，将程序的启动点提供给Windows系统。主执行线程终止了，进程也就随之终止。
　　每一个进程至少有一个主执行线程，它无需由用户去主动创建，是由系统自动创建的。用户根据需要在应用程序中创建其它线程，多个线程并发地运行于同一个进程中。一个进程中的所有线程都在该进程的虚拟地址空间中，共同使用这些虚拟地址空间、全局变量和系统资源，所以线程间的通讯非常方便，多线程技术的应用也较为广泛。
　　多线程可以实现并行处理，避免了某项任务长时间占用CPU时间。要说明的一点是，目前大多数的计算机都是单处理器（CPU）的，为了运行所有这些线程，操作系统为每个独立线程安排一些CPU时间，操作系统以轮换方式向线程提供时间片，这就给人一种假象，好象这些线程都在同时运行。由此可见，如果两个非常活跃的线程为了抢夺对CPU的控制权，在线程切换时会消耗很多的CPU资源，反而会降低系统的性能。这一点在多线程编程时应该注意。
　　Win32 SDK函数支持进行多线程的程序设计，并提供了操作系统原理中的各种同步、互斥和临界区等操作。Visual C++ 6.0中，使用MFC类库也实现了多线程的程序设计，使得多线程编程更加方便。

Win32 API对多线程编程的支持

　　Win32 提供了一系列的API函数来完成线程的创建、挂起、恢复、终结以及通信等工作。下面将选取其中的一些重要函数进行说明。

1、HANDLE CreateThread(LPSECURITY_ATTRIBUTES lpThreadAttributes,

DWORD dwStackSize,

LPTHREAD_START_ROUTINE lpStartAddress,

LPVOID lpParameter,

DWORD dwCreationFlags,

LPDWORD lpThreadId);

该函数在其调用进程的进程空间里创建一个新的线程，并返回已建线程的句柄，其中各参数说明如下：

lpThreadAttributes：指向一个 SECURITY_ATTRIBUTES 结构的指针，该结构决定了线程的安全属性，一般置为 NULL；

dwStackSize：指定了线程的堆栈深度，一般都设置为0；

lpStartAddress：表示新线程开始执行时代码所在函数的地址，即线程的起始地址。一般情况为(LPTHREAD_START_ROUTINE)ThreadFunc，ThreadFunc 是线程函数名；

lpParameter：指定了线程执行时传送给线程的32位参数，即线程函数的参数；

dwCreationFlags：控制线程创建的附加标志，可以取两种值。如果该参数为0，线程在被创建后就会立即开始执行；如果该参数为CREATE_SUSPENDED,则系统产生线程后，该线程处于挂起状态，并不马上执行，直至函数ResumeThread被调用；

lpThreadId：该参数返回所创建线程的ID；

如果创建成功则返回线程的句柄，否则返回NULL。

2、DWORD SuspendThread(HANDLE hThread);

该函数用于挂起指定的线程，如果函数执行成功，则线程的执行被终止。

3、DWORD ResumeThread(HANDLE hThread);

该函数用于结束线程的挂起状态，执行线程。

4、VOID ExitThread(DWORD dwExitCode);

该函数用于线程终结自身的执行，主要在线程的执行函数中被调用。其中参数dwExitCode用来设置线程的退出码。

5、BOOL TerminateThread(HANDLE hThread,DWORD dwExitCode);

　　一般情况下，线程运行结束之后，线程函数正常返回，但是应用程序可以调用TerminateThread强行终止某一线程的执行。各参数含义如下：

hThread：将被终结的线程的句柄；

dwExitCode：用于指定线程的退出码。

使用TerminateThread()终止某个线程的执行是不安全的，可能会引起系统不稳定；虽然该函数立即终止线程的执行，但并不释放线程所占用的资源。因此，一般不建议使用该函数。

6、 BOOL GetExitCodeThread(

HANDLE hThread, // handle to the thread

LPDWORD lpExitCode // address to receive termination status

);

得到终止线程状态，如果状态为STILL_ACTIVE，线程没有终止，否则线程终止。

7、BOOL PostThreadMessage(DWORD idThread,

UINT Msg,

WPARAM wParam,

LPARAM lParam);

该函数将一条消息放入到指定线程的消息队列中，并且不等到消息被该线程处理时便返回。

idThread：将接收消息的线程的ID；

Msg：指定用来发送的消息；

wParam：同消息有关的字参数；

lParam：同消息有关的长参数；

调用该函数时，如果即将接收消息的线程没有创建消息循环，则该函数执行失败。

注：没有对应SendThreadMessage函数，因为SendMessage是不安全的，发送消息到一个窗口，自己等待，消息处理完成之后返回。如果消息始终没有处理完成返回的话，就会存在死锁问题，所以线程中没有对应SendThreadMessage之类的函数。

SendMessag、PostMessage、GetMessage、PeekMessage区别

SendMessag是发送消息到另一个窗口，自己等待，消息处理完成之后返回。（表面上另一个窗口消息处理是自己窗口来执行完成的，其实另一个窗口消息处理真正的执行者是SendMessag这个窗口）

PostMessage是发送消息到消息队列中，自己马上返回。

GetMessage消息过滤，等到有合适的消息时才返回，同时会将消息从队列中删除。

PeekMessage消息过滤，查看了一下消息队列，PeekMessage可以设置最后一个参数wRemoveMsg来决定是否将消息保留在队列中。

MFC对多线程编程的支持

　　MFC中有两类线程，分别称之为工作者线程和用户界面线程。二者的主要区别在于工作者线程没有消息循环，而用户界面线程有自己的消息队列和消息循环。
　　工作者线程没有消息机制，通常用来执行后台计算和维护任务，如冗长的计算过程，打印机的后台打印等。用户界面线程一般用于处理独立于其他线程执行之外的用户输入，响应用户及系统所产生的事件和消息等。但对于Win32的API编程而言，这两种线程是没有区别的，它们都只需线程的启动地址即可启动线程来执行任务。
　　在MFC中，一般用全局函数AfxBeginThread()来创建并初始化一个线程的运行，该函数有两种重载形式，分别用于创建工作者线程和用户界面线程。两种重载函数原型和参数分别说明如下：

(1) CWinThread* AfxBeginThread(AFX_THREADPROC pfnThreadProc,

LPVOID pParam,

nPriority=THREAD_PRIORITY_NORMAL,

UINT nStackSize=0,

DWORD dwCreateFlags=0,

LPSECURITY_ATTRIBUTES lpSecurityAttrs=NULL);

PfnThreadProc:指向工作者线程的执行函数的指针，线程函数原型必须声明如下：

UINT ExecutingFunction(LPVOID pParam);

请注意，ExecutingFunction()应返回一个UINT类型的值，用以指明该函数结束的原因。一般情况下，返回0表明执行成功。

pParam：传递给线程函数的一个32位参数，执行函数将用某种方式解释该值。它可以是数值，或是指向一个结构的指针，甚至可以被忽略；

nPriority：线程的优先级。如果为0，则线程与其父线程具有相同的优先级；

nStackSize:线程为自己分配堆栈的大小，其单位为字节。如果nStackSize被设为0，则线程的堆栈被设置成与父线程堆栈相同大小；

dwCreateFlags：如果为0，则线程在创建后立刻开始执行。如果为CREATE_SUSPEND，则线程在创建后立刻被挂起；

lpSecurityAttrs：线程的安全属性指针，一般为NULL；

(2) CWinThread* AfxBeginThread(CRuntimeClass* pThreadClass,

int nPriority=THREAD_PRIORITY_NORMAL,

UINT nStackSize=0,

DWORD dwCreateFlags=0,

LPSECURITY_ATTRIBUTES lpSecurityAttrs=NULL);

pThreadClass 是指向 CWinThread 的一个导出类的运行时类对象的指针，该导出类定义了被创建的用户界面线程的启动、退出等；其它参数的意义同形式1。使用函数的这个原型生成的线程也有消息机制，在以后的例子中我们将发现同主线程的机制几乎一样。

下面我们对CWinThread类的数据成员及常用函数进行简要说明。

m_hThread：当前线程的句柄；

m_nThreadID:当前线程的ID；

m_pMainWnd：指向应用程序主窗口的指针.

线程间通讯

　　一般而言,应用程序中的一个次要线程总是为主线程执行特定的任务,这样,主线程和次要线程间必定有一个信息传递的渠道,也就是主线程和次要线程间要进行通信。这种线程间的通信不但是难以避免的，而且在多线程编程中也是复杂和频繁的，下面将进行说明。

使用全局变量进行通信

由于属于同一个进程的各个线程共享操作系统分配该进程的资源，故解决线程间通信最简单的一种方法是使用全局变量。对于标准类型的全局变量，我们建议使用volatile 修饰符，它告诉编译器无需对该变量作任何的优化，即无需将它放到一个寄存器中，并且该值可被外部改变。如果线程间所需传递的信息较复杂，我们可以定义一个结构，通过传递指向该结构的指针进行传递信息。
　

使用自定义消息

我们可以在一个线程的执行函数中向另一个线程发送自定义的消息来达到通信的目的。一个线程向另外一个线程发送消息是通过操作系统实现的。利用Windows操作系统的消息驱动机制，当一个线程发出一条消息时，操作系统首先接收到该消息，然后把该消息转发给目标线程，接收消息的线程必须已经建立了消息循环。

线程的同步

　　虽然多线程能给我们带来好处，但是也有不少问题需要解决。例如，对于像磁盘驱动器这样独占性系统资源，由于线程可以执行进程的任何代码段，且线程的运行是由系统调度自动完成的，具有一定的不确定性，因此就有可能出现两个线程同时对磁盘驱动器进行操作，从而出现操作错误。
使隶属于同一进程的各线程协调一致地工作称为线程的同步。MFC提供了多种同步对象，下面我们只介绍最常用的四种：

临界区（CCriticalSection）

事件（CEvent）

互斥量（CMutex）

信号量（CSemaphore）

A、使用 CCriticalSection 类

　　当多个线程访问一个独占性共享资源时,可以使用“临界区”对象。任一时刻只有一个线程可以拥有临界区对象，拥有临界区的线程可以访问被保护起来的资源或代码段，其他希望进入临界区的线程将被挂起等待，直到拥有临界区的线程放弃临界区时为止，这样就保证了不会在同一时刻出现多个线程访问共享资源。

CCriticalSection类的用法非常简单，步骤如下：
　

定义CCriticalSection类的一个全局对象（以使各个线程均能访问），如CCriticalSection critical_section；

在访问需要保护的资源或代码之前，调用CCriticalSection类的成员Lock（）获得临界区对象：

critical_section.Lock();

在线程中调用该函数来使线程获得它所请求的临界区。如果此时没有其它线程占有临界区对象，则调用Lock()的线程获得临界区；否则，线程将被挂起，并放入到一个系统队列中等待，直到当前拥有临界区的线程释放了临界区时为止。

访问临界区完毕后，使用CCriticalSection的成员函数Unlock()来释放临界区：

critical_section.Unlock();

再通俗一点讲，就是线程A执行到critical_section.Lock();语句时，如果其它线程(B)正在执行critical_section.Lock();语句后且critical_section. Unlock();语句前的语句时，线程A就会等待，直到线程B执行完critical_section. Unlock();语句，线程A才会继续执行。

B、使用 CEvent 类

　　CEvent 类提供了对事件的支持。事件是一个允许一个线程在某种情况发生时，唤醒另外一个线程的同步对象。例如在某些网络应用程序中，一个线程（记为A）负责监听通讯端口，另外一个线程（记为B）负责更新用户数据。通过使用CEvent 类，线程A可以通知线程B何时更新用户数据。每一个CEvent 对象可以有两种状态：有信号状态和无信号状态。线程监视位于其中的CEvent 类对象的状态，并在相应的时候采取相应的操作。
　　在MFC中，CEvent 类对象有两种类型：人工事件和自动事件。一个自动CEvent 对象在被至少一个线程释放后会自动返回到无信号状态；而人工事件对象获得信号后，释放可利用线程，但直到调用成员函数ReSetEvent()才将其设置为无信号状态。在创建CEvent 类的对象时，默认创建的是自动事件。 CEvent 类的各成员函数的原型和参数说明如下：

1、CEvent(BOOL bInitiallyOwn=FALSE,

BOOL bManualReset=FALSE,

LPCTSTR lpszName=NULL,

LPSECURITY_ATTRIBUTES lpsaAttribute=NULL);

bInitiallyOwn:指定事件对象初始化状态，TRUE为有信号，FALSE为无信号；

bManualReset：指定要创建的事件是属于人工事件还是自动事件。TRUE为人工事件，FALSE为自动事件；

后两个参数一般设为NULL，在此不作过多说明。

2、BOOL CEvent：：SetEvent();

　　将 CEvent 类对象的状态设置为有信号状态。如果事件是人工事件，则 CEvent 类对象保持为有信号状态，直到调用成员函数ResetEvent()将 其重新设为无信号状态时为止。如果CEvent 类对象为自动事件，则在SetEvent()将事件设置为有信号状态后，CEvent 类对象由系统自动重置为无信号状态。

如果该函数执行成功，则返回非零值，否则返回零。

3、BOOL CEvent：：ResetEvent();

该函数将事件的状态设置为无信号状态，并保持该状态直至SetEvent()被调用时为止。由于自动事件是由系统自动重置，故自动事件不需要调用该函数。如果该函数执行成功，返回非零值，否则返回零。我们一般通过调用WaitForSingleObject函数来监视事件状态。

C、使用CMutex 类

　　互斥对象与临界区对象很像.互斥对象与临界区对象的不同在于:互斥对象可以在进程间使用,而临界区对象只能在同一进程的各线程间使用。当然，互斥对象也可以用于同一进程的各个线程间，但是在这种情况下，使用临界区会更节省系统资源，更有效率。

D、使用CSemaphore 类

　　当需要一个计数器来限制可以使用某个线程的数目时，可以使用“信号量”对象。CSemaphore 类的对象保存了对当前访问某一指定资源的线程的计数值，该计数值是当前还可以使用该资源的线程的数目。如果这个计数达到了零，则所有对这个CSemaphore 类对象所控制的资源的访问尝试都被放入到一个队列中等待，直到超时或计数值不为零时为止。一个线程被释放已访问了被保护的资源时，计数值减1；一个线程完成了对被控共享资源的访问时，计数值增1。这个被CSemaphore 类对象所控制的资源可以同时接受访问的最大线程数在该对象的构建函数中指定。

CSemaphore 类的构造函数原型及参数说明如下：

CSemaphore (LONG lInitialCount=1,

LONG lMaxCount=1,

LPCTSTR pstrName=NULL,

LPSECURITY_ATTRIBUTES lpsaAttributes=NULL);

lInitialCount:信号量对象的初始计数值，即可访问线程数目的初始值；

lMaxCount：信号量对象计数值的最大值，该参数决定了同一时刻可访问由信号量保护的资源的线程最大数目；

后两个参数在同一进程中使用一般为NULL，不作过多讨论；

　　在用CSemaphore 类的构造函数创建信号量对象时要同时指出允许的最大资源计数和当前可用资源计数。一般是将当前可用资源计数设置为最大资源计数，每增加一个线程对共享资源的访问，当前可用资源计数就会减1，只要当前可用资源计数是大于0的，就可以发出信号量信号。但是当前可用计数减小到0时，则说明当前占用资源的线程数已经达到了所允许的最大数目，不能再允许其它线程的进入，此时的信号量信号将无法发出。线程在处理完共享资源后，应在离开的同时通过ReleaseSemaphore()函数将当前可用资源数加1。

互斥对象、临界区、事件、信号量之间的区别：

互斥对象与临界区对象很像.互斥对象与临界区对象的不同在于:互斥对象可以在进程间使用,而临界区对象只能在同一进程的各线程间使用。命名的互斥对象可以在进程间使用.

事件是一个允许一个线程在某种情况发生时，唤醒另外一个线程的同步对象。

“信号量”对象通过一个计数器来限制可以使用某个线程的数目。计数达到了零时，线程进入等待队列中等待。计数大于零时，线程可以访问资源，同时计数减一。

编程中注意细节

1、volatile 修饰符的作用是告诉编译器无需对该变量作任何的优化，即无需将它放到一个寄存器中，并且该值可被外部改变。对于多线程引用的全局变量来说，volatile 是一个非常重要的修饰符。
2、WaitForSingleObject

DWORD WaitForSingleObject(HANDLE hHandle,DWORD dwMilliseconds);

hHandle为要监视的对象（一般为同步对象，也可以是线程）的句柄；

dwMilliseconds为hHandle对象所设置的超时值，单位为毫秒；

当在某一线程中调用该函数时，线程暂时挂起，系统监视hHandle所指向的对象的状态。如果在挂起的dwMilliseconds毫秒内，线程所等待的对象变为有信号状态，则该函数立即返回；如果超时时间已经到达dwMilliseconds毫秒，但hHandle所指向的对象还没有变成有信号状态，函数照样返回。参数dwMilliseconds有两个具有特殊意义的值：0和INFINITE。若为0，则该函数立即返回；若为INFINITE，则线程一直被挂起，直到hHandle所指向的对象变为有信号状态时为止。

3、使用CreateThread出现类似cannot convert parameter 3 from 'unsigned int (void *)' to 'unsigned long (__stdcall *)(void *)'中文，需要将参数3强制转换成LPTHREAD_START_ROUTINE。

4、CreateThread

线程函数参数类型为：LPTHREAD_START_ROUTINE

定义：ypedef DWORD (WINAPI *PTHREAD_START_ROUTINE)(

LPVOID lpThreadParameter

);

AfxBeginThread

线程函数参数类型为：AFX_THREADPROC

定义：typedef UINT (AFX_CDECL *AFX_THREADPROC)(LPVOID);

5、ON_THREAD_MESSAGE 表示线程消息映射。

6、尽量少的使用全局变量、static变量做共享数据，尽量使用参数传递对象。被参数传递的对象，应该只包括必需的成员变量。所谓必需的成员变量，就是必定会被多线程操作的。

7、在MFC中请慎用线程。因为MFC的框架假定你的消息处理都是在主线程中完成的。首先窗口句柄是属于线程的，如果拥有窗口句柄的线程退出了，如果另一个线程处理这个窗口句柄，系统就会出现问题。而MFC为了避免这种情况的发生，使你在子线程中调用消息（窗口）处理函数时，就会不停的出Assert错误，烦都烦死你。典型的例子就时CSocket，因为CSocket是使用了一个隐藏窗口实现了假阻塞，所以不可避免的使用了消息处理函数，如果你在子线程中使用CSocket，你就可能看到assert的弹出了。

8、不要在不同的线程中同时注册COM组件。两个线程，一个注册1.ocx, 2.ocx, 3.ocx, 4.ocx; 而另一个则注册5.ocx, 6.ocx, 7.ocx, 8.ocx，结果死锁发生了，分别死在FreeLibrary和DllRegisterServer，因为这8个ocx是用MFC中做的，也可能是MFC的Bug，但DllRegisterServer却死在GetModuleFileName里。

9、不要把线程搞的那么复杂。很多初学者，恨不能用上线程相关的所有的函数，这里互斥，那里等待，一会儿起线程，一会儿关线程的。好的多线程程序，应该是尽量少的使用线程。这句话怎么理解呐，就是说尽量统一一块数据共享区存放数据队列，工作子线程从队列中取数据，处理，再放回数据，这样才会模块化，对象化；而不是每个数据都起一个工作子线程处理，处理完了就关闭，写的时候虽然直接，等维护起来就累了。

常用线程问题

1、在线程里用控件是不明智的选择。

2、多线程的自动启动方法.

A、窗口建立后，执行AfxBeginThread.但终止线程时，比较麻烦。有时你还必须用CloseHandle和TerminateThread来强行终止线程。这样容易造成内存泄露。

B、设置一个CEvent类对象，你可以控制他的信号量（分两种：被触发，未被触发），在建立线程时，设置线程挂起并等待信号。这样，在线程建立后（你可以提早建立线程，但它时被挂起的），你就可以想什么时候启动线程就启动线程。而且关闭也很方便（事件触发）。这是微软推荐做法。
3、不要跨线程访问复杂的MFC对象。大多数复杂的MFC对象的内部实现引用了线程局部存储（TLS）。在线程中发送一个自定义消息到窗口句柄就可以访问了。

4、mfc的大多数类不是线程安全的，cwnd及其消息路由是其中之最。mfc界面类的大多数方法，最后都是通过sendmessage实现的，而消息处理的过程中会引发其他消息的发送及处理。如果消息处理函数本身不是线程安全的。你从工作线程中调用这些方法迟早会同你界面线程的用户消息响应发生冲突。

5、Cxxxx::fromhandle会根据调用者所在线程查表，如果查不到用户创建的Cxxxx对应对象，它会创建一个临时对象出来并返回给你，你根本不可能期望它的成员变量会是有意义的。所以要用也只能用cwnd::fromhandle，因为它只包含一个m_hwnd成员。不过，要记住跨线程直接或间接地调用::sendmessage,通常都是行为不可预测的。

6、一个线程不可以也不应该访问另一个线程中的包装类对象（因为包装类对象就相当于窗口，这是MFC的目标，并不是包装类本身不能被跨线程访问），“不可以”就是通过在包装类成员函数中的断言宏实现的（在CWnd::AssertValid中），而“不应该”下面会解释。
虽然包装类对象不能跨线程访问，但是窗口句柄却可以跨线程访问。因为包装类对象不仅等同于窗口，还改变了窗口的交互方式（这也正是C++类的概念的应用），使得不用非得使用消息机制才能和窗口交互。注意前面提到的，如果跨线程访问包装类对象，而又使用C++类的概念操作它，则其必须进行线程保护，而“不能跨线程访问”就消除了这个问题。因此临时对象的产生就只是如前面所说，方便代码的编写而已，不提供子类化的效果，因为窗口句柄可以跨线程访问。

窗口类

窗口类是一个结构，其一个实例代表着一个窗口类型，与C++中的类的概念非常相近（虽然其表现形式完全不同，C++的类只不过是内存布局和其上的操作这个概念的类型），故被称作为窗口类。
窗口是具有设备操作能力的逻辑概念，即一种能操作设备（通常是显示器）的东西。由于窗口是窗口类的实例，就象C++中的一个类的实例，是可以具有成员函数的（虽然表现形式不同），但一定要明确窗口的目的——操作设备（这点也可以从Microsoft针对窗口所制订的API的功能看出，主要出于对设备操作的方便）。因此不应因为其具有成员函数的功能而将窗口用于功能对象的创建，这虽然不错，但是严重违反了语义的需要，是不提倡的，但却由于MFC界面包装类的加入导致大多数程序员经常将逻辑混入界面。
窗口类是个结构，其中的大部分成员都没什么重要意义，只是Microsoft一相情愿制订的，如果不想使用界面API（Windows User Interface API），可以不管那些成员。其中只有一个成员是重要的——lpfnWndProc，消息处理函数。
外界（使用窗口的代码）只能通过消息操作窗口，这就如同C++中编写的具有良好的面向对象风格的类的实例只能通过其公共成员函数对其进行操作。因此消息处理函数就代表了一个窗口的一切（忽略窗口类中其他成员的作用）。很容易发现，窗口这个实例只具有成员函数（消息处理函数），不具有成员变量，即没有一块特定内存和一特定的窗口相关联，则窗口将不能具有状态（Windows还是提供了Window Properties API来缓和这种状况）。这也正是上面问题发生的根源。
为了处理窗口不能具有状态的问题（这其实正是Windows灵活的表现），可以有很多种方法，而MFC出于能够很容易的对已有窗口类进行扩展，选择了使用一个映射将一个窗口句柄（窗口的唯一标示符）和一个内存块进行绑定，而这块内存块就是我们熟知的MFC界面包装类（从CWnd开始派生延续）的实例。

MFC状态

状态就是实例通过某种手段使得信息可以跨时间段重现，C++的类的实例就是由外界通过公共成员函数改变实例的成员变量的值以实现具有状态的效果。在MFC 中，具有三种状态：模块状态、进程状态、线程状态。分别为模块、进程和线程这三种实例的状态。由于代码是由线程运行，且和另外两个的关系也很密切，因此也被称作本地数据。
模块本地数据
具有模块本地性的变量。模块指一个加载到进程虚拟内存空间中的PE文件，即exe文件本身和其加载的dll文件。而模块本地性即同样的指针，根据代码从不同的模块执行而访问不同的内存空间。这其实只用每个模块都声明一个全局变量，通过一个切换的过程即可实现模块本地性。MFC中，这个过程是通过调用AfxSetModuleState来切换的，而通常都使用 AFX_MANAGE_STATE这个宏来处理，因此下面常见的语句就是用于模块状态的切换的：
AFX_MANAGE_STATE( AfxGetStaticModuleState() );
MFC中定义了一个结构（AFX_MODULE_STATE），其实例具有模块本地性，记录了此模块的全局应用程序对象指针、资源句柄等模块级的全局变量。其中有一个成员变量是线程本地数据，类型为AFX_MODULE_THREAD_STATE，其就是本文问题的关键。
进程本地数据
具有进程本地性的变量。与模块本地性相同，即同一个指针，在不同进程中指向不同的内存空间。这一点Windows本身的虚拟内存空间这个机制已经实现了，不过在dll中定义的全局变量，如果dll支持Win32s，则其是共享其全局变量的，即不同的进程加载了同一dll将访问同一内存。Win32s是为了那些基于Win32的应用程序能在Windows 3.1上运行，由于Windows 3.1是16位操作系统，早已被淘汰，而现行的dll模型其本身就已经实现了进程本地性（不过还是可以通过共享节来实现Win32s中的dll的效果），因此进程状态其实就是一全局变量。
MFC中作为本地数据的结构有很多，如_AFX_WIN_STATE、_AFX_DEBUG_STATE、_AFX_DB_STATE等，都是MFC内部自己使用的具有进程本地性的全局变量。
线程本地数据
具有线程本地性的变量。如上，即同一个指针，不同的线程将会访问不同的内存空间。这点MFC是通过线程本地存储（TLS——Thread Local Storage，其使用方法由于与本文无关，在此不表）实现的。
MFC中定义了一个结构（_AFX_THREAD_STATE）以记录某些线程级的全局变量，如最近一次的模块状态指针，最近一次的消息等。
模块线程状态
MFC中定义的一个结构（AFX_MODULE_THREAD_STATE），其实例即具有线程本地性又具有模块本地性。也就是说不同的线程从同一模块中和同一线程从不同模块中访问MFC库函数都将导致操作不同的内存空间。其应用在AFX_MODULE_STATE中，记录一些线程相关但又模块级的数据，如本文的重点——窗口句柄映射。

包装类对象和句柄映射

句柄映射——CHandleMap，MFC提供的一个底层辅助类，程序员是不应该直接使用它的。其有两个重要的成员变量：CMapPtrToPtr m_permanentMap, m_temporaryMap;。分别记录永久句柄绑定和临时句柄绑定。前面说过，MFC使用一个映射将窗口句柄和其包装类的实例绑定在一起，m_permanentMap和m_temporaryMap就是这个映射，映射分为永久包装类对象和临时包装类对象，而在前面提到过的 AFX_MODULE_THREAD_STATE中就有一个成员变量：CHandleMap* m_pmapHWND;（之所以是CHandleMap*是使用懒惰编程法，尽量节约资源）以专门完成HWND的绑定映射，除此以外还有如 m_pmapHDC、m_pmapHMENU等成员变量以分别实现HDC、HMENU的绑顶映射。而为什么这些映射要放在模块线程状态而不放在线程状态或模块状态是很明显的——这些包装类包装的句柄都是和线程相关的（如HWND只有创建它的线程才能接收其消息）且这个模块中的包装类对象可能不同于另一个模块的（如包装类是某个DLL中专门派生的一个类，如a.dll中定义的CAButton的实例和b.dll中定义的CBButton的实例如果同时在一个线程中。此时线程卸载了a.dll，然后CAButton的实例得到消息并进行处理，将发生严重错误——类代码已经被卸载掉了）。

包装类存在的意义有二：包装对HWND的操作以加速代码的编写和提供窗口子类化（不是超类化）的效果以派生窗口类。包装类对象针对线程分为两种：永久包装类对象（以后简称永久对象）和临时包装类对象（以后简称临时对象）。临时对象的意义仅仅只有包装对HWND的操作以加速代码编写，不具有派生窗口类的功能。永久对象则具有前面说的包装类的两个意义。
在创建窗口时（即CWnd::CreateEx中），MFC通过钩子提前（WM_CREATE和WM_NCCREATE之前）处理了通知，用AfxWndProc子类化了创建的窗口并将对应的CWnd*加入当前线程的永久对象的映射中，而在AfxWndProc中，总是由CWnd::FromHandlePermanent（获得对应HWND的永久对象）得到当前线程中当前消息所属窗口句柄对应的永久对象，然后通过调用得到的CWnd*的WindowProc成员函数来处理消息以实现派生窗口类的效果。这也就是说永久对象具有窗口子类化的意义，而不仅仅是封装HWND的操作。
要将一个HWND和一个已有的包装类对象相关联，调用CWnd::Attach将此包装类对象和HWND映射成永久对象（但这种方法得到的永久对象不一定具有子类化功能，很可能仍和临时对象一样，仅仅起封装的目的）。如果想得到临时对象，则通过CWnd::FromHandle这个静态成员函数以获得。临时对象之所以叫临时，就是其是由MFC内部（CHandleMap::FromHandle）生成，其内部（CHandleMap::DeleteTemp）销毁（一般通过CWinThread::OnIdle中调用AfxUnlockTempMaps）。因此程序员是永远不应该试图销毁临时对象的（即使临时对象所属线程没有消息循环，不能调用CwinThread::OnIdle，在线程结束时，CHandleMap的析构仍然会销毁临时对象）。

7、MFC对象不要跨线程使用，因为MFC不是线程安全的。比如CWnd对象不要跨线程使用,可以用窗口句柄（HWND）代替。CSocket/CAsyncSocket对象不要跨线程使用,用SOCKET句柄代替.那么到底什么是线程安全呢?什么时候需要考虑?如果程序涉及到多线程的话，就应该考虑线程安全问题。比如说设计的接口，将来需要在多线程环境中使用，或者需要跨线程使用某个对象时，这个就必须考虑了。所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性,也就是说我们不用考虑同步的问题。

一般而言“线程安全”由多线程对共享资源的访问引起。如果调用某个接口时需要我们自己采取同步措施来保护该接口访问的共享资源,则这样的接口不是线程安全的.MFC和STL都不是线程安全的. 怎样才能设计出线程安全的类或者接口呢?如果接口中访问的数据都属于私有数据,那么这样的接口是线程安全的.或者几个接口对共享数据都是只读操作,那么这样的接口也是线程安全的.如果多个接口之间有共享数据,而且有读有写的话,如果设计者自己采取了同步措施，调用者不需要考虑数据同步问题，则这样的接口是线程安全的，否则不是线程安全的。

实例：

DWORD WINAPI ThreadProc( void *pData ) // 线程函数（比如用于从COM口获取数据）
{
// 数据获取循环
// 数据获得后放在变量i中
CAbcDialog *pDialog = reinterpret_cast( pData );
ASSERT( pDialog ); // 此处如果ASSERT_VALID( pDialog )将断言失败
pDialog->m_Data = i;
pDialog->UpdateData( FALSE ); // UpdateData内部ASSERT_VALID( this )断言失败
…
}
BOOL CAbcDialog::OnInitDialog()
{
CDialog::OnInitDialog();
// 其他初始化代码
CreateThread( NULL, 0, ThreadProc, this, 0, NULL ); // 创建线程
return TRUE;
}

//解决方法

#define AM_DATANOTIFY ( WM_USER + 1 )
static DWORD g_Data = 0;
DWORD WINAPI ThreadProc( void *pData ) // 线程函数（比如用于从COM口获取数据）

{
// 数据获取循环
// 数据获得后放在变量i中
g_Data = i;
CWnd *pWnd = CWnd::FromHandle( reinterpret_cast( pData ) );
ASSERT_VALID( pWnd ); // 本例应该直接调用平台SendMessage而不调用包装类的，这里只是演示
pWnd->SendMessage( AM_DATANOTIFY, 0, 0 );
…
}
BEGIN_MESSAGE_MAP( CAbcDialog, CDialog )
…
ON_MESSAGE( AM_DATANOTIFY, OnDataNotify )
…
END_MESSAGE_MAP()
BOOL CAbcDialog::OnInitDialog()
{
CDialog::OnInitDialog();
// 其他初始化代码
CreateThread( NULL, 0, ThreadProc, m_hWnd, 0, NULL ); // 创建线程
return TRUE;
}
LRESULT CAbcDialog::OnDataNotify( WPARAM /* wParam */, LPARAM /* lParam */ )
{
UpdateData( FALSE );
return 0;
}
void CAbcDialog::DoDataExchange( CDataExchange *pDX )
{
CDialog::DoDataExchange( pDX );
DDX_Text( pDX, IDC_EDIT1, g_Data );
}

8、一个主线程Create一个子线程，那么为了保证安全退出，应该在退出时怎么样处理？

问题的难点在于怎么样知道子线程是否退出了。

解答：

检索线程的退出代码

若要获取辅助线程或用户界面线程的退出代码，请调用 GetExitCodeThread 函数。有关此函数的信息，请参见 Platform SDK。此函数获取线程（存储在 CWinThread 对象的 m_hThread 数据成员中）的句柄和 DWORD 的地址。

如果线程仍然是活动的，GetExitCodeThread 会将 STILL_ACTIVE 放在提供的 DWORD 地址中；否则将退出代码放在此地址中。

检索 CWinThread 对象的退出代码还需要一步。默认情况下，当 CWinThread 线程终止时，删除该线程对象。这意味着不能访问 m_hThread 数据成员，因为 CWinThread 对象不再存在。若要避免此情况，请执行以下两个操作之一：

将 m_bAutoDelete 数据成员设置为 FALSE。这使 CWinThread 对象在线程终止后仍可以继续存在。然后可以在线程终止后，访问 m_hThread 数据成员。但是如果使用此技术，您有责任销毁 CWinThread 对象，因为框架不会自动为您删除该对象。这是首选方法。

－ 或 －

单独存储线程的句柄。创建线程后，（使用 ::DuplicateHandle）将其 m_hThread 数据成员复制到其他变量，并通过该变量访问该成员。这样，终止后即可以自动删除对象，并且仍然可以查出线程终止的原因。请注意：在可以复制句柄之前，线程不终止。执行此操作的最安全的方式是将 CREATE_SUSPENDED 传递到 AfxBeginThread，存储句柄，然后通过调用 ResumeThread 继续执行线程。

任一方法都可以使您确定 CWinThread 对象终止的原因。

下面给出一段代码：

// 启动工作者线程,线程对象不自动退出,需要手动delete

void VideoInstance::StartThreads()

{

m_pThread_MduHeart = AfxBeginThread(Thread_MDUHeart, (void*)this, THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED, NULL);

ASSERT( m_pThread_MduHeart != NULL );

m_pThread_MduHeart->m_bAutoDelete = FALSE; // 这点很重要.保证线程退出码在外能被检查到。

m_pThread_MduHeart->ResumeThread();

Sleep(100);

m_pThread_RecvData = AfxBeginThread(Thread_MduRealVideo, (void*)this, THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED, NULL);

ASSERT( m_pThread_RecvData != NULL );

m_pThread_RecvData->m_bAutoDelete = FALSE; // 这点很重要.保证线程退出码在外能被检查到。

m_pThread_RecvData->ResumeThread();

}

// 退出实例的线程对象并删除线程对象,主要是为了正常退出线程

void VideoInstance::QuitInstance()

{

// 设置线程退出信号,需要手动重置

::SetEvent(this->m_hEventQuit);

DWORD dwExitCode1 = STILL_ACTIVE;

DWORD dwExitCode2 = STILL_ACTIVE;

while(1)

{

// 检索线程的退出代码前要求线程对象还没有退出

::GetExitCodeThread(m_pThread_MduHeart->m_hThread, &dwExitCode1);

::GetExitCodeThread(m_pThread_RecvData->m_hThread, &dwExitCode2);

if( dwExitCode1 != STILL_ACTIVE && dwExitCode2 != STILL_ACTIVE)

break;

}

// 手动删除线程对象

delete m_pThread_MduHeart;

delete m_pThread_RecvData;

m_pThread_MduHeart = NULL;

m_pThread_RecvData = NULL;

}

Windows是一种多任务的操作系统，在Windows的一个进程内包含一个或多个线程。32位Windows环境下的Win32 API提供了多线程应用程序开发所需要的接口函数，而利用ＶＣ中提供的标准Ｃ库也可以开发多线程应用程序，相应的ＭＦＣ类库封装了多线程编程的类，用户在开发时可根据应用程序的需要和特点选择相应的工具。为了使大家能全面地了解Windows多线程编程技术，本文将重点介绍Win32 API和MFC两种方式下如何编制多线程程序。

多线程编程在Win32方式下和MFC类库支持下的原理是一致的，进程的主线程在任何需要的时候都可以创建新的线程。当线程执行完后，自动终止线程; 当进程结束后，所有的线程都终止。所有活动的线程共享进程的资源，因此，在编程时需要考虑在多个线程访问同一资源时产生冲突的问题。当一个线程正在访问某进程对象，而另一个线程要改变该对象，就可能会产生错误的结果，编程时要解决这个冲突。

Win32 API下的多线程编程

Win32 API是Windows操作系统内核与应用程序之间的界面，它将内核提供的功能进行函数包装，应用程序通过调用相关函数而获得相应的系统功能。为了向应用程序提供多线程功能，Win32 API函数集中提供了一些处理多线程程序的函数集。直接用Win32 API进行程序设计具有很多优点: 基于Win32的应用程序执行代码小，运行效率高，但是它要求程序员编写的代码较多，且需要管理所有系统提供给程序的资源。用Win32 API直接编写程序要求程序员对Windows系统内核有一定的了解，会占用程序员很多时间对系统资源进行管理，因而程序员的工作效率降低。

1. 用Win32函数创建和终止线程

Win32函数库中提供了操作多线程的函数，包括创建线程、终止线程、建立互斥区等。在应用程序的主线程或者其他活动线程中创建新的线程的函数如下：

HANDLE CreateThread(LPSECURITY_ATTRIBUTES lpThreadAttributes,DWORD dwStackSize,LPTHREAD_START_ROUTINE lpStartAddress,LPVOID lpParameter,DWORD dwCreationFlags,LPDWORD lpThreadId);

如果创建成功则返回线程的句柄，否则返回NULL。创建了新的线程后，该线程就开始启动执行了。但如果在dwCreationFlags中使用了CREATE_SUSPENDED特性，那么线程并不马上执行，而是先挂起，等到调用ResumeThread后才开始启动线程，在这个过程中可以调用下面这个函数来设置线程的优先权：

BOOL SetThreadPriority(HANDLE hThread,int nPriority);

当调用线程的函数返回后，线程自动终止。如果需要在线程的执行过程中终止则可调用函数：

VOID ExitThread(DWORD dwExitCode);

如果在线程的外面终止线程，则可调用下面的函数：

BOOL TerminateThread(HANDLE hThread,DWORD dwExitCode);

但应注意: 该函数可能会引起系统不稳定，而且线程所占用的资源也不释放。因此，一般情况下，建议不要使用该函数。

如果要终止的线程是进程内的最后一个线程，则线程被终止后相应的进程也应终止。

2. 线程的同步

在线程体内，如果该线程完全独立，与其他线程没有数据存取等资源操作上的冲突，则可按照通常单线程的方法进行编程。但是，在多线程处理时情况常常不是这样，线程之间经常要同时访问一些资源。由于对共享资源进行访问引起冲突是不可避免的，为了解决这种线程同步问题，Win32 API提供了多种同步控制对象来帮助程序员解决共享资源访问冲突。在介绍这些同步对象之前先介绍一下等待函数，因为所有控制对象的访问控制都要用到这个函数。

Win32 API提供了一组能使线程阻塞其自身执行的等待函数。这些函数在其参数中的一个或多个同步对象产生了信号，或者超过规定的等待时间才会返回。在等待函数未返回时，线程处于等待状态，此时线程只消耗很少的CPU时间。使用等待函数既可以保证线程的同步，又可以提高程序的运行效率。最常用的等待函数是：

DWORD WaitForSingleObject(HANDLE hHandle，DWORD dwMilliseconds);

而函数WaitForMultipleObject可以用来同时监测多个同步对象，该函数的声明为：

DWORD WaitForMultipleObject(DWORD nCount,CONST HANDLE *lpHandles,BOOL bWaitAll,DWORD dwMilliseconds);

（1）互斥体对象

Mutex对象的状态在它不被任何线程拥有时才有信号，而当它被拥有时则无信号。Mutex对象很适合用来协调多个线程对共享资源的互斥访问。可按下列步骤使用该对象：

首先，建立互斥体对象，得到句柄：

HANDLE CreateMutex();

然后，在线程可能产生冲突的区域前（即访问共享资源之前）调用WaitForSingleObject，将句柄传给函数，请求占用互斥对象：

dwWaitResult = WaitForSingleObject(hMutex,5000L);

共享资源访问结束，释放对互斥体对象的占用：

ReleaseMutex(hMutex);

互斥体对象在同一时刻只能被一个线程占用，当互斥体对象被一个线程占用时，若有另一线程想占用它，则必须等到前一线程释放后才能成功。

（2）信号对象

信号对象允许同时对多个线程共享资源进行访问，在创建对象时指定最大可同时访问的线程数。当一个线程申请访问成功后，信号对象中的计数器减一，调用ReleaseSemaphore函数后，信号对象中的计数器加一。其中，计数器值大于或等于０，但小于或等于创建时指定的最大值。如果一个应用在创建一个信号对象时，将其计数器的初始值设为０，就阻塞了其他线程，保护了资源。等初始化完成后，调用ReleaseSemaphore函数将其计数器增加至最大值，则可进行正常的存取访问。可按下列步骤使用该对象：

首先，创建信号对象：

HANDLE CreateSemaphore();

或者打开一个信号对象：

HANDLE OpenSemaphore();

然后，在线程访问共享资源之前调用WaitForSingleObject。

共享资源访问完成后，应释放对信号对象的占用：

ReleaseSemaphore();

（3）事件对象

事件对象(Event)是最简单的同步对象，它包括有信号和无信号两种状态。在线程访问某一资源之前，需要等待某一事件的发生，这时用事件对象最合适。例如：只有在通信端口缓冲区收到数据后，监视线程才被激活。

事件对象是用CreateEvent函数建立的。该函数可以指定事件对象的类和事件的初始状态。如果是手工重置事件，那么它总是保持有信号状态，直到用ResetEvent函数重置成无信号的事件。如果是自动重置事件，那么它的状态在单个等待线程释放后会自动变为无信号的。用SetEvent可以把事件对象设置成有信号状态。在建立事件时，可以为对象命名，这样其他进程中的线程可以用OpenEvent函数打开指定名字的事件对象句柄。

（4）排斥区对象

在排斥区中异步执行时，它只能在同一进程的线程之间共享资源处理。虽然此时上面介绍的几种方法均可使用，但是，使用排斥区的方法则使同步管理的效率更高。

使用时先定义一个CRITICAL_SECTION结构的排斥区对象，在进程使用之前调用如下函数对对象进行初始化:

VOID InitializeCriticalSection(LPCRITICAL_SECTION);

当一个线程使用排斥区时，调用函数：EnterCriticalSection或者TryEnterCriticalSection;

当要求占用、退出排斥区时，调用函数LeaveCriticalSection，释放对排斥区对象的占用，供其他线程使用。

基于MFC的多线程编程

MFC是微软的VC开发集成环境中提供给程序员的基础函数库，它用类库的方式将Win32 API进行封装，以类的方式提供给开发者。由于其快速、简捷、功能强大等特点深受广大开发者喜爱。因此，建议使用MFC类库进行应用程序的开发。

在VC++附带的MFC类库中，提供了对多线程编程的支持，基本原理与基于Win32 API的设计一致，但由于MFC对同步对象做了封装，因此实现起来更加方便，避免了对象句柄管理上的烦琐工作。

在MFC中，线程分为两种：工作线程和用户接口线程。工作线程与前面所述的线程一致，用户接口线程是一种能够接收用户的输入、处理事件和消息的线程。

1. 工作线程

工作线程编程较为简单，设计思路与前面所讲的基本一致: 一个基本函数代表了一个线程，创建并启动线程后，线程进入运行状态; 如果线程用到共享资源，则需要进行资源同步处理。这种方式创建线程并启动线程时可调用函数：

CWinThread*AfxBeginThread( AFX_THREADPROC pfnThreadProc, LPVOID pParam,int nPriority= THREAD_PRIORITY_NORMAL,UINT nStackSize =0,DWORD dwCreateFlags=0, LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL);参数pfnThreadProc是线程执行体函数，函数原形为: UINT ThreadFunction( LPVOID pParam)。

参数pParam是传递给执行函数的参数；

参数nPriority是线程执行权限，可选值：

THREAD_PRIORITY_NORMAL、THREAD_PRIORITY_LOWEST、THREAD_PRIORITY_HIGHEST、THREAD_PRIORITY_IDLE。

参数dwCreateFlags是线程创建时的标志，可取值CREATE_SUSPENDED，表示线程创建后处于挂起状态，调用ResumeThread函数后线程继续运行，或者取值“0”表示线程创建后处于运行状态。

返回值是CWinThread类对象指针，它的成员变量m_hThread为线程句柄，在Win32 API方式下对线程操作的函数参数都要求提供线程的句柄，所以当线程创建后可以使用所有Win32 API函数对pWinThread->m_Thread线程进行相关操作。

注意：如果在一个类对象中创建和启动线程时，应将线程函数定义成类外的全局函数。

2. 用户接口线程

基于MFC的应用程序有一个应用对象，它是CWinApp派生类的对象，该对象代表了应用进程的主线程。当线程执行完并退出线程时，由于进程中没有其他线程存在，进程自动结束。类CＷinApp从CＷinThread派生出来，CＷinThread是用户接口线程的基本类。我们在编写用户接口线程时，需要从CＷinThread派生我们自己的线程类，ClassWizard可以帮助我们完成这个工作。

先用ClassWizard派生一个新的类，设置基类为CwinThread。注意：类的DECLARE_DYNCREATE和IMPLEMENT_DYNCREATE宏是必需的，因为创建线程时需要动态创建类的对象。根据需要可将初始化和结束代码分别放在类的InitInstance和ExitInstance函数中。如果需要创建窗口，则可在InitInstance函数中完成。然后创建线程并启动线程。可以用两种方法来创建用户接口线程，MFC提供了两个版本的AfxBeginThread函数，其中一个用于创建用户接口线程。第二种方法分为两步进行：首先，调用线程类的构造函数创建一个线程对象；其次，调用CWinThread::CreateThread函数来创建该线程。线程建立并启动后，在线程函数执行过程中一直有效。如果是线程对象，则在对象删除之前，先结束线程。CWinThread已经为我们完成了线程结束的工作。

3. 线程同步

前面我们介绍了Win32 API提供的几种有关线程同步的对象，在MFC类库中对这几个对象进行了类封装，它们有一个共同的基类CSyncObject，它们的对应关系为: Semaphore对应CSemaphore、Mutex对应CMutex、Event对应CEvent、CriticalSection对应CCriticalSection。另外，MFC对两个等待函数也进行了封装，即CSingleLock和CMultiLock。因四个对象用法相似，在这里就以CMutex为例进行说明：

创建一个CMutex对象:

CMutex mutex(FALSE,NULL,NULL);

或CMutex mutex;

当各线程要访问共享资源时使用下面代码：

CSingleLock sl(&mutex);

sl.Lock();

if(sl.IsLocked())

//对共享资源进行操作...

sl.Unlock();

结束语

如果用户的应用程序需要多个任务同时进行相应的处理，则使用多线程是较理想的选择。这里，提醒大家注意的是在多线程编程时要特别小心处理资源共享问题以及多线程调试问题

样例程序

程序功能：求从1一直到 APPLE_MAX_VALUE (100000000) 相加累计的和，并赋值给 apple 的 a 和 b ；求 orange 数据结构中的 a[i]+b[i ] 的和，循环 ORANGE_MAX_VALUE (1000000) 次。

说明：

由于样例程序是从实际应用中抽象出来的模型，所以本文不会进行 test.a=test.b= test.b+sum 、中间变量(查找表)等类似的优化。
以下所有程序片断均为部分代码，完整代码请参看本文最下面的附件。

清单 1. 样例程序
#define ORANGE_MAX_VALUE 1000000
#define APPLE_MAX_VALUE 100000000
#define MSECOND 1000000

struct apple
{
unsigned long long a;
unsigned long long b;
};

struct orange
{
int a[ORANGE_MAX_VALUE];
int b[ORANGE_MAX_VALUE];

};

int main (int argc, const char * argv[]) {
// insert code here...
struct apple test;
struct orange test1;

for(sum=0;sum<APPLE_MAX_VALUE;sum++)
{
test.a += sum;
test.b += sum;
}

sum=0;
for(index=0;index= Vk

M: 在结束测试之前，测量值的最大数量。

按照升序的方式维护一个 K 个最快时间的数组，对于每一个新的测量值，如果比当前 K 处的值更快，则用最新的值替换数组中的元素 K ，然后再进行升序排序，持续不断的进行该过程，并满足误差标准，此时就称测量值已经收敛。如果 M 次后，不能满足误差标准，则称为不能收敛。

在接下来的所有试验中，采用 K=10，ε=2%，M=200 来获取程序运行时间，同时也对 K 次最优测量方法进行了改进，不是采用最小值来表示程序执行的时间，而是采用 K 次测量值的平均值来表示程序的真正运行时间。由于采用的误差 ε 比较大，在所有试验程序的时间收集过程中，均能收敛，但也能说明问题。

为了可移植性，采用 gettimeofday() 来获取系统时钟（system clock）时间，可以精确到微秒。

测试环境

硬件：联想 Dual-core 双核机器，主频 2.4G，内存 2G

软件：Suse Linunx Enterprise 10，内核版本：linux-2.6.16

软件优化的三个层次

医生治病首先要望闻问切，然后才确定病因，最后再对症下药，如果胡乱医治一通，不死也残废。说起来大家都懂的道理，但在软件优化过程中，往往都喜欢犯这样的错误。不分青红皂白，一上来这里改改，那里改改，其结果往往不如人意。

一般将软件优化可分为三个层次：系统层面，应用层面及微架构层面。首先从宏观进行考虑，进行望闻问切，即系统层面的优化，把所有与程序相关的信息收集上来，确定病因。确定病因后，开始从微观上进行优化，即进行应用层面和微架构方面的优化。

系统层面的优化：内存不够，CPU 速度过慢，系统中进程过多等
应用层面的优化：算法优化、并行设计等
微架构层面的优化：分支预测、数据结构优化、指令优化等
软件优化可以在应用开发的任一阶段进行，当然越早越好，这样以后的麻烦就会少很多。

在实际应用程序中，采用最多的是应用层面的优化，也会采用微架构层面的优化。将某些优化和维护成本进行对比，往往选择的都是后者。如分支预测优化和指令优化，在大型应用程序中，往往采用的比较少，因为维护成本过高。

本文将从应用层面和微架构层面，对样例程序进行优化。对于应用层面的优化，将采用多线程和 CPU 亲和力技术；在微架构层面，采用 Cache 优化。

并行设计

利用并行程序设计模型来设计应用程序，就必须把自己的思维从线性模型中拉出来，重新审视整个处理流程，从头到尾梳理一遍，将能够并行执行的部分识别出来。

可以将应用程序看成是众多相互依赖的任务的集合。将应用程序划分成多个独立的任务，并确定这些任务之间的相互依赖关系，这个过程被称为分解（Decomosition）。分解问题的方式主要有三种：任务分解、数据分解和数据流分解。关于这部分的详细资料，请参看参考资料一。

仔细分析样例程序，运用任务分解的方法 ，不难发现计算 apple 的值和计算 orange 的值，属于完全不相关的两个操作，因此可以并行。

改造后的两线程程序：

清单 2. 两线程程序
void* add(void* x)
{
for(sum=0;suma += sum;
((struct apple *)x)->b += sum;
}

return NULL;
}

int main (int argc, const char * argv[]) {
// insert code here...
struct apple test;
struct orange test1={{0},{0}};
pthread_t ThreadA;

pthread_create(&ThreadA,NULL,add,&test);

for(index=0;indexrwLock);
for(sum=0;suma += sum;
}
pthread_rwlock_unlock(&((struct apple *)x)->rwLock);

return NULL;
}

void* addy(void* y)
{
pthread_rwlock_wrlock(&((struct apple *)y)->rwLock);
for(sum=0;sumb += sum;
}
pthread_rwlock_unlock(&((struct apple *)y)->rwLock);

return NULL;
}

int main (int argc, const char * argv[]) {
// insert code here...
struct apple test;
struct orange test1={{0},{0}};
pthread_t ThreadA,ThreadB;

pthread_create(&ThreadA,NULL,addx,&test);
pthread_create(&ThreadB,NULL,addy,&test);

for(index=0;index<ORANGE_MAX_VALUE;index++)
{
sum+=test1.a[index]+test1.b[index];
}

pthread_join(ThreadA,NULL);
pthread_join(ThreadB,NULL);

return 0;
}

这样改造后，真的能达到我们想要的效果吗？通过 K-Best 测量方法，其结果让我们大失所望，如下图：

图 1. 单线程与多线程耗时对比图

为什么多线程会比单线程更耗时呢？其原因就在于，线程启停以及线程上下文切换都会引起额外的开销，所以消耗的时间比单线程多。

为什么加锁后的三线程比两线程还慢呢？其原因也很简单，那把读写锁就是罪魁祸首。通过 Thread Viewer 也可以印证刚才的结果，实际情况并不是并行执行，反而成了串行执行，如图2：

图 2. 通过 Viewer 观察三线程运行情况

其中最下面那个线程是主线程，一个是 addx 线程，另外一个是 addy 线程，从图中不难看出，其他两个线程为串行执行。

通过数据分解来划分多线程，还存在另外一种方式，一个线程计算从1到 APPLE_MAX_VALUE/2 的值，另外一个线程计算从 APPLE_MAX_VALUE/2+1 到 APPLE_MAX_VALUE 的值，但本文会弃用这种模型，有兴趣的读者可以试一试。

在采用多线程方法设计程序时，如果产生的额外开销大于线程的工作任务，就没有并行的必要。线程并不是越多越好，软件线程的数量尽量能与硬件线程的数量相匹配。最好根据实际的需要，通过不断的调优，来确定线程数量的最佳值。

加锁与不加锁

针对加锁的三线程方案，由于两个线程访问的是 apple 的不同元素，根本没有加锁的必要，所以修改 apple 的数据结构（删除读写锁代码），通过不加锁来提高性能。

测试结果如下：

图 3. 加锁与不加锁耗时对比图

其结果再一次大跌眼镜，可能有些人就会越来越糊涂了，怎么不加锁的效率反而更低呢？将在针对 Cache 的优化一节中细细分析其具体原因。

在实际测试过程中，不加锁的三线程方案非常不稳定，有时所花费的时间相差4倍多。

要提高并行程序的性能，在设计时就需要在较少同步和较多同步之间寻求折中。同步太少会导致错误的结果，同步太多又会导致效率过低。尽量使用私有锁，降低锁的粒度。无锁设计既有优点也有缺点，无锁方案能充分提高效率，但使得设计更加复杂，维护操作困难，不得不借助其他机制来保证程序的正确性。

针对 Cache 的优化

在串行程序设计过程中，为了节约带宽或者存储空间，比较直接的方法，就是对数据结构做一些针对性的设计，将数据压缩 (pack) 的更紧凑，减少数据的移动，以此来提高程序的性能。但在多核多线程程序中，这种方法往往有时会适得其反。

数据不仅在执行核和存储器之间移动，还会在执行核之间传输。根据数据相关性，其中有两种读写模式会涉及到数据的移动：写后读和写后写 ，因为这两种模式会引发数据的竞争，表面上是并行执行，但实际只能串行执行，进而影响到性能。

处理器交换的最小单元是 cache 行，或称 cache 块。在多核体系中，对于不共享 cache 的架构来说，两个独立的 cache 在需要读取同一 cache 行时，会共享该 cache 行，如果在其中一个 cache 中，该 cache 行被写入，而在另一个 cache 中该 cache 行被读取，那么即使读写的地址不相交，也需要在这两个 cache 之间移动数据，这就被称为 cache 伪共享，导致执行核必须在存储总线上来回传递这个 cache 行，这种现象被称为“乒乓效应”。

同样地，当两个线程写入同一个 cache 的不同部分时，也会互相竞争该 cache 行，也就是写后写的问题。上文曾提到，不加锁的方案反而比加锁的方案更慢，就是互相竞争 cache 的原因。

在 X86 机器上，某些处理器的一个 cache 行是64字节，具体可以参看 Intel 的参考手册。

既然不加锁三线程方案的瓶颈在于 cache，那么让 apple 的两个成员 a 和 b 位于不同的 cache 行中，效率会有所提高吗？

修改后的代码片断如下：

清单 4. 针对Cache的优化
struct apple
{
unsigned long long a;
char c[128]; /*32,64,128*/
unsigned long long b;
};

测量结果如下图所示：

图 4. 增加 Cache 时间耗时对比图

小小的一行代码，尽然带来了如此高的收益，不难看出，我们是用空间来换时间。当然读者也可以采用更简便的方法： __attribute__((__aligned__(L1_CACHE_BYTES))) 来确定 cache 的大小。

如果对加锁三线程方案中的 apple 数据结构也增加一行类似功能的代码，效率也是否会提升呢？性能不会有所提升，其原因是加锁的三线程方案效率低下的原因不是 Cache 失效造成的，而是那把锁。

在多核和多线程程序设计过程中，要全盘考虑多个线程的访存需求，不要单独考虑一个线程的需求。在选择并行任务分解方法时，要综合考虑访存带宽和竞争问题，将不同处理器和不同线程使用的数据放在不同的 Cache 行中，将只读数据和可写数据分离开。

CPU 亲和力

CPU 亲和力可分为两大类：软亲和力和硬亲和力。

Linux 内核进程调度器天生就具有被称为 CPU 软亲和力（affinity） 的特性，这意味着进程通常不会在处理器之间频繁迁移。这种状态正是我们希望的，因为进程迁移的频率小就意味着产生的负载小。但不代表不会进行小范围的迁移。

CPU 硬亲和力是指进程固定在某个处理器上运行，而不是在不同的处理器之间进行频繁的迁移。这样不仅改善了程序的性能，还提高了程序的可靠性。

从以上不难看出，在某种程度上硬亲和力比软亲和力具有一定的优势。但在内核开发者不断的努力下，2.6内核软亲和力的缺陷已经比2.4的内核有了很大的改善。

在双核机器上，针对两线程的方案，如果将计算 apple 的线程绑定到一个 CPU 上，将计算 orange 的线程绑定到另外一个 CPU 上，效率是否会有所提高呢？

程序如下：

清单 5. CPU 亲和力
struct apple
{
unsigned long long a;
unsigned long long b;
};

struct orange
{
int a[ORANGE_MAX_VALUE];
int b[ORANGE_MAX_VALUE];
};

inline int set_cpu(int i)
{
CPU_ZERO(&mask);

if(2 <= cpu_nums)
{
CPU_SET(i,&mask);

if(-1 == sched_setaffinity(gettid(),sizeof(&mask),&mask))
{
return -1;
}
}
return 0;
}

void* add(void* x)
{
if(-1 == set_cpu(1))
{
return NULL;
}

for(sum=0;suma += sum;
((struct apple *)x)->b += sum;
}

return NULL;
}

int main (int argc, const char * argv[]) {
// insert code here...
struct apple test;
struct orange test1;

cpu_nums = sysconf(_SC_NPROCESSORS_CONF);

if(-1 == set_cpu(0))
{
return -1;
}

pthread_create(&ThreadA,NULL,add,&test);

for(index=0;index<ORANGE_MAX_VALUE;index++)
{
sum+=test1.a[index]+test1.b[index];
}

pthread_join(ThreadA,NULL);

return 0;
}

测量结果为：

图 5. 采用硬亲和力时间对比图(两线程)

其测量结果正是我们所希望的，但花费的时间还是比单线程的多，其原因与上面分析的类似。

进一步分析不难发现，样例程序大部分时间都消耗在计算 apple 上，如果将计算 a 和 b 的值，分布到不同的 CPU 上进行计算，同时考虑 Cache 的影响，效率是否也会有所提升呢？

图 6. 采用硬亲和力时间对比图(三线程)

从时间上观察，设置亲和力的程序所花费的时间略高于采用 Cache 的三线程方案。由于考虑了 Cache 的影响，排除了一级缓存造成的瓶颈，多出的时间主要消耗在系统调用及内核上，可以通过 time 命令来验证：

#time ./unlockcachemultiprocess
real 0m0.834s user 0m1.644s sys 0m0.004s
#time ./affinityunlockcacheprocess
real 0m0.875s user 0m1.716s sys 0m0.008s

通过设置 CPU 亲和力来利用多核特性，为提高应用程序性能提供了捷径。同时也是一把双刃剑，如果忽略负载均衡、数据竞争等因素，效率将大打折扣，甚至带来事倍功半的结果。

在进行具体的设计过程中，需要设计良好的数据结构和算法，使其适合于应用的数据移动和处理器的性能特性。

总结

根据以上分析及实验，对所有改进方案的测试时间做一个综合对比，如下图所示：

图 7. 各方案时间对比图

单线程原始程序平均耗时：1.049046s，最慢的不加锁三线程方案平均耗时：2.217413s，最快的三线程( Cache 为128)平均耗时：0.826674s，效率提升约26%。当然，还可以进一步优化，让效率得到更高的提升。

从上图不难得出结论：采用多核多线程并行设计方案，能有效提高性能，但如果考虑不全面，如忽略带宽、数据竞争及数据同步不当等因素，效率反而降低，程序执行越来越慢。

如果抛开本文开篇时的限制，采用上文曾提到的另外一种数据分解模型，同时结合硬亲和力对样例程序进行优化，测试时间为0.54s，效率提升了92%。

软件优化是一个贯穿整个软件开发周期，从开始设计到最终完成一直进行的连续过程。在优化前，需要找出瓶颈和热点所在。正如最伟大的 C 语言大师 Rob Pike 所说：

如果你无法断定程序会在什么地方耗费运行时间，瓶颈经常出现在意想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。

将这句话送给所有的优化人员，和大家共勉。