今天遇到一个神坑，坑了足足有半天的时间，一直在这个坑里面爬不出来，当然有很大一部分原因是因为我经验不足引起的，今天和大家一起分分享一下这个神坑。
坑的场景：
项目采用
dubbo+zookeeper实现分布式
RPC调用。客户端和服务端都是
springboot项目，客户端通过
RPC远程调用服务端，但是意外的出现了
Tried 3 times of the providers的错误，发现服务端对应的接口被重复调用了
三次，而且服务端没有报任何错误，客户端反而出现如下所示的错误：
提出问题可能的原因：
所以就特别纳闷，然后就开始寻找问题的原因，问题的原因刚开始想到一下四点：
1.客户端接口和服务端接口的实现类没有一一对应
2.客户端请求服务端超时，导致请求重试
3.传输的参数过大，导致服务端返回给客户端的时候出现问题（因为我看客户端返回的堆内存溢出）
4.返回的数据，没有进行序列化，导致结果返回不了给客户端
问题解决过程：
然后我就根据总结的这几点原因，一一去寻找是不是这些原因引起这个问题的。
首先检测一客户端的接口和服务端的接口实现类是不是一致的，发现是一致的，所以排除第一个原因。
根据第二点原因，我就将客户端的请求时间和超时重试次数做了相应的修改，如下图所示：
最后发现这个问题还是没解决，说明也不是这个原因引起的。
对于第三点，我就将返回的参数大小设置一个大值，设置的值如下所示：
结果发现还是没有任何软用，照样堆溢出，简直坑的一批。
最后只能期望与最后一点了，结果还是令人失望，实体类是有做序列化的，所以也不是这个问题。
峰回路转：
这样最后一个线索也全断了，在快要放弃的时候，突然看到一堆JSONArray和JSONObject错误，想着会不会是json的问题，最后发现还真实json的问题，大家看看我引用的json就知道了。
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
</dependency>
json-lib的依赖中多了
<classifier>jdk15</classifier> 和jdk1.8冲突，导致堆溢出的。最后我机智的将
json-lib改为
fastjson依赖就成功的解决这个问题了。
坑的总结：
总结一点就是，看问题不要只看表面原因，可能是其它原因引起的，就像这个json冲突，导致堆溢出。它表现出来的状态就是服务端连续请求三次，导致我一直以为是
dubbo的问题，没有往json这方面思考，然后一直贻误战机。