吉德林法则（Kidlin’s Law）

美国通用汽车公司管理顾问查尔斯·吉德林提出：把难题清清楚楚地写出来，便已经解决了一半。也就是说只有先认清问题，才能很好地解决问题。这种观点在管理学上被称为吉德林法则。

案例对话

与合作公司开发一个并发的数据处理的后台系统，主要负责接收、处理和转发数据。由于人员紧缺，所以让一个新手项目经理负责整个系统的设计和实现。项目经理仔细理解了需求然后设计一套系统。

他在系统设计完过以后，进行了初步的测试，告诉我系统的性能现在很有问题，系统虽然可以接受大量的数据，但是延时却随着数据量显著增加。由于经验有限，无论如何，他也解决不了这个问题，于是我们就有了以下的对话。

我：你觉得现在的主要问题是什么？
他：性能不行。
我：为什么？
他：因为框架不好
我：框架为什么不好？
他：消息传递的不是很流畅。
我：为什么框架不流畅？
他：总觉得有些细节不对。
我：你可以说清楚是哪些细节吗？
他：我也说不清楚，总感觉哪里不对。

他不能确定问题所在，于是我只好换个问题

我：你觉得系统性能瓶颈在哪里？
他：可能是输入部分吧。
我：输入的部分为什么是瓶颈？
他：在输入的时候由于信息量比较大，因此会形成瓶颈。
我：那数量有多大呢？
他：数量挺大的。
我：你能不能做一个估算？
他：好的，假如说我们有10万用户，那么10万用户连接的时候，每秒钟大概会有一次通讯，这样的话呢就是10万次通讯。每次通信一般1-2条消息，每一条消息大概是一二十个字节。消息的作用只表明他在线或者是他做了什么样的选择，这些操作的消息的题量都很小，甚至有的消息只有几个字节。
所以，可以平均地理解为每个用户每秒最多30个字节。这样的话，总量是3MB/s。
我：实际上10万用户不可能都会发这么多数据，对吧？
他：是的，按1/3活跃用户计算，数量总流量为 1MB/s。
我：我们的带宽是多少？
他：100 mbps. 如此算来，输入也不是瓶颈。

通过流量估计，我们排出了输入瓶颈

他（仔细思考后）：就说那这样的话入口带宽应该不是问题，卡顿的原因可能是因为我们的数据处理耗时比较多。
我：那你这个消息是怎么处理的呢？有哪些处理操作是比较耗时的呢？

他又详细和我解释了一下消息的整个流程，从不同的模块之间怎么扭转，但是经过一番查看，这些操作仅仅是把消息进行了派发，而在处理的时候使用的是多线程，因此数据处理当中也不存在瓶颈。

我：经过上面的分析，我们发现系统的数据处理模块，仅仅是对消息进行分类和派发，根据我的个人经验，一般1个核心的计算能力，可以实现每秒千万条的数据分类和派发，所以系统的数据处理模块也不是瓶颈。

经过以上的分析，我们看到，虽然排除了部分原因，但是仍然没有找到根本的问题是什么。

我：那么延时是在哪里产生的，你知道吗？
他：不清楚，目前只知道消息从获得到派发出去有几秒的延时。
我：你可以在所有的消息处理的地方加上日志，跟踪一条消息（消息有编号）看看时间出在哪里。
他：好的。

经过半天的努力，给我回报有结果了

他：经过测试，我发现消息在进出消息队列的时间占用了大量的时间。由于消息队列的长度是不定长的，所以他使用的数据结构是LinkedList，并且每个操作都有加锁和解锁操作。我调查后发现知道，列表使用的本身从逻辑上来说是没有问题的，但是在消息量非常大的时候就出现了问题，因为链表的访问的性能是不高的，所以当数量很大的时候如10万数据量时，延时会非常明显，同时再考虑加锁和解锁操作，会占用大量的CPU资源因此导致显著的延时。
我：找到问题了，可以解决吗？
他：没问题，解决不难，我可以将LinkedList 改成数组。虽然数组的长度是有限制的，但是10万长度的数组还是很容易实现的，并且我们可以提前预留把数组的长度，比如说射程20万或者50万都是OK的。毕竟，在Java中，能支持的最大的数组长度是20亿（2³¹），或者我再搜索一下，使用第三方的现成框架也可以。

最终，他采用了一个第三方的消息管理框架，终于解决了问题。

结语

通过上面的例子，我们可以看出，发现和找到问题的本质其实是不容易的，尤其是在一个复杂的系统当中，能够准确而清晰的找到问题，往往比解决问题本身还要困难。比如，我们在系统中找到延时产生的原因真的是花了很多的功夫。但是一旦找到问题，解决起来真的很简单。

因此，吉德林法则是非常实用的，也就是说能够清晰准确的描述问题的本质，往往已经把问题解决一半了。在计算机领域，甚至于远大于一半，基本上找到问题，几乎都可以很快地解决。

所以，我们需要在遇到问题时，需要清楚地搞明白到底问题是什么。在上面的示例中，从开始错误地理解的框架不行，到使用了错误的数据结构，从而才真正解决问题。