大厂禁止业务代码 new Thread() 是因物理线程绕过 Sidecar 导致流量劫持失效、生命周期失控、可观测性断裂；应改用虚拟线程、goroutine 或封装 SDK 等受控异步方案。
大厂在云原生 Service Mesh 架构中明确禁止业务代码 new Thread() 或直接管理原生物理线程，核心原因不是“线程不能用”，而是它与 Service Mesh 的设计哲学和运行机制根本冲突——物理线程会绕过 Sidecar 流量拦截、破坏可观测性边界、干扰资源调度，并引发不可控的稳定性风险。
一、Sidecar 流量劫持失效：线程逃逸导致治理失能
Envoy 或 Istio Proxy 的流量治理（如熔断、重试、超时、TLS 加密）仅对经过其监听端口的网络流量生效。当业务代码自行创建物理线程并发起直连调用（例如 new Thread(() -> httpclient.send(...))），该请求可能：
- 跳过本地 Sidecar 代理，直连目标服务 IP（尤其在 Pod 内部 DNS 解析+IP 直发场景）
- 使用非标准端口或协议（如自定义 TCP 连接池），不匹配 Listener 的过滤链配置
- 绕过 mTLS 双向认证，导致安全策略漏检
结果是：这部分流量在控制面完全不可见，无法被路由规则匹配、无法被指标采集、无法被故障注入影响——相当于在网格里开了个“暗道”。
二、线程生命周期失控：与 Kubernetes + Mesh 协调机制矛盾
K8s 和 Service Mesh 共同依赖“声明式运维”和“自动扩缩容”。而手动 new Thread() 带来的问题包括：
- 线程未正确关闭 → 连接泄漏、文件描述符耗尽、内存缓慢增长（JVM 中表现为
java.lang.Thread对象堆积） - 线程持有长连接或阻塞 I/O → Pod 就绪探针失败，被 K8s 误判为不健康而驱逐
- 多线程并发数不受 HPA 控制 → 实际负载远超副本数预估，引发雪崩
Sidecar 本身已通过虚拟线程或事件驱动模型（如 Envoy 的非阻塞 I/O）高效处理百万级连接；业务再开物理线程，等于在“已优化的流水线上强行加人手搬货”。
三、可观测性与排障断层：追踪链路断裂、日志归属混乱
Service Mesh 依赖统一上下文传播（如 x-request-id、b3 头）实现全链路追踪。但自主线程：
- 默认不继承父线程的 MDC（Mapped Diagnostic Context）或 OpenTracing 上下文
- 若未显式透传 TraceID，Jaeger/Zipkin 中该段调用将显示为孤立节点，甚至丢失
- 日志打点分散在不同线程名下（如
Thread-123），无法关联到具体请求或业务语义标签
这对 SRE 定位“为什么这个接口 P99 突增”造成致命障碍。
四、替代方案明确且更优：用平台提供的异步能力
大厂并非禁止并发，而是要求收敛到受控的抽象层：
- Java 场景：强制使用
CompletableFuture+ 虚拟线程（Java 21+Thread.startVirtualThread()），由 JVM 统一调度，Sidecar 可感知其 I/O 行为 - Go 场景：只允许
go func()，依赖 runtime 的 goroutine 调度器，与 Istio 的 eBPF 流量捕获兼容 - 所有 HTTP/RPC 调用必须走封装 SDK（如蚂蚁 SOFAStack 的
RpcClient），内部自动注入x-envoy-*头并复用连接池
这些方式既满足高并发需求，又确保每个请求仍流经数据面，保持治理能力完整。
不复杂但容易忽略
