并发编程解决多线程共享状态一致性问题，依赖Thread、锁、原子类等机制；异步编程聚焦非阻塞等待，依托回调、Future、响应式流实现任务调度。两者目标不同：并发重安全并行，异步重线程复用。
并发编程关注线程协作与资源竞争
Java并发编程本质是解决多线程环境下共享状态的一致性问题。它不等于“多个任务同时运行”，而是围绕 Thread、synchronized、ReentrantLock、AtomicInteger、ConcurrentHashMap 等机制，控制对临界资源的访问顺序和可见性。
典型场景包括：高并发订单扣减、缓存预热时的双重检查锁、生产者-消费者模型中的队列协调。常见错误现象是 ConcurrentModificationException 或数据丢失——比如两个线程同时执行 counter++ 却只加了一次。
- 必须显式处理线程生命周期（
start()/join()）、中断（interrupt()）和异常传播 -
ExecutorService是推荐入口，但提交的Runnable或Callable仍需自行管理共享变量 - 过度使用锁会导致吞吐下降；用错
volatile（比如用于非原子复合操作）反而掩盖问题
异步编程关注任务调度与非阻塞等待
Java异步编程的核心是“不等结果，先干别的”，重点在避免线程因 I/O 或远程调用空转。它依赖回调、Future 或响应式流抽象，典型实现有 CompletableFuture、CompletableStage、Spring WebFlux 的 Mono/Flux，以及底层的 Selector 和 Netty 事件循环。
典型场景包括：HTTP客户端并发请求多个微服务、文件上传后触发多个异步校验、定时任务中混合数据库查询与邮件发送。常见错误是 CompletableFuture.get() 在主线程阻塞，把异步写成了同步；或忘记用 exceptionally() 处理链路异常导致静默失败。
-
CompletableFuture.supplyAsync()默认用ForkJoinPool.commonPool()，CPU密集型任务应传入自定义线程池 - 链式调用如
thenApply()默认在前一个阶段完成的线程上执行，跨线程需显式指定thenApplyAsync() - WebFlux 中
block()是反模式，仅限测试或启动逻辑中极少数必要场景
两者常混用但目标不同：并发 ≠ 异步
一个 HTTP 接口内部既可能用 ExecutorService 并发查多个 DB 表（并发编程），又用 WebClient 异步调第三方 API（异步编程）。前者解决“怎么安全地并行干活”，后者解决“怎么不卡住线程等别人干活”。
容易混淆的点在于：都用了多线程，但动机完全不同。比如 parallelStream() 是并发（内部用 ForkJoinPool 拆分集合并行处理），而 CompletableFuture.runAsync() 是异步（把任务扔给线程池后立即返回，不关心何时完成）。
- 并发编程中线程常长期存活，反复处理任务；异步编程中线程更倾向短生命周期，靠事件驱动复用
- 阻塞式 JDBC 驱动无法真正异步，即使包装成
CompletableFuture，也只是把阻塞转移到了线程池里 - Project Reactor 的
publishOn()和subscribeOn()区分的是“谁执行”和“在哪执行”，不是并发控制语义
选型关键看瓶颈类型而非技术时髦度
如果系统瓶颈在 CPU（如图像批量处理），优先考虑并发编程 + 合理线程数；如果瓶颈在网络/磁盘 I/O（如网关聚合多个下游接口），异步编程才能释放线程资源。强行用 CompletableFuture 改写纯计算逻辑，只会增加调度开销。
Spring Boot 2.0+ 默认 WebMvc 是同步阻塞模型，WebFlux 才是响应式异步模型——但切换 WebFlux 不代表自动获得性能提升，还要求数据库驱动、缓存客户端、消息中间件全链路支持非阻塞。
- 排查工具要匹配：并发问题看
jstack线程栈和VisualVM锁竞争；异步问题看reactor-tools的调试钩子或日志中的线程名（如parallel-1vshttp-nio-8080-exec）
-5 - 单元测试写法差异大：
CountDownLatch等待并发结果；StepVerifier验证响应式流行为 - 最易被忽略的是错误传播路径：并发中未捕获异常会杀死线程；异步中未声明
handle()或whenComplete()可能导致异常丢失
-5