启动一个 java -jar app.jar 创建1个JVM进程，其内部默认至少有2个线程：主线程和JVM守护线程；所有 new Thread().start() 均在该进程内创建线程，不产生新进程。
Java里启动一个main方法，到底创建了几个进程和线程？
直接说结论：启动一个 java -jar app.jar，操作系统会创建1个JVM进程；这个进程内部默认至少有2个线程——主线程（执行 main() 方法的那个）和守护线程（如 Reference Handler、Finalizer 等 JVM 自带线程）。
你写的每个 new Thread(...).start() 或 ExecutorService.submit()，都只是在当前 JVM 进程内新增线程，不会产生新进程。这点非常关键——很多初学者误以为“多线程 = 多进程”，结果在调试时发现 kill 掉一个线程整个应用就挂了，就是没意识到线程崩溃会拖垮整个进程。
为什么不能用多进程替代多线程来处理并发任务？
Java 中极少手动 fork 新进程（比如调用 Runtime.getRuntime().exec()），因为代价太高：
- 每次
exec()都要加载完整 JVM，内存开销动辄 50MB+，启动耗时几十到几百毫秒 - 父子进程间通信必须走 IPC（如管道、Socket、文件），无法直接读写对方堆内存，代码复杂度飙升
- 无法共享 Spring Bean、数据库连接池、静态变量等运行时上下文，相当于“重启半个系统”
- JVM 的 GC、JIT 编译、类加载器等机制都是进程级的，跨进程就全失效
所以真实业务中：同一服务内高并发请求 → 用线程池（ThreadPoolExecutor）；不同服务解耦 → 用微服务（独立 JVM 进程）。
线程崩溃真的会让整个进程退出吗？
不一定，但风险极高——取决于崩溃类型和 JVM 设置：
-
OutOfMemoryError: Java heap space：整个 JVM 进程会卡死或直接退出（取决于 GC 策略和是否配置了-XX:+ExitOnOutOfMemoryError） - 未捕获的
RuntimeException（如NullPointerException）：只终止当前线程，主线程和其他线程照常运行（但可能因共享状态错乱导致后续异常） - 调用
System.exit()或触发kill -9：直接终结整个 JVM 进程 - 本地方法崩溃（JNI）：大概率导致 JVM 进程 segfault，无任何恢复机会
因此生产环境必须做两件事：① 给所有线程设置 Thread.setDefaultUncaughtExceptionHandler；② 关键线程用 try-catch 包裹顶层 run() 逻辑，避免静默失败。
如何验证当前 JVM 进程里有多少线程？
别只看 jps 或任务管理器——它们只显示进程。真正要看线程数，用这些方式：
- 命令行实时查看：
jstack| grep "java.lang.Thread" | wc -l
（注意：jstack 输出含注释，更准的是
jstack）| grep "tid=" | wc -l - 代码中获取：
ManagementFactory.getThreadMXBean().getThreadCount()（返回当前活跃线程数） - JConsole / VisualVM 连接后，在“Threads”页签直观看到所有线程名、状态、栈帧
特别提醒：Thread.activeCount() 返回的是当前线程所在线程组的**估算值**，不准，别用于监控告警。
最易被忽略的一点：线程不是越多越好。当线程数超过 CPU 核心数太多（比如 200 个线程跑在 4 核机器上），大量时间花在上下文切换和锁竞争上，吞吐反而断崖下跌。压测前务必确认线程池核心数、队列容量、拒绝策略是否匹配实际 IO/CPU 密集型特征。
