Java线程调用start()后真实触发操作系统创建原生内核线程，采用1:1映射模型：new Thread()仅创建Java对象，start()通过JNI调用os::create_thread()（如pthread_create），由内核分配独立调度实体（LWP），run()在其上下文中执行字节码。
Java 线程调用 start() 后，并不是“启动一个虚拟线程”，而是**真实触发操作系统创建一个原生内核线程**——这就是 1:1 映射的实质。它不是 JVM 自己调度的协程，也不是用户态模拟的轻量线程，而是让操作系统亲自认领、管理、调度的一个独立执行单元。
映射不是“绑定”，而是“委托创建”
JVM 不自己实现线程调度器，而是把线程生命周期完全交给 OS：
- new Thread() → 堆中创建 Java 对象：仅是普通对象，无 OS 资源，处于 NEW 状态；
-
start() → JVM 进入 JNI 层 → 调用 os::create_thread()：Linux 下实际封装
pthread_create()，Windows 下调用CreateThread()； - 内核分配 task_struct：每个 Java 线程对应一个独立的内核调度实体（LWP），拥有自己的 pid（但 tgid = 主线程 pid），共享进程资源（如内存、文件描述符、信号处理）；
- run() 执行 → 在该内核线程上下文中运行字节码：JVM 把 Java 方法栈压入这个内核线程的执行流，CPU 真实在跑它。
为什么必须是 1:1？历史教训说清楚了
早期 JVM 曾尝试“N:1 用户线程模型”（比如绿色线程），结果被彻底淘汰，原因很硬：
- 阻塞式 I/O（如
FileInputStream.read()、Socket.recv()）会直接挂起整个用户线程调度器，导致进程内所有 Java 线程卡死； - 无法利用多核并行：用户态调度器只能在一个 CPU 上轮转，哪怕机器有 64 核，也只用得上 1 个；
- 无法响应系统级事件（如信号、中断、超时），调度粒度粗、不可靠。
所以 HotSpot 从 JDK 1.3 起就全面转向 1:1 模型，Linux 用 NPTL，Windows 用 Win32 Thread API —— 这不是设计选择，是现实倒逼的必然。
立即学习“Java免费学习笔记（深入）”；
内核真相：你看到的“Java 线程”，就是 Linux 的 LWP
在 Linux 中运行一个 Java 程序，用 ps -eLf | grep java 查看：
- 主线程显示为 PID = TID（即线程组 ID = 线程 ID），表示它是线程组 leader；
- 每个
start()出来的线程，都会作为一个独立的 LWP（Lightweight Process）出现在列表里，有自己的 TID，且与主线程共享 TGID； - 它们在 /proc/[pid]/task/ 目录下各有一个子目录，每个子目录对应一个
task_struct，可查其调度策略、优先级、CPU 使用时间等。
换句话说：Java 线程名（如 "pool-1-thread-3"）只是 JVM 给的标签，内核眼里它就是一个标准的、带完整上下文的调度单位，和 C 语言 pthread_create 出来的线程毫无区别。
代价与边界：1:1 不是免费午餐
1:1 模型带来确定性调度和多核支持，但也付出明确成本：
- 每次
start()都是一次系统调用（clone()或pthread_create()），涉及内核态切换、栈空间分配（默认 1MB）、task_struct初始化； - 线程数量受限于 OS 资源：不是 CPU 核心数，而是
/proc/sys/kernel/threads-max和可用内存（每个线程栈占空间）； - 频繁创建销毁线程（如每请求起一个）会导致显著开销，这也是线程池成为标配的根本原因。
