Project Loom 重写线程模型，将线程变为 JVM 内部调度单元，实现 M:N 虚拟线程调度；虚拟线程阻塞时自动释放平台线程，同步代码获得异步性能；零改造兼容现有并发 API 与调试工具；支持百万级并发，重塑高并发开发方式。
Project Loom 没有改良线程模型，而是重写了它——把“线程”从操作系统资源变成 JVM 内部调度单元，让并发从稀缺走向丰裕。
打破 1:1 映射，实现 M:N 调度
传统 Java 线程与 OS 线程一对一绑定，每个线程默认占用约 1MB 栈空间，创建成本高、数量受限。虚拟线程由 JVM 管理，多个虚拟线程共享少量平台线程（Carrier Threads），形成 M:N 关系。一个应用可轻松启动百万级虚拟线程，而内存仅增几百字节/个，上下文切换在用户态完成，开销近乎忽略。
阻塞不再等于浪费 CPU
当虚拟线程执行 I/O、锁等待或 sleep 等阻塞操作时，JVM 自动将其挂起，并立即释放所依附的平台线程去执行其他任务。这意味着：同步风格的代码（如 Thread.sleep(1000) 或 socket.read()）能天然获得异步性能，无需改造成 CompletableFuture 或响应式链式调用。
零改造兼容现有生态
虚拟线程完全复用原有并发语义：synchronized、ReentrantLock、ThreadLocal、ExecutorService 全部可用。只需将 Executors.newFixedThreadPool(200) 替换为 Executors.newVirtualThreadPerTaskExecutor()，就能让旧代码跑在新模型上。调试时仍可见完整堆栈，IDE 断点照常生效。
重新定义高并发开发方式
过去为规避线程开销，开发者被迫采用复杂异步模型，牺牲可读性与可维护性；现在可以回归自然的“每请求一虚拟线程”设计。微服务中处理万级 HTTP 连接、数据库批量查询、消息轮询等 IO 密集场景，不再需要精心调优线程池大小，也不再因线程耗尽导致请求排队或超时。
