是不是常常会有这样的问题：做完了计划，反而不去执行了？对于觉得需要做的事情，立刻去做，有时候会比什么样的计划都要好。

最近买了很多书，一本Masterminds of Programming，一本Effective Java2中文版，一本Programming Pearls，还有一本著名的GEB（哥德尔 爱舍儿 巴赫：集异璧之大成）。

Effectiva Java2与Programming Pearls是重读，Masterminds of Programming是当八卦书看的，GEB是源于我对某些问题的爱好。

Effectiva Java2真是好书，非常适合Java库的开发人员阅读，就算是新手，如果按着它的准则做，也真能写出漂亮的代码，所以我特别推荐Java新手看这本书，它可以帮你的代码和人生减少很多错误。
Effectiva Java2讲的是招数，但它的招数特别：招数成了，心法也会了。我打算在这周把它看完。

Programming Pearls是经典的面试书，原来的一本在搬家的时候丢了，就又补了一本，既然补了，就打算重看一遍。

MasterMinds of Programming，我虽然当他是八卦书，但是看起来真的很累。很多陌生语言的特性，我不熟悉；他们的文化，我也不了解；于是就很难去理解他们的创造者的呓语。

GEB，我读了开头，很精彩，打算让老婆也看一下；或许哥德尔和他的世界太过奇异，有的人认为这是一种绚丽，有的人认为是悲剧。但其实，你是不是偶尔也会这样觉得：不完备性其实更符合直觉？哥德尔，图灵，丘奇的工作只是在讲述一件直白的事情？

看私人的书要带只笔，涂涂写写，我总是匆匆的过了很多精彩的书，真是遗憾。

注意：由于个人能力及知识水平问题，以下内容可能有原则性错误，请批判着阅读！

最近搜东西，又搜到了这个关于pthread_kill的话题，相信有不少人看过这个讨论。NPTL的作者真霸道。看了几遍pthread_kill的手册，然后放心的写代码，然后得到一个core dump，相信谁都会不爽的。

但用pthread_kill(pid, 0)来检测一个线程的运行情况是一件不靠谱的行为，虽然这是非常普遍的行为：Joinable的线程完结了，还没执行pthread_join()，这个状态，pthread_kill(pid, 0)能正常识别么？规范没有说，其实很多实现都没有能够区分这两种状态吧。（1 运行中, 2 运行结束，还没join）还有一种比较不大可能发生的事情——通常，你的代码能提前发现这个问题：pid如果被重用了呢？这种时候，其实你检查的是一个全新的线程。

pthread_kill()是一个非常难用的方法，在确定你的线程能正确的处理信号之前，不能随意的向某个线程发出信号；如果你的程序不能正确处理，你的整个系统都会由于这个方法的调用而终止。出于对其的害怕，我从来没有在自己的代码里使用过它。

如果要关闭一个Server线程，其实可以为线程提供一个shutdown()方法，像所有Java程序员都会的那样；如果要立刻终止一个线程，可以用pthread_cancel(pthread_t)，当然这个方法也会有风险(你不知道你要关闭的线程是不是已经终止了，你也不知道你要关闭的线程或许是一个全新的线程)。所以，pthread_cancel(pthread_t)方法需要在同步块内调用，调用前，确认 线程处于有效的状态。而线程也需要在同步块内才能改变自己的状态。

我觉得安全的做法，不论是pthread_cancel，或是pthread_kill，都需要利用同步机制，确认线程先有效，再操作。当然，很多人不这么认为，因为他们的代码从不这样写。

上篇日志提到Thrift ThreadPoolServer有时候会出现较多的close wait状态，有朋友问我这是不是thrift的bug？写过Server比较多的同志们应该能意识到这个问题的原因，不值得说，可是我今天实在是太郁闷无聊了，我就写写我的想法吧。

我觉得这当然不能算是Thrift的Bug，如果出现了这样的问题，其实是因为错误的选择了Server的类型，错误的实现了Client，过于保守的Server Max Connection配置等等原因。

对于ThreadPoolServer而言，每一个客户端连接，Server端都需要提供一个固定的线程来维护，在空闲时，线程堵塞在read()操作，等待客户端数据的到来。Thrift ThreadPoolServer中使用的默认线程池是定长线程池，意味着Server端能提供的线程池数是有限的。当线程用完时，新的连接将不能得到Server殷勤的服务，它不会在乎你的生死，你必须等待。

举个例子：

我有一个用Thrift ThreadPoolServer（使用SimpleThreadPool）实现的Server，最大支持100个连接，现在有100个客户端连接到我的Server。实现客户端的程序员都很在乎TCP连接建立的开销，因此，他们都维护了一个长连接。这个时候，如果有第101个客户端连接到Server了，会发生什么情况呢？

1. Server会接受这个连接，连接成功建立；
2. Server没有合适的线程来处理这个连接，于是将这个连接放到暂存列表；
3. 如果这个时候有线程空闲了，则一切顺利，这个线程将接管这个连接；
4. 但遗憾的是，我们没有空闲线程，所以这个连接一直处于空闲状态，直到客户端程序timeout(如果设置了timeout的话)；
5. 连接timeout，意味着暂存列表里的连接已经失效了，此时对应的socket处于CLOSE_WAIT中（出现了本文开头的情况），遗憾的是，我们依然没有空闲的线程来处理这个连接，所以它一直处于CLOSE_WAIT中。
6. 终于，某一个时刻，有一个客户端关闭了连接，我们有了空闲线程，它去查看暂存列表。发现有一个socket fd，尝试去接管它，对这个fd执行read()，然后得到一个Connection Reset error，终于，我们可以优雅的关闭它了（CLOSE_WAIT结束）。
7. 以上就是全部的故事。

那么，要怎么办？

1. 如果连接数太多，为什么不用NonBlockingServer呢？Thrift有基于libevent的实现，虽然它的ThreadPool限制了NonblockingServer的性能，但是，你可以方便的实现一个存/取线程更高效的ThreadPool.
2. 你可以实现一个TimeoutCachedThreadPool来替代SimpleThreadPool.
3. 提高Max Connection的值.

   前段时间，同事发现一个采用Thrift TheadPoolServer作为TCP的服务出现了大量的CLOSE_WAIT状态的socket。当第一次遇到这种问题的时候，你可能会有如下的问题：

1. 什么是CLOSE_WAIT? 为什么会发生?
2. 还有其他类似状态我不知道的么？

其实，你真正想问的是：

1. 当tcp通道关闭时，发生了什么事情？
2. 我该怎么办？

TCP通道是一个连接，连接的两端都可以向通道里写数据或者从通道里读数据，连接的两端都可以发起关闭操作。整个TCP通道的关闭流程如下：

A(socketfd:10) <——–TCP Connction ———->B(socketfd:20)

1. 关闭A，则A向B发送FIN;
2. B接受到FIN后，返回一个ACK，表明收到了关闭通知， 当B返回ACK后，状态就转变为CLOSE_WAIT（！）了，它在等待什么呢？等待程序显式（手动）的关闭socket B。如果打开B的程序在发出ACK后，没有做任何处理，那么它就一直处于CLOSE_WAIT中了。
3. 如果程序显式的关闭了B，那么B会向A发送一个FIN，然后B就处于LAST_ACK状态了；
4. A在接受到B的FIN后，发出最后一个ACK，此时A就处于知名的TIME_WAIT状态了。TIME_WAIT时间一般会比较长。

如何避免CLOSE_WAIT? 太多的CLOSE_WAIT通常意味着你程序中存在着严重的问题：没有正确处理socket的关闭事件，去查看代码吧。

如何避免TIME_WAIT? 通常，这是一个不应该问的问题，应该先问自己，TIME_WAIT真的给你带来麻烦了么? TIME_WAIT是可靠性的保证机制，没有必要去避免它。但或许，你可以尝试一下使用RFC1323。如果某一端实在是有太多的TIME_WAIT而造成问题，我建议的策略是：

1. 尽量避免TIME_WAIT过多的一端主动关闭socket
2. 使用SocketPool，避免频繁创建/关闭socket

11月初，我把座位从公司7楼的一端搬到了另一端（我至今还没弄清楚具体的方位），就这样，从网易杭研搬到了网易邮件部。

一切都在从头开始。

我读了一遍cyrus-sasl的代码，弄清楚其逻辑及各种结构后，为它写了一个新的认证机制。测试完后，我想我短期内不会再有C/C++的活了吧。

抽空大概的浏览了ZimbraServer的代码，我们并不打算从里面借鉴什么，我只是想尽快熟悉下邮件系统到底是怎么回事。我开始写一些底层的模块，主要是存储/解析，以及抽象一些结构，用Java开发真是感觉良好。

正在集中精神开发新Server的时候，我又同时参与了一个C++项目N（目前就我1个开发人员），项目已经开始稳定，不过还有很多后续功能要开发。我记得在1个月前做过一个梦，梦见自己开始接手这个N项目，程序不稳定，服务器一直坏，压力很大。没想到前半部分成真了，后半部分是否成真，那还得看天意。

我和同事两人干了一件有趣的事情，我们把自己的Map-Reduce/DFS系统与Hadoop，以及另外一套某搜索引擎使用的Map-Reduc/DFS做了较为深入的分析和性能/功能测试。测试的结果非常符合我们的期望，NEMR/DFS的组合从文件的存取效率，Map-Reduce的任务分发/容错/易用性等都要明显好于Hadoop与另一套系统。当然，这三个系统的定位并不一致。

四月份，我接到的任务是重新整理DFS的Java接口，除了整理了一下包结构与异常机制，我基本没有做什么有价值的事情。原有的Java代码有较深的C/C++风格，另外，代码结构虽然凌乱但能完美的工作，我有些无从下手。当把整理完的结果commit，并关掉任务的时候，我有一种深深的负罪感。

我们组与其他部门开始合作一个应用于廉价存储设备的支持大文件的分布式文件系统（大文件意味着整个系统的元数据基本很小）。支持大文件的分布式系统开发其实比较简单，这是一个C++的项目，作为一个不是很称职的Java程序员，刚开始做C++项目的时候充满了惊奇的体验。我只负责一些边缘的开发工作，比如为这个文件系统做一个shell, 并参与了部分系统对外接口的开发，做为一个C++初学者都算不上的家伙，我在这个项目里每写一行代码都十分的小心，倒也没有出什么问题。

我一直期望把分布式文件系统的接口做的不让人惊奇。处理DFS里的文件像本地文件那样open/write/read/close/unlink，支持流式写入等。（最近开始全面接手上面的项目，可以对其好好改造啦！嘿嘿）

6月份开始了一个较大的项目，我们组开始做一个全新的支持廉价设备的(且低碳省电的)大量小文件存储的分布式文件系统。我负责开发文件的对外Java接口，以及文件系统的存储节点(C++)。其他同事开发管理工具和master。由于考虑到自己只是一个C++新人，我有意识的只使用C++的一个子集来开发系统以避免额外的复杂性。虽然在一开始就约束自己不要重做轮子，可是到了最后，还是造了很多基础设施（线程安全的集合, BlockingQueue, ThreadPool, Runnable, DailyRollingLog等等),  Hacker了一个库的部分代码。可能是因为没有找到简单，可靠的C++实用库吧。这次开发感觉很顺利，我想很大程度上要归功于我们使用了一个非常酷的通信/rpc框架，它引起的麻烦远远要小于它所克服的麻烦。

之后的精力花在了大量线上数据的迁移/线上系统的维护上面，大概有10000亿个线上文件需要迁移到新开发的文件系统。