【Java】一次历时两周的排bug经历

公司内部使用的一套自研RPC框架（称为m框架）是基于thrift的。在这个框架下，服务提供者在某个zk服务器（称为注册中心）上注册服务，服务消费者从注册中心消费服务。我负责开发提供者，冯同学负责开发消费者。该bug被冯同学发现。

冯同学对该bug的描述：“你们的服务耗时也太久了点，经常性延迟好几秒，有时候十几秒都有，我这边都超时了。你们能不能优化一下速度？”

冯同学的描述和我的观察不一致。我当初刚把这些接口开发完毕进行自测时，响应时间的量级是十毫秒。

遂着手排bug。

排bug的第一步是复现这个现象。万万没想到，复现这个bug花了我好久。

我的资源包括一台开发机macbook和两台测试机（称为s9和s10）。轻车熟路把项目在本地起起来，测了一下接口，响应时间几毫秒。将项目打包并部署到s10上，再次检测，响应时间也是几毫秒。复现bug失败了，我怀疑是网络环境问题，于是请冯同学再次调用一下接口方法测试一下接口速度。冯同学测了之后表示响应速度很快。

↑说实话听到这个结论我是很头大的。如果我测试接口很快，冯同学同时测试接口发现很慢，我就可以把锅甩给网络环境或机器了。但是这件事没发生，说明锅不在网络环境或机器上，那锅就有可能在我身上。

我和冯同学同时调接口方法，发现都很快。我自欺欺人地觉得bug大概率是偶发但持久的网络波动导致的，转头去干别的开发工作了。

一整天相安无事。第二天接到冯同学的抱怨：“又卡起来了啊。”

于是我在开发机上起了一个消费者去调用s10上的方法接口，并在调用前后记录了时间戳。确实，响应速度非常不理想。但是从控制台ping s10是很快的。锅不在网络环境上。我又在自己的开发机上把项目起