Hazelcast成员日志出现TcpIpConnection关闭警告，求异常原因分析

先把你提供的日志内容贴出来方便对照：

2018-04-17 15:38:59.734 - WARN --- [hz._hzInstance_1_dev.IO.thread-in-2] com.hazelcast.nio.tcp.TcpIpConnection : [172.16.42.193]:5701 [dev] [3.9.3] Connection[id=30, /172.16.42.193:5701->/172.16.15.16:54266, endpoint=[172.16.15.16]:5701, alive=false, type=MEMBER] 已关闭。原因：Connection[id=30, /172.16.42.193:5701->/172.16.15.16:54266, endpoint=[172.16.15.16]:5701, alive=true, type=...

针对这个MEMBER类型连接关闭的警告，我整理了几个最常见的排查方向：

• 网络层面异常：这是最大概率的原因。两台集群节点（172.16.42.193和172.16.15.16）之间可能出现了网络波动、丢包，或者防火墙/安全组临时阻断了Hazelcast默认的5701端口通信，导致TCP连接被强制断开。你可以用ping、telnet 172.16.15.16 5701这类命令测试节点间的连通性，同时检查防火墙规则是否有临时变更。
• 节点资源耗尽：如果172.16.15.16这台节点的CPU、内存或者文件句柄被耗尽，会导致Hazelcast无法维持正常连接，进而主动关闭连接。比如IO线程池过载、JVM发生内存溢出（OOM），都会触发这类问题。建议查看该节点的系统监控数据，以及JVM的GC日志、Hazelcast的详细日志，看是否有资源告警信息。
• 节点主动退出集群：172.16.15.16节点可能因为手动重启、配置变更生效，或者遇到未捕获的致命异常导致进程崩溃，在退出时会主动关闭和其他集群节点的连接。你可以检查该节点的启动/停止日志，看是否有进程退出的相关记录。
• 超时配置不合理：如果Hazelcast的hazelcast.socket.timeout或者hazelcast.connection.timeout参数设置得过短，当节点间通信延迟稍微增加（比如网络高峰时段），就会触发连接超时被关闭。你可以核对下集群的配置文件，看看这些超时参数是否符合你的实际网络环境。
• 版本兼容性问题：虽然日志里显示集群版本都是3.9.3，但如果后续集群引入了不同版本的节点，或者客户端与服务端版本不匹配，也可能导致这类连接异常。不过当前案例里这条可能性较低，但可以作为后续排查的备选方向。

内容的提问来源于stack exchange，提问作者user2966021