JMeter WebSocket Read Sampler无法捕获消息 读超时问题排查

• 跨线程传递WebSocket连接的方式存在本质缺陷：threadLocalCachedConnection是线程私有的ThreadLocal变量，setUp线程组与后续业务线程组分属独立线程池，你从setUp线程中取出的WebSocketClient对象虽然被存入了全局属性，但底层Socket对应的输入输出流是有状态、非线程安全的资源。setUp线程组执行完成后线程会被销毁，绑定在该线程上的Socket流资源会被部分回收，你传递到业务线程的只是一个失效的对象引用，无法执行正常的读写操作。
• 连接标识逻辑存在错配风险：你使用ctx.getThreadNum()作为连接存储的key，但setUp线程组和普通线程组的线程编号是独立计数的，当前两边各1线程时编号同为0看似匹配，只要任意一侧线程数调整，就会出现拿错连接、空引用的问题。
• 缺少业务订阅生效校验：你仅校验了WebSocket TCP连接建立成功，没有在连接建立后发送业务层面的订阅请求，也没有校验订阅成功的服务端响应，发布端发送消息时订阅端实际未加入对应消息的投递范围，自然收不到任何消息，等待达到超时阈值后就会抛出java.net.SocketTimeoutException: Read timed out异常。

• 优先放弃setUp线程组建连、跨线程传连接的方案：将发布端、订阅端的WebSocket Open Connection采样器直接放在对应业务线程组的起始位置，同一线程组内的WebSocket采样器默认自动复用当前线程下的已建连接，无需手写JSR223脚本缓存传递连接，从根源上规避跨线程传递有状态Socket资源的问题。
• 若确需跨线程组复用连接，不要手动存取原始WebSocketClient对象：直接使用WebSocket Samplers插件自带的全局连接缓存能力，在Open Connection采样器中指定自定义连接名（例如订阅端连接命名为participantA_conn），后续其他采样器勾选Use existing connection选项并填入相同连接名即可实现全局安全复用，插件本身已经处理了跨线程场景下的资源生命周期管理和线程安全逻辑，无需自行编写属性存取代码。
• 补全连接建立后的业务校验链路：WebSocket连接打开后，第一时间发送业务订阅请求，新增一个Read Sampler等待并校验服务端返回的订阅成功响应，确认订阅关系在服务端生效后，再启动发布端发送测试消息的流程，避免等待不会被投递的消息。
• 时序问题临时排查：可在订阅端完成订阅校验、发布端发送消息之间增加100ms固定定时器，排除两端启动速度差导致的"先发消息、后订阅"问题，该手段仅用于排查，不能替代正式的订阅成功校验逻辑。

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