一次 Java 内存泄漏排查过程,涨姿势
人人都会犯错,但一些错误是如此的荒谬,我想不通怎么会有人犯这种错误。更没想到的是,这种事竟发生在了我们身上。当然,这种东西只有事后才能发现真相。接下来,我将讲述一系列最近在我们一个应用上犯过的这种错误。最有意思的是,一开始的迹象揭示的问题,与实际发生的问题完全不同。 在一个凄凉的午夜 午夜刚过,我就被一条来自监控系统的警报吵醒了。Adventory,我们的 PPC (以点击次数收费)广告系统中一个负责索引广告的应用,很明显连续重启了好几次。在云端的环境里,实例的重启是很正常的,也不会触发报警,但这次实例重启的次数在短时间内超过了阈值。我打开了笔记本电脑,一头扎进项目的日志里。 一定是网络的问题 我看到服务在连接 ZooKeeper 时发生了数次超时。我们使用 ZooKeeper(ZK)协调多个实例间的索引操作,并依赖它实现鲁棒性。很显然,一次 Zookeeper 失败会阻止索引操作的继续运行,不过它应该不会导致整个系统挂掉。而且,这种情况非常罕见(这是我第一次遇到 ZK 在生产环境挂掉),我觉得这个问题可能不太容易搞定。于是我把 ZooKeeper 的值班人员喊醒了,让他们看看发生了什...