事情起因：當時接了個需求，開發過程中需要對工程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出來吧！！！