根本原因是jvm方法区类加载边界混乱导致多租户上下文隔离失效；表现为跨租户数据混写、日志id错乱、敏感字段泄露，高并发或灰度后复现，重启临时恢复，需通过类加载追踪、classloader校验及上下文传播优化来诊断修复。

这类事故不常见，但一旦发生，现象典型：租户A的数据被写入租户B的表、日志中出现跨租户的用户ID、接口返回其他租户的敏感字段。根本原因不是数据库或网络层出错，而是JVM方法区（Metaspace）中类加载边界混乱，导致多租户上下文隔离失效。

确认是否为类加载边界问题

先排除更常见的配置错误（如tenant_id漏传、数据源路由错配），再聚焦方法区。关键线索包括：

• 故障仅出现在高并发压测或灰度发布后，重启单个服务实例即临时恢复
• 同一JVM内，不同租户请求共用同一个TenantContext静态实例或ThreadLocal未正确清理
• 使用了自定义类加载器（如OSGi、Spring Boot DevTools、热部署插件），且未按租户隔离ClassLoader实例
• 堆转储（heap dump）中发现多个TenantRoutingDataSource或TenantLineInnerInterceptor对象指向相同Class对象，但内部状态不一致

检查类加载与上下文绑定逻辑

重点审查三类代码：

• 租户上下文传递：确认TenantContext.setCurrentTenant()是否在Filter/Interceptor中调用，且remove()在finally块中执行；避免在异步线程（@Async、CompletableFuture）中直接继承主线程ThreadLocal
• 动态数据源类加载：若使用AbstractRoutingDataSource子类，确保其Class由应用类加载器（AppClassLoader）加载，而非被Tomcat WebAppClassLoader或自定义ClassLoader重复加载多次
• MyBatis-Plus多租户插件：检查TenantLineHandler实现类是否被声明为static内部类或单例——这会导致所有租户共享同一handler实例，getTenantId()返回值被覆盖

验证与修复步骤

无需立即上线，先通过诊断确认：

• 添加JVM启动参数：-XX:+TraceClassLoading -XX:+TraceClassUnloading，观察日志中是否出现同一类被多个ClassLoader重复加载（如com.example.TenantInterceptor被WebAppClassLoader和RestartClassLoader各加载一次）
• 在关键拦截器入口打印this.getClass().getClassLoader()和Thread.currentThread().getName()，确认不同租户请求是否落到同一ClassLoader实例
• 将TenantContext从static改为基于RequestContextHolder的request-scoped Bean，或改用InheritableThreadLocal并显式传播到子线程
• 禁用开发期热加载工具（如Spring DevTools、JRebel），生产环境统一使用标准JAR包部署