事情起因：当时接了个需求，开发过程中需要对工程A新增依赖工程B和工程C。
写代码，噼里啪啦噼里啪啦。。。
本地起了三个dubbo服务，其他服务依赖开发环境服务，非常开森改自己冒烟的bug。
提测！
测试环境，工程A死活起不来，起到一半卡住！没有任何异常！！！然后过了三分钟，抛出zk心跳连接超时，巴拉巴拉。。
2018-11-22 14:38:03,857 INFO [kafka-coordinator-heartbeat-thread | webull-trade-analyse--center] Marking the coordinator 10.xx.2.xxx:9092 (id: 2147483646 rack: null) dead for group webull-trade-analyse--center (org.apache.kafka.clients.consumer.internals.AbstractCoordinator) (AbstractCoordinator.java:631)
2018-11-22 14:38:12,049 WARN [localhost-startStop-1-SendThread(10.70.2.173:2181)] Client session timed out, have not heard from server in 41557ms for sessionid 0x36605afb146892d (org.apache.zookeeper.ClientCnxn) (ClientCnxn.java:1108)
2018-11-22 14:39:49,437 INFO [localhost-startStop-1-EventThread] zookeeper state changed (Disconnected) (org.I0Itec.zkclient.ZkClient) (ZkClient.java:713)
试过的办法：
1、检查测试环境zk集群的ip和端口。正常
2、检查kafka配置。正常
3、把kafka对应consumer干掉再启动。失败
4、重启测试环境卡住的日志最后一个依赖的dubbo服务，再启动。失败
5、一顿其他瞎操作！！！
一顿操作猛如虎，搞到凌晨都没搞定。。
第二天同事提醒是否和内存有关系，然后查看了下，开发环境配置的xms和xmx 2G，测试环境1G。
发现工程B启动的时候放了一大大大堆到内存中。以前没有依赖B的时候，A随便起。
现在GG。后面把测试环境内存加大，重启。完事！！
麻蛋，一开始怎么没有往内存方面想，心想着内存问题，你至少给我抛个OutOfMemory出来吧！！！