这是两种主流的并发模型，核心区别在于 线程与 CPU 的映射关系。
文中对比数据都是理论数据，无实验数据支撑，图片来自网络，侵删
水平有限，如有错误，请评论！
一、核心模型对比
| 特性 |
Java 线程池 |
Go GMP 模型 |
| 线程模型 |
1:1 (Java 线程 = 内核线程) |
M:N (Goroutine 多对多内核线程) |
| 调度器 |
操作系统内核调度 |
Go 运行时用户态调度 |
| 线程栈 |
~1MB (固定) |
~2KB (动态伸缩) |
| 切换开销 |
高 (内核态切换) |
低 (用户态切换) |
| 最大并发 |
几千个 |
百万级 |
| 阻塞行为 |
阻塞内核线程 |
阻塞时自动切换 G |
┌─────────────────────────────────────────────────────────────┐
│ 模型对比图 │
│ │
│ Java 线程池 (1:1) Go GMP (M:N) │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ Java 线程 1│ ◄──────────────► │ 内核线程 M1 │ │
│ └──────────┘ 1:1 │ (OS Thread) │ │
│ ┌──────────┐ ├──────────────────┤ │
│ │ Java 线程 2│ ◄──────────────► │ 内核线程 M2 │ │
│ └──────────┘ └──────────────────┘ │
│ ▲ │
│ │ M:N 映射 │
│ ┌──────┴──────┐ │
│ │ G1 G2 G3 │ │
│ │ Goroutine │ │
│ └─────────────┘ │
│ │
│ Java: 简单直接，但资源消耗大 │
│ Go: 高效轻量，但调度复杂 │
└─────────────────────────────────────────────────────────────┘
二、Go GMP 模型详解
1. GMP 三个核心组件
| 组件 |
全称 |
说明 |
| G |
Goroutine |
用户态协程，包含栈、指令指针、状态 |
| M |
Machine |
内核线程，执行 G 的载体 |
| P |
Processor |
逻辑处理器，管理 G 的调度和资源 |
┌─────────────────────────────────────────────────────────────┐
│ GMP 架构 │
│ │
│ G (Goroutine) P (Processor) M (Machine) │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ G1 │ ──┐ │ P1 │ ──┐ │ M1 │ │
│ ├──────┤ │ ├──────┤ │ ├──────┤ │
│ │ G2 │ ──┼──► Local Queue │ │ OS │ │
│ ├──────┤ │ ├──────┤ │ │ Thread│ │
│ │ G3 │ ──┘ │ P2 │ ──┼──► │ M2 │ │
│ └──────┘ ├──────┤ │ ├──────┤ │
│ ▲ │Global Queue│ │ OS │ │
│ │ └──────┘ │ │ Thread│ │
│ │ │ └──────┘ │
│ └────────── 调度器管理 ──────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
2. 调度流程
┌─────────────────────────────────────────────────────────────┐
│ GMP 调度流程 │
│ │
│ 1. 创建 G ──► 放入 P 的本地队列 │
│ │ │
│ ▼ │
│ 2. M1 获取 P ──► 从 P 的本地队列获取 G 执行 │
│ │ │
│ ▼ │
│ 3. G 阻塞 (如 IO) ──► M1 和 P 分离 ──►M2 获取 P 继续执行 │
│ │ │
│ ▼ │
│ 4. G 就绪──► M1尝试绑定空闲P队列，若无空闲P，则将G放入全局队列， │
再偷取其他 P 的G │
│ │
└─────────────────────────────────────────────────────────────┘
详情如下图所示：
3. 关键特性
| 特性 |
说明 |
| 工作窃取 |
P 本地队列空时，从其他 P 偷 G 执行 |
| 手递手 |
G 阻塞时，M 将 P 交给其他 M 使用 |
| 抢占式调度 |
基于协作 + 信号抢占，防止长任务阻塞 |
| 网络轮询器 |
网络 IO 阻塞时，G 挂起，M 不阻塞 |
三、Java 线程池详解
1. 核心组件
ThreadPoolExecutor(
int corePoolSize, // 核心线程数
int maximumPoolSize, // 最大线程数
long keepAliveTime, // 空闲线程存活时间
TimeUnit unit, // 时间单位
BlockingQueue<Runnable> workQueue, // 任务队列
ThreadFactory threadFactory, // 线程工厂
RejectedExecutionHandler handler // 拒绝策略
)
2. 任务提交流程
┌─────────────────────────────────────────────────────────────┐
│ Java 线程池任务流程 │
│ │
│ 提交任务 │
│ │ │
│ ▼ │
│ 核心线程数满了吗？──否──► 创建新核心线程执行 │
│ │是 │
│ ▼ │
│ 任务队列满了吗？──否──► 放入队列等待 │
│ │是 │
│ ▼ │
│ 最大线程数满了吗？──否──► 创建非核心线程执行 │
│ │是 │
│ ▼ │
│ 执行拒绝策略 (Abort/CallerRuns/Discard) │
│ │
└─────────────────────────────────────────────────────────────┘
四、详细对比表
| 维度 |
Java 线程池 |
Go GMP |
| 并发模型 |
1:1 (线程=内核线程) |
M:N (协程：内核线程) |
| 调度器位置 |
操作系统内核 |
Go 运行时 (用户态) |
| 栈大小 |
1MB (固定，可配置) |
2KB (动态伸缩) |
| 创建开销 |
高 (系统调用) |
低 (用户态分配) |
| 切换开销 |
~1-5μs (内核切换) |
~200ns (用户态切换) |
| 最大并发数 |
几千 (受内存限制) |
百万级 |
| 阻塞处理 |
阻塞内核线程 |
G 挂起，M 继续执行其他 G |
| IO 模型 |
阻塞 IO / NIO |
非阻塞 IO + 网络轮询器 |
| 内存占用 |
高 (每线程 1MB) |
低 (每 G 2KB) |
| 调试难度 |
较低 (成熟工具) |
较高 (需理解 GMP) |
| 适用场景 |
CPU 密集型、企业应用 |
高并发 IO、网络服务 |
五、代码对比
Java 线程池示例
// 创建线程池
ExecutorService pool = new ThreadPoolExecutor(
10, // 核心线程
100, // 最大线程
60, TimeUnit.SECONDS, // 空闲存活
new LinkedBlockingQueue<>(1000), // 任务队列
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.CallerRunsPolicy()
);
// 提交任务
pool.submit(() -> {
// 业务逻辑
System.out.println("Task executed by " + Thread.currentThread().getName());
});
// 关闭
pool.shutdown();
Go GMP 示例
// 创建 Goroutine (自动使用 GMP 调度)
for i := 0; i < 1000; i++ {
go func(id int) {
// 业务逻辑
fmt.Printf("Task %d executed\n", id)
}(i)
}
// 等待完成
var wg sync.WaitGroup
wg.Add(1000)
for i := 0; i < 1000; i++ {
go func(id int) {
defer wg.Done()
// 业务逻辑
}(i)
}
wg.Wait()
// 无需手动管理线程池，GMP 自动调度
六、性能对比测试
场景：10 万并发任务
| 指标 |
Java 线程池 |
Go GMP |
| 内存占用 |
~100GB |
~500MB |
| 创建时间 |
~10 秒 |
~0.1 秒 |
| 上下文切换 |
频繁 (内核) |
少量 (用户态) |
| 吞吐量 |
受线程数限制 |
高 |
| 可行性 |
不可行 (OOM) |
轻松支持 |
场景：100 并发 CPU 密集型
| 指标 |
Java 线程池 |
Go GMP |
| CPU 利用率 |
~100% |
~100% |
| 执行时间 |
相当 |
相当 |
| 推荐度 |
✅ 适合 |
✅ 适合 |
七、阻塞行为对比
Java 线程池阻塞
┌─────────────────────────────────────────────────────────────┐
│ Java 线程阻塞 │
│ │
│ 线程 1 ──► 执行任务 ──► IO 阻塞 ──► 内核线程阻塞 │
│ │ │ │
│ ▼ ▼ │
│ CPU 闲置 资源浪费 │
│ │
│ ❌ 阻塞一个线程 = 浪费一个内核线程资源 │
└─────────────────────────────────────────────────────────────┘
Go GMP 阻塞
┌─────────────────────────────────────────────────────────────┐
│ Go GMP 阻塞处理 │
│ │
│ G1 ──► 执行 ──► IO 阻塞 ──► G1 挂起 │
│ │ │
│ ▼ │
│ M1 ──► 分离 P ──► 获取新 P ──► 执行 G2 │
│ │
│ ✅ G 阻塞不影响 M，M 继续执行其他 G │
└─────────────────────────────────────────────────────────────┘
八、选择建议
| 场景 |
推荐方案 |
理由 |
| 高并发 IO |
Go GMP |
轻量、高效、自动调度 |
| CPU 密集型 |
Java 线程池 |
两者相当，Java 生态更成熟 |
| 企业应用 |
Java 线程池 |
生态完善、工具丰富 |
| 微服务/网关 |
Go GMP |
高并发、低延迟 |
| 大数据处理 |
Java 线程池 |
Hadoop/Spark 生态 |
| 实时通信 |
Go GMP |
连接数多、资源占用低 |
九、Java 21 虚拟线程（新变量）
Java 21 引入 虚拟线程 (Virtual Threads)，接近 Go GMP 模型：
// 传统线程池
ExecutorService pool = Executors.newFixedThreadPool(100);
// 虚拟线程 (Java 21+)
ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor();
| 特性 |
传统线程池 |
虚拟线程 |
Go GMP |
| 模型 |
1:1 |
M:N |
M:N |
| 栈大小 |
1MB |
动态 |
2KB |
| 调度器 |
内核 |
JVM |
Go 运行时 |
| 成熟度 |
成熟 |
新 |
成熟 |
十、总结
| 维度 |
Java 线程池 |
Go GMP |
| 核心优势 |
生态成熟、工具完善 |
高并发、低资源 |
| 核心劣势 |
资源消耗大、并发受限 |
调试复杂、生态较小 |
| 最佳场景 |
企业应用、CPU 密集 |
网络服务、高并发 IO |
| 学习曲线 |
低 |
中 |
Java 线程池是 1:1 内核线程模型，简单直接但资源消耗大；Go GMP 是 M:N 用户态调度模型，高效轻量但复杂度高。选择取决于应用场景：高并发 IO 选 Go，企业应用选 Java。Java 21 虚拟线程正在缩小两者差距。
简单记忆：Java 线程池 = heavyweight 内核线程，Go GMP = lightweight 用户态协程