synchronized会导致虚拟线程被固定，因其monitor依赖OS线程级阻塞原语，迫使JVM将虚拟线程绑定至当前平台线程以保证锁语义安全，从而丧失调度弹性；应缩小临界区、改用JUC原子类或并发集合、细化锁粒度，并通过JFR监控高频Pinning。
Java虚拟线程（Virtual Thread）在synchronized块中会被“固定”（pinning），即被迫绑定到某个平台线程（Platform Thread）上执行，失去轻量调度优势。这不是bug，而是JVM为保证锁语义一致性而做的安全设计——因为synchronized依赖底层操作系统互斥原语（如mutex），而这些原语与平台线程强关联。
为什么synchronized会导致虚拟线程被固定
虚拟线程由JVM调度、用户态挂起/恢复，但synchronized的monitor实现依赖OS线程级阻塞（如futex或pthread_mutex）。当虚拟线程进入synchronized块并竞争锁失败时，JVM必须将其挂起在当前运行它的平台线程上，不能切换到其他平台线程——否则无法安全唤醒和恢复锁状态。这导致该虚拟线程在整个同步块生命周期内始终占用一个平台线程，丧失并发弹性。
识别是否发生了不必要固定
可通过以下方式确认：
- 使用
jcmd <pid> VM.native_memory summary观察平台线程数是否异常增长 - 开启JVM参数
-XX:+UnlockDiagnosticVMOptions -XX:+PrintPinnedThreadStacks，在发生固定时打印堆栈（仅限诊断） - 监控
jdk.VirtualThread:PinnedJVM TI事件（需配合JFR或自定义监听器）
避免固定的核心策略
关键不是完全不用synchronized，而是减少其作用范围和使用场景：
立即学习“Java免费学习笔记（深入）”；
-
优先用无锁结构：如
java.util.concurrent中的AtomicInteger、ConcurrentHashMap、StampedLock等，它们内部不依赖OS级阻塞 - 缩小synchronized粒度：只保护真正共享且需原子性的字段，避免包裹I/O、网络调用或长耗时逻辑
-
用ReentrantLock替代（谨慎）：默认仍会固定，但可配合
tryLock()非阻塞尝试，失败后主动yield或重试，避免死等 - 对临界区做异步拆分：例如将“读-改-写”拆成纯内存操作（用CAS）+ 异步持久化，把同步逻辑控制在微秒级
特殊情况下的兼容处理
若必须用synchronized（如遗留代码、第三方库内部逻辑），可考虑：
- 将高争用的同步块移到专用平台线程池中执行（如
Executors.newFixedThreadPool(n)），让虚拟线程只负责调度和编排 - 用
Thread.ofVirtual().unmount()手动卸载虚拟线程上下文（JDK 21+），再以平台线程身份执行同步逻辑，完成后重新挂载——但需自行管理上下文传递，适用性有限 - 接受局部固定：只要固定时间极短（纳秒~微秒级）、争用率低，对整体吞吐影响有限，不必过度优化
不复杂但容易忽略——虚拟线程的价值在于“大量并发+低争用”，而非替代所有同步机制。理解pinning的边界，比强行绕过更重要。
