这个问题我在做Agile PLM集成项目时碰到过好几次，核心原因其实很直白：你的Tomcat应用连接池里还握着一堆已经失效的旧连接，而重启后的Agile PLM早就把这些连接扔了。

为什么会出现PeerGoneException？ #

PeerGoneException本质是TCP层的异常——当你的应用尝试用一个已经被远端（WebLogic上的Agile服务）关闭的连接发送请求时，就会触发这个异常。

具体到你的场景：

• Agile PLM重启时，WebLogic会彻底关闭所有关联的服务端口，销毁所有旧的会话和连接。
• 但Tomcat这边的连接池还保留着之前和Agile建立的连接，这些连接在本地看来是“存活”的，但实际上已经变成了僵尸连接（远端早已断开）。当你用这些旧连接做测试时，自然就会抛出异常。

怎么解决？ #

给你几个实用的解决方案，按优先级排序：

1. 给连接池加有效性检测 #

这是最根本的解决办法，让连接池自己识别并剔除失效连接：

• 如果是JDBC连接池（比如Tomcat自带的DBCP或者HikariCP）：
  • 开启testOnBorrow="true"：每次从池里拿连接前，先做一次有效性检测（比如执行SELECT 1 FROM DUAL这种轻量SQL），无效的连接直接丢弃，重新创建新的。
  • 或者开启testWhileIdle="true"，配合timeBetweenEvictionRunsMillis参数，定期检测空闲连接，自动清理失效的。
• 如果是WebService客户端连接池（比如CXF/Axis的HTTP连接池）：
  • 配置连接的存活时间，或者开启连接的健康检查，调用Agile的一个轻量测试接口（比如获取系统版本的接口）来验证连接有效性。

2. 缩短连接的最大空闲时间 #

把连接池里连接的maxIdle（最大空闲时间）设置得比Agile服务的连接超时时间短。比如Agile的连接超时是1分钟，你就把maxIdle设为30秒，这样旧连接还没变成僵尸就被池子里自动回收了，不会留到Agile重启后。

3. Agile重启后主动刷新连接池 #

如果你们有自动化运维流程，可以在Agile重启完成后，调用Tomcat的连接池刷新接口（比如通过JMX控制台，或者自己写一个简单的管理接口），强制清空所有旧连接，让池子重新建立新的有效连接。这样测试连接时就不会碰到旧连接了。

4. 代码层面捕获异常并重试 #

在你的连接测试代码里，专门捕获PeerGoneException，一旦触发就主动关闭当前连接（从池里移除），然后重新获取新连接再测试。这种方式可以作为兜底方案，即使前面的配置没覆盖到，也能自动处理失效连接的情况。

额外注意点 #

• 如果你用的是EJB方式调用Agile，要确保EJB客户端的连接池也做了同样的配置，因为EJB客户端也会持有远程连接。
• 可以去WebLogic的日志里查一下，Agile重启时应该会有明确的“关闭所有现有连接”的日志，这能进一步确认问题根源。

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