Java中没有多进程编程，只有单JVM进程；多线程共享内存与资源，故障不隔离；真需多进程须用ProcessBuilder或Runtime.exec()启动新JVM实例。
Java里没有“多进程编程”这回事——java -jar app.jar 启动的永远是**1个JVM进程**，里面跑再多 new Thread().start() 也还是这一个进程；真要搞多进程，得靠 ProcessBuilder 或 Runtime.exec() 去调操作系统命令，自己拉起另一个 JVM 实例。
Java中线程和进程的资源归属完全不同
进程是操作系统分配资源的最小单位，有独立内存空间、文件描述符、PID；线程只是 CPU 调度的基本单位，必须依附于进程存在。JVM 进程启动后，默认至少含两个线程：main 线程（执行你的 main() 方法）和若干 JVM 守护线程（如 Reference Handler、Finalizer），它们共享堆、方法区、已加载类等资源。
- 你写的每个
new Thread().start()，只在当前 JVM 进程内新增栈空间和线程控制块（TCB），不申请新地址空间、不触发 fork 系统调用 - 一旦某个线程因未捕获异常崩溃（比如
NullPointerException在后台线程抛出），整个 JVM 进程会退出——因为线程不是隔离容器，而是共享生命体 - 想验证？用
jps -l查看 Java 进程数，再用jstack看线程列表：你会发现几十上百个线程都挤在一个 PID 下
为什么不能用多线程替代多进程来隔离故障
多线程共享堆内存，意味着一个线程把 static Map 搞乱了，所有线程都会读到脏数据；而多进程天然内存隔离，A 进程 OOM 不影响 B 进程运行。
- 典型踩坑场景：用线程池处理用户上传的脚本（如 Groovy/JSR-223），若脚本死循环或内存泄漏，整个服务不可用；换成
ProcessBuilder启动独立 JVM 执行，超时可destroyForcibly()杀掉，主服务稳如泰山 - Java 本身不提供进程间共享内存或信号量机制，IPC 得靠文件、Socket、Pipe 或第三方库（如 Chronicle Queue）
-
ProcessBuilder启动子进程时，父子进程默认不共享标准输入输出流，需显式重定向（redirectInput()/redirectOutput()）才能通信
创建开销和上下文切换的实际差距
线程创建快，但不代表“随便开”。Linux 下 pthread_create() 约耗时 300 微秒，而 fork() + exec() 组合通常要 2000+ 微秒；但线程上下文切换（约 300 微秒）比进程切换（约 2000 微秒）轻量得多——这是高并发 I/O 场景选线程、稳定性敏感场景选进程的根本依据。
立即学习“Java免费学习笔记（深入）”；
- Web 服务器用线程池处理 HTTP 请求：连接多、计算少、需共享 session/cache → 线程高效
- 批处理任务调度系统：不同客户脚本互不信任、需硬性资源限制（CPU 时间、内存上限）→ 必须用进程隔离
- JVM 默认栈大小是 1MB（64 位 Linux），开 1000 个线程 ≈ 占用 1GB 栈内存，容易触发
OutOfMemoryError: unable to create new native thread
ProcessBuilder pb = new ProcessBuilder("java", "-cp", "lib/*", "com.example.SandboxRunner", "script.groovy");
pb.redirectOutput(ProcessBuilder.Redirect.INHERIT); // 复用父进程 stdout
pb.redirectErrorStream(true);
try {
Process p = pb.start();
boolean finished = p.waitFor(30, TimeUnit.SECONDS);
if (!finished) {
p.destroyForcibly(); // 强制终止，避免僵尸进程
}
} catch (Exception e) {
e.printStackTrace();
}
真正麻烦的从来不是“怎么写”，而是“什么时候不该用线程”——比如你正在写一个插件沙箱、用户代码执行器、或者需要 cgroup 限频限存的服务，这时候还执着于 ExecutorService，就等于把所有鸡蛋放在一个篮子里，还嫌篮子不够结实。
