Java 虚拟线程为什么不适合长时间持有锁

虚拟线程降低了大量等待任务的线程成本，却不会让同一把独占锁同时被多人持有。锁内做慢I/O或长计算，仍会让竞争者排队。还要区分JDK版本：JDK 24的JEP 491消除了synchronized相关的主要虚拟线程固定问题，但没有消除锁的互斥语义。

官方地址：https://openjdk.org/

线程变多以后先找共享锁

设想一个配置缓存：每次读取都进入同一个synchronized块，缺少数据时还在锁内访问远程服务。如果由我处理它的虚拟线程迁移，我会先检查这把共享锁，而不是先增加调度器线程。下面是分析用场景，不是一次生产实测复盘。

最容易产生的错觉是“线程更便宜，所以等待不再重要”。等待线程确实可能更省资源，但业务请求仍在等待锁；远程访问慢一次，其他读取也可能被拖住。线程成本与临界区吞吐量是两个不同约束。

我会先记录锁对象是否全局共享、谁持有它、锁内做什么工作，以及请求是否确实需要串行。这比单看线程数量更接近问题。

把锁竞争与载体固定分开

在JDK 21到23的语境里，synchronized区域内阻塞可能涉及载体固定。JDK 24引入JEP 491后，不能继续把“使用synchronized”一概视为固定载体的理由。具体发行版是否回移相关改动，应按其发布说明确认。

JDK 25官方说明仍列出了native方法或外部函数相关的固定情况。因此没有monitor相关固定，不代表任何阻塞都无代价；反过来，没有观察到固定事件，也不能证明共享锁没有造成排队。

缩小临界区时重新检查一致性

对于允许读到旧快照、且允许并发刷新重复加载的缓存，可以把加载移到锁外，锁只保护快照发布。下面是JDK 21及以上可使用的类片段；Loader由调用方提供，本文没有执行网络请求：

import java.util.Map;

public final class CatalogCache {
    public interface Loader {
        Map load() throws Exception;
    }

    private final Object lock = new Object();
    private Map snapshot = Map.of();

    public String get(String key) {
        synchronized (lock) {
            return snapshot.get(key); // 仅访问已发布的不可变快照。
        }
    }

    public void refresh(Loader loader) throws Exception {
        // 慢操作在锁外；失败时异常交给上层，旧快照保留。
        Map loaded = Map.copyOf(loader.load());
        synchronized (lock) {
            snapshot = loaded; // 只在短临界区内发布完整结果。
        }
    }
}

这个改法有明确条件：Map.copyOf不接受null键值；映射值是不可变String；并发刷新可能重复加载，后完成的结果会覆盖先完成的结果。若业务要求最新版本绝不能被旧结果覆盖，需要增加版本判断或刷新协调，不能直接采用这个片段。

如果原来的锁还保护“检查库存并扣减”这样的原子业务，把检查和更新拆到锁两侧会破坏正确性。我更愿意先写清楚不变量，再判断哪些慢工作可以移出，不能只追求锁内代码行数少。

换锁之前确认真正需要的语义

把synchronized机械替换成ReentrantLock，不会改变同一独占临界区只能串行的事实。后者适合确实需要可中断获取、限时尝试或其他显式锁能力的场景；采用后还必须保证finally中释放。

如果锁只是被用来限制外部接口并发，应重新判断是否需要真正的共享状态互斥，或者应使用信号量表达容量限制。已经由连接池管理的稀缺资源，也不要无理由再叠加一层全局锁。

我的取舍是保留易懂的同步关系，优先消除不必要的串行范围。对受CPU约束的工作，虚拟线程也不会凭空增加计算资源。

按相同负载观察改造结果

改造后使用相同请求量和数据条件比较延迟分布、成功吞吐量、锁等待及外部资源占用。JFR和支持虚拟线程的线程转储能提供线索，但事件含义应按运行JDK解释，不能把固定事件与所有锁等待等同。

还应覆盖加载失败、重复刷新以及读取并发出现的情况。对于上面的快照示例，要确认失败时保留旧值、读取不见到半成品，并确认“完成顺序覆盖”的策略确实可接受。这些是读者复查建议，没有虚构任何性能数字。

JDK 24以后可以在锁里无限等待吗？

仍不合适。载体能否释放和其他线程能否获得这把锁是不同问题。

虚拟线程是否不能使用synchronized？

可以使用。需要评估的是共享范围、持有时间、运行版本及一致性要求，而非简单禁用关键字。

把锁外移后数据错乱怎么办？

先恢复正确性，明确原子边界，再选择快照、版本判断或其他协调方式，不能用吞吐量收益掩盖数据错误。

官方资料：JEP 491的版本变化、JDK 25虚拟线程说明。