/**
 * 代码审计清单：这些模式需要评估
 */
public class LoomCompatibilityChecklist {
    
    // 1. ThreadLocal使用 - 检查是否有内存泄漏风险
    private static final ThreadLocal<DatabaseConnection> connectionHolder = new ThreadLocal<>();
    // 问题：虚拟线程数量可能很大，ThreadLocal值的数量也会相应增大
    // 评估：是否每次任务结束都调用了remove()
    
    // 2. synchronized块内的IO - Pinning风险
    public synchronized void processWithIO() {
        // 如果这里有数据库调用、HTTP调用等IO，会发生Pinning
        dbClient.query("SELECT 1"); // 危险！
    }
    
    // 3. 线程池配置 - 可能不再需要那么多线程
    private final ExecutorService pool = Executors.newFixedThreadPool(200);
    // 问题：虚拟线程后，这个线程池可能浪费资源
    
    // 4. 线程命名和监控 - 需要更新
    // 平台线程有明确命名可以追踪，虚拟线程需要专门的监控方案
}

3.2 ThreadLocal的迁移方案

// === 场景一：请求上下文传递 ===

// 改造前：ThreadLocal
public class RequestContextHolder {
    private static final ThreadLocal<RequestContext> CONTEXT = new ThreadLocal<>();
    
    public static void set(RequestContext ctx) { CONTEXT.set(ctx); }
    public static RequestContext get() { return CONTEXT.get(); }
    public static void clear() { CONTEXT.remove(); }
}

// 改造方案一：保留ThreadLocal，但用虚拟线程per-task模式
// 每个虚拟线程处理一个请求，任务结束后ThreadLocal自动随线程消亡
// （不需要显式clear，但要确保没有线程池复用虚拟线程）
Thread.ofVirtual()
    .name("request-handler")
    .start(() -> {
        RequestContextHolder.set(context);
        try {
            processRequest();
        } finally {
            RequestContextHolder.clear(); // 良好习惯，即使不复用也应该清理
        }
    });

// 改造方案二：Java 21 ScopedValue（推荐用于新代码）
public class RequestContextHolder2 {
    public static final ScopedValue<RequestContext> CONTEXT = ScopedValue.newInstance();
    
    // ScopedValue的key特点：
    // 1. 不可变，线程安全
    // 2. 在绑定的代码块结束后自动清理
    // 3. 天然支持结构化并发的子任务继承
}

// 使用ScopedValue
ScopedValue.where(RequestContextHolder2.CONTEXT, context)
    .run(() -> {
        processRequest(); // 这里可以访问CONTEXT.get()
        // 子任务（虚拟线程）也能访问到CONTEXT
    });
// 代码块结束，CONTEXT自动失效

3.3 解决synchronized Pinning

// 系统性替换synchronized的工具方法
public class PinningFixer {
    
    /**
     * 将synchronized方法改造为使用ReentrantLock
     * 使用字节码工具或手动重构
     */
    
    // 原始代码
    public class OriginalClass {
        private final Object lock = new Object();
        
        public synchronized String getData() {
            return fetchFromDB(); // 会Pinning！
        }
        
        public void process() {
            synchronized (lock) {
                externalHttpCall(); // 会Pinning！
            }
        }
    }
    
    // 改造后
    public class RefactoredClass {
        private final ReentrantLock lock = new ReentrantLock();
        
        public String getData() {
            lock.lock();
            try {
                return fetchFromDB(); // 不再Pinning
            } finally {
                lock.unlock();
            }
        }
        
        public void process() {
            lock.lock();
            try {
                externalHttpCall(); // 不再Pinning
            } finally {
                lock.unlock();
            }
        }
    }
}

3.4 线程池改造策略

@Configuration
public class ExecutorConfig {
    
    /**
     * 策略1：IO密集型任务 - 改用虚拟线程
     */
    @Bean("ioTaskExecutor")
    public ExecutorService ioTaskExecutor() {
        // 不再需要固定大小的线程池
        // 每个任务一个虚拟线程，JVM自动调度
        return Executors.newVirtualThreadPerTaskExecutor();
    }
    
    /**
     * 策略2：CPU密集型任务 - 保持平台线程
     * 虚拟线程对CPU密集型任务没有帮助
     */
    @Bean("cpuTaskExecutor")
    public ExecutorService cpuTaskExecutor() {
        int cores = Runtime.getRuntime().availableProcessors();
        return Executors.newFixedThreadPool(cores,
            new ThreadFactoryBuilder().setNameFormat("cpu-task-%d").build());
    }
    
    /**
     * 策略3：混合任务 - 按类型路由
     */
    @Service
    public class TaskRouter {
        
        @Qualifier("ioTaskExecutor")
        @Autowired
        private ExecutorService ioExecutor;
        
        @Qualifier("cpuTaskExecutor")
        @Autowired
        private ExecutorService cpuExecutor;
        
        public <T> CompletableFuture<T> submitIO(Callable<T> task) {
            return CompletableFuture.supplyAsync(() -> {
                try { return task.call(); } 
                catch (Exception e) { throw new RuntimeException(e); }
            }, ioExecutor);
        }
        
        public <T> CompletableFuture<T> submitCPU(Callable<T> task) {
            return CompletableFuture.supplyAsync(() -> {
                try { return task.call(); }
                catch (Exception e) { throw new RuntimeException(e); }
            }, cpuExecutor);
        }
    }
}

3.5 监控和可观测性

/**
 * 虚拟线程的监控适配
 */
@Component
public class VirtualThreadMonitor {
    
    private final MeterRegistry meterRegistry;
    
    @EventListener
    public void onApplicationStarted(ApplicationStartedEvent event) {
        // 监控虚拟线程数量（通过JMX/JFR）
        setupVirtualThreadMetrics();
    }
    
    private void setupVirtualThreadMetrics() {
        // 注册Gauge监控活跃虚拟线程数
        Gauge.builder("jvm.threads.virtual.active", this, monitor -> {
            ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
            return (double) Arrays.stream(threadBean.getAllThreadIds())
                .mapToObj(id -> threadBean.getThreadInfo(id))
                .filter(info -> info != null && info.getThreadName().startsWith("virtual-"))
                .count();
        }).register(meterRegistry);
    }
    
    /**
     * 检测Pinning事件（生产环境监控）
     */
    public void enablePinningMonitor() {
        // 通过JFR事件监控
        // jcmd <pid> JFR.start duration=60s filename=pinning.jfr
        // 然后分析VirtualThreadPinned事件
        
        // 或者通过System Property开启日志
        System.setProperty("jdk.tracePinnedThreads", "short");
    }
}

四、工程实践：改造优先级矩阵

4.1 按影响程度排序

4.2 框架兼容性

框架/库	Loom支持状态	注意事项
Spring Boot 3.2+	完整支持	spring.threads.virtual.enabled=true
Tomcat 10.1+	支持	自动配置虚拟线程
Netty	不适用	Netty有自己的异步模型
HikariCP 5.1+	兼容	注意连接池大小配置
Jedis 5.x	有Pinning风险	内部synchronized
Lettuce	支持好	本来就是异步客户端
gRPC-java 1.57+	支持	需要特定配置
MyBatis	透明兼容	不影响功能，可能有Pinning

五、踩坑实录

坑一：连接池被打爆

这是我们改造后第一个遇到的问题，前面虚拟线程篇也提到了，但这里从架构角度说清楚。

虚拟线程让每个请求都能立即执行，不用在队列里等。但数据库连接是有限的，大量虚拟线程同时竞争连接，HikariCP的等待队列瞬间排满。

根本原因：传统线程池本身就是一种限流机制，线程数限制了并发请求数。虚拟线程去掉了这个限制，但数据库的承载能力没变。

解决方案：用Semaphore或RateLimiter限制数据库并发访问量。

// 用Semaphore限制数据库并发
private final Semaphore dbSemaphore = new Semaphore(50); // 最多50并发

public User findUser(Long id) throws InterruptedException {
    dbSemaphore.acquire();
    try {
        return userRepository.findById(id).orElseThrow();
    } finally {
        dbSemaphore.release();
    }
}

坑二：日志追踪断链

我们系统用MDC（Mapped Diagnostic Context）传递TraceId，基于ThreadLocal实现。改成虚拟线程后，子任务的MDC上下文没有正确继承。

// 问题：虚拟线程的子任务看不到MDC
String traceId = MDC.get("traceId");
Thread.ofVirtual().start(() -> {
    System.out.println(MDC.get("traceId")); // null！
});

// 解决：手动传递MDC
Map<String, String> mdcContext = MDC.getCopyOfContextMap();
Thread.ofVirtual().start(() -> {
    if (mdcContext != null) {
        MDC.setContextMap(mdcContext);
    }
    try {
        System.out.println(MDC.get("traceId")); // 有了
    } finally {
        MDC.clear();
    }
});

长远来说，应该用ScopedValue替代MDC里的ThreadLocal部分。

坑三：第三方库的synchronized导致性能不升反降

我们有个依赖，内部大量使用synchronized来保证线程安全，但它的操作里有大量IO。改成虚拟线程后，Pinning事件极多，平台线程全被占满，吞吐量还不如改造前。

排查花了一天，最后发现是这个库。升级到新版本（重写了lock机制），问题解决。

教训：升虚拟线程之前，先用BlockHound做一遍扫描，找出所有阻塞点。

坑四：OOM排查变得更困难

虚拟线程可以创建几百万个，堆里会有大量虚拟线程对象。一次内存泄漏排查中，我发现堆里有50万个虚拟线程对象，每个都持有一个数据库连接——原因是有个地方的代码没有正确释放资源，在虚拟线程的放大效应下，变成了严重的内存问题。

虚拟线程的轻量性是双刃剑，创建容易了，泄漏的代价也更大。

六、总结与个人判断

Loom项目是Java历史上最重大的运行时变革之一，它的工程影响被大多数人低估了。简单开一个配置spring.threads.virtual.enabled=true确实很容易，但要真正用好虚拟线程，你需要：

全面审计代码中的synchronized+IO组合，这是最高优先级
重新评估线程池配置，IO密集型任务不再需要大线程池
规范化ThreadLocal的使用，避免内存泄漏
更新监控体系，现有的线程监控工具可能失效

我建议的改造节奏：先在测试环境开启虚拟线程，用BlockHound扫描Pinning点，用性能测试验证改进效果，再逐步推进到生产环境。不要一把全开，分服务、分阶段地推进。

Project Loom的最终目标是让Java程序员彻底忘掉并发的复杂性，用最简单的同步代码写出高性能的并发程序。这个目标我认为已经基本实现，但完全达到还需要整个生态继续演进。