Java线程在HotSpot JVM中与操作系统内核线程严格1:1映射，每个new Thread().start()触发pthread_create（Linux）或CreateThread（Windows）创建LWP或内核线程，生命周期与调度均由OS管理。
java 线程在主流 jvm（如 hotspot）中，并不是“运行在虚拟机里就与操作系统无关”的抽象体——它真实、直接、一对一地绑定到一个操作系统内核线程上。这种 1:1 映射不是设计妥协，而是现代并发能力的底层基石。
每个 new Thread().start() 都触发一次系统调用
当你执行 new Thread(() -> {...}).start()，HotSpot 不是在 JVM 内部“模拟”出一个线程，而是立即调用操作系统的原生接口：
- 在 Linux 上，最终调用 pthread_create()，创建一个轻量级进程（LWP），内核为其分配独立的 task_struct 结构；
- 在 Windows 上，则调用 CreateThread()，生成一个由 Windows 内核调度的内核线程；
- 该线程拥有独立的内核栈、寄存器上下文、调度优先级和信号处理能力，完全由 OS 调度器管理。
Java 线程生命周期 = 内核线程生命周期
Java 层面的线程状态变化，基本同步反映到底层内核线程的状态：
- NEW → RUNNABLE：对应内核中 LWP 创建完成，进入可运行队列；
- RUNNABLE → BLOCKED（如 synchronized 竞争失败）：JVM 在用户态做自旋或挂起，但若涉及锁竞争激烈，可能触发 futex 等系统调用，让内核线程进入休眠；
- RUNNABLE → WAITING/TIMED_WAITING（如 Object.wait() 或 Thread.sleep()）：JVM 主动调用 park() / nanosleep() 等系统调用，使对应内核线程让出 CPU 并进入等待队列；
- TERMINATED：JVM 回收 Java 对象后，调用 pthread_join() / CloseHandle()，内核销毁 task_struct，释放资源。
为什么必须是 1:1？不是为了“简单”，而是为了正确性
早期 JVM 曾用用户级线程（Green Threads），但被彻底淘汰，关键原因在于三类不可绕过的真实世界约束：
- 多核并行失效：用户级线程全靠 JVM 单一线程模拟调度，无法真正分发到多个 CPU 核心；
- 阻塞式 I/O 拖垮全局：一个线程读文件阻塞，整个 JVM 的所有用户线程都会停摆——因为它们共用同一个内核线程；
- 信号与中断不兼容：OS 发送的 SIGUSR1、SIGQUIT 等信号只能投递给内核线程，用户级线程无法被操作系统感知和响应。
代价清晰，但可控：上下文切换与栈内存
1:1 模型带来可测量的成本，但它不是“缺陷”，而是权衡后的显式契约：
立即学习“Java免费学习笔记（深入）”；
- 每次线程切换需从用户态陷入内核态，保存/恢复寄存器、切换 MMU 上下文、更新调度器元数据——典型开销约 1–5 微秒；
- 每个平台线程默认分配 1MB 栈空间（可通过 -Xss 调整），大量线程会快速耗尽虚拟内存，但这正是一致性保障的代价；
- 线程数上限受制于 OS 限制（如 Linux 的 /proc/sys/kernel/threads-max 和内存），而非 JVM 自身。
这种映射真相，不是为了让人回避线程，而是让人理解：Java 线程就是 OS 线程。写好并发代码的前提，是尊重这个事实——该用线程池控制数量，该用虚拟线程卸载 I/O 阻塞，该用 LockSupport 精确干预调度点。不神秘，也不抽象，就在 syscall 和 task_struct 之间。
