并发是程序能同时管理多个任务，即使单核也靠时间片切换实现；并行需多核硬件支持，真正物理同时执行。Java中应优先用ExecutorService线程池而非裸Thread，并注意parallelStream()共享ForkJoinPool的风险。
并发是“能管多个任务”，并行是“真能同时干”
Java里说的并发（Concurrency），不是指CPU真在同时跑多个线程，而是指程序具备**同时管理多个任务的能力**——哪怕只有一个CPU核心，也能靠快速切换（比如每10ms切一次）让多个任务轮流执行，看起来像在“一起动”。并行（Parallelism）则必须有硬件支撑：多核CPU、或多台机器，让不同线程**物理上同一时刻运行在不同核心上**。
常见错误现象：Thread.sleep(1) 后发现两个线程输出依然交错，就以为“没并发”；其实这恰恰是并发的典型表现——单核下靠调度器切任务，不是bug，是设计使然。
- 适用场景：I/O密集型任务（如HTTP请求、文件读写）优先用并发，避免CPU空等
- 适用场景：CPU密集型任务（如图像缩放、数值计算）才值得拆成并行子任务
- 性能影响：盲目开100个线程做计算，在4核机器上反而因上下文切换拖慢整体速度
Java中怎么写出并发代码？别只new Thread()
最基础的并发实现是启动多个Thread，但实际项目里几乎不用裸写Thread——它难控、易泄漏、不复用。真正该用的是ExecutorService线程池。
例如：Executors.newFixedThreadPool(4) 创建固定4线程池，比手动new Thread().start() 更安全，还能统一管理生命周期。
立即学习“Java免费学习笔记（深入）”；
- 容易踩的坑：用
Executors.newCachedThreadPool()处理不可控的请求量，可能导致OOM（线程数无限增长） - 参数差异：
corePoolSize决定常驻线程数，maximumPoolSize是峰值上限，两者差值由队列容量和拒绝策略共同约束 - 兼容性注意：Java 21+ 推荐用
StructuredTaskScope替代传统线程池做短生命周期协作任务
并行流parallelStream()不是银弹
list.parallelStream().map(...).filter(...).collect(...) 看似一行搞定并行，但它底层依赖ForkJoinPool.commonPool()，而这个公共池是全JVM共享的——如果某段代码耗尽了它的线程，其他模块（比如CompletableFuture默认也用它）就会卡住。
- 使用场景：数据量大（>10万元素）、操作无状态且无IO（比如纯数学变换）时收益明显
- 危险操作：在
parallelStream()里调用System.out.println()或写数据库，可能引发竞态或连接池枯竭 - 替代方案：明确指定自定义
ForkJoinPool，或改用CompletableFuture.supplyAsync(..., executor)控制线程来源
并发 ≠ 线程安全，别把Runnable当护身符
很多人以为“用了多线程就是并发编程”，结果共享变量出问题：两个线程同时对int count = 0执行count++，最后不是2而是1——因为count++不是原子操作（读-改-写三步）。
关键点在于：并发只是让多个任务“能一起跑”，但**共享资源的访问控制要另外加锁或用原子类**。
- 常见错误：用
ArrayList存并发产生的日志，没加锁也没换CopyOnWriteArrayList，导致ConcurrentModificationException - 正确姿势：计数用
AtomicInteger，集合用ConcurrentHashMap，临界区用synchronized或ReentrantLock - 容易被忽略：即使用了
volatile修饰变量，也不能保证复合操作（如if (flag) doSomething()）的原子性
