遇到Java服务“自己引用自己”的坑？排查思路与解决姿势
最近在折腾服务部署的时候，遇到一个让人哭笑不得的问题：Java服务居然开始“自己引用自己”，导致CPU飙升甚至直接卡死。这种情况乍一听很离谱，但在实际开发中，如果对配置或者某些机制理解不到位，真的容易踩坑。今天就来复盘一下这个问题可能的原因，以及该怎么排查和解决。
服务CPU飙升时的常见表象
一、现象：服务“内卷”起来了
通常遇到这种问题，表象无外乎以下几种：
- CPU爆表：某个核心线程一直处于Runnable状态，忙得停不下来。
- 日志刷屏：控制台疯狂打印相同的请求日志，时间戳几乎一致。
- 连接池耗尽：HTTP客户端连接数暴增，甚至因为等待超时而报错。
服务自引用形成的死循环原理
简单来说，就像是服务自己发了一个请求给自己，然后这个请求又触发了发请求的逻辑，形成一个死循环。这就是所谓的“自己引用自己”。
二、原因分析：为什么会“自己打自己”？
要解决这个问题，得先搞清楚它是怎么发生的。大概率是以下几种情况之一：
1. 分布式链路追踪或回调陷阱
最常见的原因是在代码里写了类似this.callSelf()的逻辑，或者使用了Feign/RestTemplate时，目标地址配置成了当前服务的地址。比如在做全链路压测时，配置中心的开关没关好，或者负载均衡策略选错了，本来该调下游，结果路由回了自己。
2. 定时任务或Event Loop失控
如果你的服务里用了定时任务，或者使用了像Reactor这样的响应式编程模型，发布订阅模式配置不当，可能会导致消息在同一个服务内部无限循环消费。
3. 长连接与心跳机制
标题里提到的“longcat”（可能指代长连接或长轮询场景），如果心跳机制没有做好幂等性，可能会因为网络抖动导致客户端疯狂重连，服务端为了维持连接又疯狂响应，造成一种“引用自己”的假象。
深层原因： 往往是因为服务拆分不够彻底，或者缺乏明确的环境区分（开发、测试、生产环境配置混用）。
三、排查三板斧
遇到了别慌，按照这个顺序来，大概率能定位到问题。
第一步：抓取线程堆栈
这是最快的手段。在服务器上执行：
jstack <pid> > dump.log
打开dump.log，找那些RUNNABLE状态的线程。如果你看到类似Thread-A在等待Thread-B，而Thread-B又在等待Thread-A，或者同一个方法在调用栈里出现了好几次（递归调用），那基本就锁定了。
第二步：查看网络流量
使用netstat或ss命令看连接情况：
ss -tulnp | grep <your_port>
如果发现大量ESTABLISHED状态的连接，且源IP和目的IP居然都是本机，那就坐实了“自引用”。
第三步：检查配置中心
去Nacos、Apollo或者你的配置文件里搜一下url、host、target等关键字。看看有没有把localhost或者本机内网IP配置成了下游服务地址。
四、解决方案：如何终结死循环？
找到了原因，解决起来就对症下药了。
1. 代码层面的隔离
如果业务逻辑确实需要回调，一定要加上熔断机制。比如使用Resilience4j或者Hystrix，限制同一时间内的调用频次。
// 伪代码示例：增加防重检查
if (traceId.startsWith("SELF_CALLBACK_PREFIX")) {
log.warn("检测到自引用调用，直接中断");
return;
}
2. 网络层面的拦截
在网关层（如Nginx或Spring Cloud Gateway）加个规则，如果是内网IP访问特定的敏感接口，直接拒绝。
3. 修复长连接超时
针对“longcat”场景，优化你的KeepAlive设置和超时时间。确保客户端在心跳超时后，是指数退避重试，而不是立即狂暴重试。
五、总结
Java服务“自己引用自己”虽然听起来很蠢，但其背后往往反映了架构设计上的盲点，特别是微服务治理和配置管理的严谨性。
以后再遇到CPU报警、服务假死，先别急着重启服务（虽然重启最快），花两分钟看一眼线程堆栈和网络连接，没准就能发现这种“蠢到哭”的低级错误。
评论已关闭