ss -p 不能直接看到 Java 线程内部逻辑，但能暴露高频、异常、重复的 TCP 连接行为，是死循环式网络握手（如反复 connect→timeout→retry）的典型外在痕迹；需先用 ss -tnp 锁定可疑连接及 PID，再通过 /proc/PID/fdinfo 和 jstack 定位到具体线程栈与代码行。
系统网络响应极慢时，ss -p 本身不能直接看到 Java 线程内部逻辑，但它能暴露「高频、异常、重复」的 TCP 连接行为——这是死循环式网络握手（比如反复 connect → timeout → retry）最典型的外在痕迹。关键不是靠 ss -p 单独定位线程，而是用它作为第一跳线索，快速锁定可疑连接，再反向映射到 Java 线程。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
先用 ss -p 抓住“正在疯狂建连”的进程和端口
执行：sudo ss -tlnp | grep java —— 查看 Java 进程监听了哪些端口sudo ss -tnp 'sport = :8080 or dport = :8080' —— 聚焦目标端口（如服务端口或下游依赖端口）
重点观察：
- 大量 SYN-SENT 状态连接（客户端反复发 SYN，但没收到 ACK）
- 大量 TIME-WAIT 且持续快速新建（说明连接刚断就又重连）
- 同一源端口反复出现（127.0.0.1:42391 → 127.0.0.1:42392 → 127.0.0.1:42393），说明应用层在短时间密集创建新 socket
从连接反推 PID 和线程 LWP
ss -tnp 输出中每行末尾的 users:(("java",pid=12345,fd=123)) 给出的是进程 PID 和文件描述符 fd。
但注意：一个 Java 进程内可能有成百上千线程，而 ss 不显示具体线程 ID（LWP）。需进一步关联：
- 记下该连接对应的 pid=12345
- 执行 ls -l /proc/12345/fd/123，确认这个 fd 确实指向 socket（类型为 socket:[1234567]）
- 再用 sudo lsof -p 12345 -a -d 123 或 cat /proc/12345/task/*/fdinfo/123 2>/dev/null | grep -A1 pid，可查到哪个线程（task）持有该 fd —— 输出中的 pid: 行即为该线程的 LWP（十进制）
用 jstack 定位到具体线程栈和代码行
拿到 LWP 后：
- printf '%x\n' 27982 → 得到十六进制线程 ID（如 6d4e）
- jstack 12345 > jstack.out
- 在 jstack.out 中搜索 nid=0x6d4e（注意带 0x 前缀且小写）
死循环握手的线程通常表现为：
- 状态为 RUNNABLE
- 栈顶是 java.net.PlainSocketImpl.connect、SocketChannelImpl.connect 或 Netty 的 doConnect
- 循环体里没有合理的退避（如 Thread.sleep(1000)），也没有连接成功后的状态更新
验证是否真为死循环，而非正常重试
光看栈不够，要确认调用频次：
- 用 Arthas：trace *HttpClient connect -n 100，看 1 分钟内是否调用数百次
- 检查代码中是否有：
• while (!connected) { socket.connect(...); } 且无超时或 sleep
• retryPolicy = new RetryPolicy().maxRetries(Integer.MAX_VALUE)
• 使用了未配置重试上限的 FeignClient 或 RestTemplate
- 特别注意：JVM 优化可能把简单 while 循环编译成 tight loop，perf top -p 12345 若看到 sys_connect 或 do_syscall_64 占比极高，就是强证据
