吐艹一下某公司总架构师

[Lonely_Snow]

这号称有10+年工作经验的架构师，一晚上跟我争论一问题，伪代码如下

HANDLE hThread = CreateThread();
CloseHandle(hThread);

那架构师看到我写这样的代码，然后跟哥抬扛了，问到”你这不等于把刚起的线程给杀死了么？“
楼主无语中，说了句，你去看看msdn，然后那架构师看了回来了，然后，说到”你这样会导致不稳定，你关闭handle后，你怎么控制线程”。。。。
楼主实在忍不住了，说了句“你想怎么控制，TerminateThread?"
接下来，那架构师发火了。。。。说我工作不负责。。。。。。。。。。。。。

[lincolnandlinda]

那们架构师怎么不说:C++11都出来了为什么不用std::thread类? CloseThread 相当于 thread.detach()

[ccnyou]

引用 322 楼 lincolnandlinda 的回复:

那们架构师怎么不说:C++11都出来了为什么不用std::thread类? CloseThread 相当于 thread.detach()

很多公司还在用 Visual Studio 2005/2008

[super_admi]

这话比较扯淡吧？最典型的就是监听服务程序：非线程池的情况下，一般一个连接就会新创建一个线程来处理。创建线程的这个监听程序，你能完全管控你自己创建的线程？ 你举的例子涉及到多线程同步问题，和管控有个毛的关系，前面就有人提过WaitFor了，也提过线程间通信了。

引用 313 楼 ccnyou 的回复:

[quote=引用 6 楼 supermegaboy 的回复:] 偶会比这个总架构师发更大的火。

+1 自己开的线程要负责管理这个线程的生命周期，你这样太不负责任了。 举个例子，如果刚关了句柄，用户要关程序，你的线程就异常退出了，轻则导致数据丢失，严重会导致数据不完整而后面程序都执行不了。[/quote]

[super_admi]

线程同步可能会用到线程句柄，但貌似不是一定会用到线程句柄吧？再说了，人家的程序，一定有同步要求？

引用 305 楼 zhuobattle 的回复:

[quote=引用 304 楼 Lonely_Snow 的回复:] [quote=引用 300 楼 zhuobattle 的回复:] 请用_beginthreadex,CreateThread在某些情况下会出错，不是吓你。

知道CreateThread在某些情况下会出现泄露_tiddata结构的情况，但会出错，请给个示例学习下。[/quote] 是同步问题，比泄漏严重。[/quote]

[super_admi]

我同意伪老赵的观点。一般业务中，除了线程池管理，很少会用到线程句柄的。即使是做线程同步，我一般也不会使用线程句柄。

引用 321 楼 zhao4zhong1 的回复:

[quote=引用 317 楼 shinerise 的回复:] [quote=引用 316 楼 zhao4zhong1 的回复:]

File: F:\软件\VC6\MSDN98\SAMPLES\VC98\SDK\SDKTOOLS\WINNT\SWITCHER\SWITCHER.C 1 occurrences found on 1 lines
    159:            CloseHandle(CreateThread(NULL, 0,
File: F:\软件\VC6\MSDN98\SAMPLES\MSDN\PERIODIC\4598\KTTEST.CPP 1 occurrences found on 1 lines
    261:          CloseHandle(CreateThread(NULL, 0, WorkerMonitorThread,
File: F:\软件\VC6\MSDN98\SAMPLES\MSDN\TECHART\3274\NEVIEW.CPP 1 occurrences found on 1 lines
    502:  CloseHandle(CreateThread(NULL,9,(LPTHREAD_START_ROUTINE)DebugTreadFunction,
File: F:\软件\VC6\MSDN98\SAMPLES\MSDN\TECHART\3274\PEVIEW.CPP 1 occurrences found on 1 lines
    703:  CloseHandle(CreateThread(NULL,9,(LPTHREAD_START_ROUTINE)DebugTreadFunction,

我是想看一下演示代码，createhandle()之后closehandle()，然后还可以使用这个thread 的handler的例子。不是说只是演示closehandle()这个函数的。你发的这些个例子，无非只是说明closehandle()函数是用来关闭createthread()创建的句柄而已。[/quote] 这些例子代码都说明，CreateThread之后，如果不再使用其返回的Handle，最好立即CloseHandle之。[/quote]

[Sandrer]

为什么意见统一不了？就是因为每个人做的事都不一样，所以你不可能为所有人都规定一个固定的方式来做事。 createthread 之后立刻 closehandle 也不是说不可以，但你要看线程里面在做什么事 如果无关紧要的强制关闭都没有影响的那无所谓 但如果里面处理的是重要数据，你的程序退出前必须等待它完成或者让它有时间来中断工作的话，那就另外一种处理方式了

[赵4老师]

引用 327 楼 Sandrer 的回复:

为什么意见统一不了？就是因为每个人做的事都不一样，所以你不可能为所有人都规定一个固定的方式来做事。 createthread 之后立刻 closehandle 也不是说不可以，但你要看线程里面在做什么事 如果无关紧要的强制关闭都没有影响的那无所谓 但如果里面处理的是重要数据，你的程序退出前必须等待它完成或者让它有时间来中断工作的话，那就另外一种处理方式了

不要企图优雅的结束（因为这是不可能办到的） 而要在烂的不能再烂的摊子上也能重整河山！ http://bbs.csdn.net/topics/390787357

[Sandrer]

引用 328 楼 zhao4zhong1 的回复:

[quote=引用 327 楼 Sandrer 的回复:] 为什么意见统一不了？就是因为每个人做的事都不一样，所以你不可能为所有人都规定一个固定的方式来做事。 createthread 之后立刻 closehandle 也不是说不可以，但你要看线程里面在做什么事 如果无关紧要的强制关闭都没有影响的那无所谓 但如果里面处理的是重要数据，你的程序退出前必须等待它完成或者让它有时间来中断工作的话，那就另外一种处理方式了

不要企图优雅的结束（因为这是不可能办到的） 而要在烂的不能再烂的摊子上也能重整河山！ http://bbs.csdn.net/topics/390787357 [/quote] 没有最好只有更好，人不能面面俱到，我们只能努力去避免程序发生不可逆的错误 今天写的代码可能在有限的条件下测试没问题，但不保证技术的不断升级改造而造成的程序不适应性 同一句代码在不同编译器、不同的编译选项、不同系统中产生的最终效果都有可能发生差异 这些都只能在测试过程里才能慢慢的逐步完善 做事也不能以偏概全，每样事物总有它存在的道理 就像这帖子所说的线程句柄关闭时机，我觉得我后面不再需要它了，那就建立后就立刻关闭咯 但不做任何判断就能保证线程是否建立成功？线程建立成功后里面的工作是否已经完成？如果线程以外其它地方需要用到线程中处理的数据，但数据未准备就绪，那是否需要重新建立线程？如果重新建立线程，怎么保证之前建立的线程是否还存在？ 所以我的重点应该在于线程的工作是否完成，还有如果没完成的话怎么去处理，而不在于何时、怎么去关闭线程 相对于客户来说，产品运行良好、界面友好、功能达到要求就基本ok了 他们不会管你是怎么实现这些功能，而我们能做到这些功能得益的还是我们自己

[l201l]

lz 做法有问题，thread如果是在 挂起时，close是没有用的。

[qiminixi]

个人觉得，如果线程不需要handle进行控制，handle立即释放掉是没关系的，留着也没用。 LZ也不要装逼过头了，仕途不利。

引用 330 楼 u011014707 的回复:

这不是技术问题，已经升华到了处事的问题。

+1

[12304108]

这不是技术问题，已经升华到了处事的问题。

[paschen]

这个架构师真是让人笑死！

[paschen]

其实创建新进程的时候我一般才CloseHandle，新线程我一般不用

[Minikinfish]

不建议使用CreateThread(),最好使用_BeginThread

[赵4老师]

任何问题首先是一个哲学问题。不是吗？

[柠檬用柠檬泡了杯柠檬水]

看看 MSDN 是怎么说的： 1. When a thread terminates, the thread object attains a signaled state, satisfying any threads that were waiting on the object. 2. The thread object remains in the system until the thread has terminated and all handles to it have been closed through a call to CloseHandle. 其一，创建线程的句柄肯定是有用的（句柄是内核对象与进程的关联），例如可以 WaitForSingleObject 等待线程结束。 其二，线程内核对象只有在所有句柄被关闭的时候，系统才会把它析构。所以 CloseHandle( hThread ) 是线程退出当中必要的一步。 所以当创建线程的宿主不需要与新创建的线程有交流（等待 / 控制）时，完全可以解除与线程内核对象的关系。即 CloseHandle( hThread )

[bluesen]

同意11楼说法，伤了他的自尊。也不知道为啥，有些年长位尊者苍老的心灵却分外脆弱。 我是超过20年的老鸟，有次90后同事纠正我Linux的发音，我不以为忤，呵呵接受。

[赵4老师]

说是一物即不中。 搜“盲人摸太阳”

[w826207]

楼主的错， 写代码的原则是， 凡是让人看着不爽的代码都不对， 即使走的通 你这样写扩展性和可靠性没法保障， 要是不知道扩展性和可靠性是啥， 看看查msdn能不能查到--！

[庄鱼]

2年前的坟又被人挖出来了！ 不过，过去这么久，相信楼主也写了不少的代码，也有跟人合作的经历了，回头看看，是不是觉得架构说得有道理呢？ 从编程角度，我本人是对这种线程技术持抵触情绪的，不是因为不熟悉，而是线程技术并不像其宣称的那么安全，线程割裂对数据的伤害远比进程大得多，另一个原因是，线程技术是针对CISC指令技术而言的软分布式计算技术，CPU单一化能够提供更高的效率；进程是针对RISC指令技术的硬分布式计算技术，多CPU多并发环境效率更高。 从某种意义上来说，线程仅仅是复杂指令架构下迫于无奈的对分时系统的仿真，美其名共享内存是因为需要相同的缓冲区进行应用分割调度与唤醒(其实在线程中一直是被轮巡的就没有被挂起过，这点可以从线程机制分析得出)。由于线程的单一CPU处理特点，几乎不可能出现进程互锁现象，但是线程异常会导致时间片的时序分割错误以及线程间的内扰(由同一内存区引发，线程未完成被再次调度而导致的程序链时序或赋值错误) ，甚至产生代码间隙陷阱直接导致系统死机。在虚拟机环境中，严重时，若干个虚拟环境中一个环境的崩溃引发整个机器的时钟时序错误而导致机器硬件宕机。而这在精简指令架构下简直是不可思议的。 写这么多的目的在于提醒楼主，在创建线程时，有没有考虑过系统安全与异常？有没有考虑采用更透明的机制？而不是将代码的安全交给一个正完善的第三方，有没有考虑过所有的代码都是可控的？是将程序稳定寄托于“成熟技术”的第三方，还是将其牢牢地掌握在自己手里，即便是一种尝试性地新技术？想通这些，这将是程序员与构架师之间的分水岭。虽然国内的很多构架师并不这么做。