技术博客

在Java并发编程中，volatile是一个既强大又容易被误用的关键字。它像一把轻巧的锁，提供了比synchronized更低的开销，但适用场景也更为受限。《Java并发编程实战》一书为我们指明了方向，提出了使用volatile必须同时满足的三个条件。 然而，原书中的表述对于初学者来说可能有些晦涩。本文旨在用最通俗的语言和最直观的代码，带你彻底搞懂volatile的正确用法。 核心回顾：volatile的作用 在深入探讨之前，我们先快速回顾一下volatile的两个核心作用： 可见性（Visibility）: 当一个线程修改了volatile变量的值，这个新值对其他线程是立即可见的。它通过防止编译器和CPU的指令重排序、并确保修改后的值立即写回主内存来实现。 有序性（Ordering）:...

你是否遇到过这样的场景：你正在学习《Java并发编程实战》这样的经典书籍，满怀期待地将一个“会出错”的并发示例代码在自己的电脑上运行时，却发现……它每次都能完美运行！书上言之凿凿的无限循环、数据错乱等问题，在你强大的 i7/i9 处理器和最新的IDE面前，消失得无影无踪。 这究竟是书本理论过时了，还是我们的认知出现了偏差？ 本文将以《Java并发编程实战》中经典的 NoVisibility 程序清单为例，深入探讨这个现象。这不仅是一个关于代码的问题，更是一次深入理解Java内存模型（JMM）、指令重排序和内存可见性的绝佳机会。 梦开始的地方：经典的 NoVisibility让我们先回顾一下这段经典的代码： 1234567891011121314151617181920// 程序清单3-1 from "Java Concurrency in Practice"public class NoVisibility { private static boolean ready; private static int number; ...

初学Java并发编程，如何看懂“锁重入”？一篇“慢动作”分解带你入门初学Java并发编程的你，是否也曾对着下面这段经典代码感到困惑？ 这段代码出自《Java并发编程实战》一书，它通过一个子类继承父类并调用父类同步方法的例子，引出了“锁重入”的概念。但很多开发者第一次看到时，都会有一个共同的疑问：重入到底发生在哪里了？我怎么没看见？ 别担心，这篇博文将用“慢动作”分解的方式，带你彻底看清这个“看不见”却至关重要的概念。 一、令人困惑的经典代码首先，让我们回顾一下这段代码： 12345678910111213// 程序清单 2-7public class Widget { public synchronized void doSomething() { // ... }}public class LoggingWidget extends Widget { public synchronized void doSomething() { ...

...

我们经常听到一个说法：“我的应用变慢了，加点线程吧！”。在多核心CPU普及的今天，“多线程”似乎成了提升性能的万能药。然而，它真的是吗？ 这篇博文的目的，是带你暂时忘掉 Thread, Runnable, ExecutorService 这些熟悉的API，戴上一副特殊的“眼镜”，从计算机最核心的部件——CPU的视角，去重新审视我们习以为常的多线程世界。你会发现，我们追求的从来不是“更多的线程”，而是一种更高效的“工作模式”。 第一章：CPU眼中的两种“工作”——计算与等待想象一下你是CPU，是这个系统里唯一真正能“思考”和“执行”的角色。交到你手上的任务，在你看来，只有两种截然不同的性质： CPU密集型任务 (CPU-Bound) 这是什么？ 这类任务需要你持续不断地进行高速计算。比如：视频编码、大规模数据排序、复杂的科学计算。 你的状态： “全神贯注”。你的计算单元在满负荷运转，几乎没有喘息之机。 类比： 一位数学家，拿着纸笔，在一间安静的房间里，心无旁骛地推导一个复杂的公式。整个过程，他都在思考和书写，没有停顿。 I/O密集型任务...

在现代Java应用中，CompletableFuture 是构建响应式、高吞吐量系统的利器。然而，许多开发者在使用其强大的链式调用功能时，常常在 thenApply 和 thenCompose 之间感到困惑。这不仅仅是API选择的问题，错误的选用可能导致系统在并发压力下性能断崖式下跌。 本文的目标，不仅仅是告诉你“何时用哪个”，而是要带你深入问题的本质： 核心误区：我们通常认为的“线程在等待”，究竟是一种怎样的状态？ 底层原理：CompletableFuture...

在学习和使用 Java 的 CompletableFuture 进行异步编程时，很多开发者都可能遇到一个令人困惑的场景：在 main 方法中满怀信心地提交了一个耗时任务，结果程序一闪而过，预期的异步结果却迟迟没有出现。这背后究竟隐藏着什么秘密？ 本文将从一个典型的“踩坑”案例出发，层层深入，为您揭示 CompletableFuture 与 JVM 线程模型之间的微妙关系，并最终给出一套健壮的解决方案。 现象：一闪而过的异步任务让我们从一个常见的场景开始：异步查询用户信息，然后根据结果发送短信。 场景描述: 异步执行一个模拟的耗时操作（比如查询用户手机号，耗时3秒）。 操作成功后，获取结果（手机号）。 使用该结果执行下一步操作（发送短信）。 初始代码： 123456789101112131415161718192021222324252627282930313233import java.util.concurrent.CompletableFuture;import java.util.concurrent.TimeUnit;public class...

在Java 8之前，进行异步编程通常意味着与Future接口和回调函数打交道，这往往会导致代码结构复杂，难以维护，即所谓的“回调地狱”。Java 8引入的CompletableFuture彻底改变了这一局面，它不仅提供了强大的异步编程能力，更带来了一种流式、声明式的编程范式。 本文将深入探讨CompletableFuture的核心优势，通过与传统多线程写法的对比，揭示其解决了哪些痛点。同时，我们也会剖析它的能力边界，明确在现代并发编程中，哪些职责仍需我们亲力亲为。 场景引入：构建一个聚合页面假设我们正在开发一个电商应用的首页，需要同时异步加载三部分数据： 获取用户信息 获取推荐商品列表（独立任务） 获取用户订单列表（依赖用户信息） 最后，将这三部分数据聚合起来展示。这个场景包含了并行和串行依赖，是检验异步编程模型的绝佳试金石。 一、传统方式的挣扎：ExecutorService 与...

在 Java 异步编程的世界里，CompletableFuture 是一个无法绕开的强大工具。当我们启动一个异步任务后，最终总要获取它的结果。这时，join() 和 get() 两个方法就登场了。它们都能阻塞当前线程直到异步任务完成并返回结果，但它们之间存在一个关键且重要的区别，这个区别直接影响了代码的简洁性和使用场景。 一言以蔽之：get() 抛出受检异常，join() 抛出非受检异常。 让我们深入探讨这个核心差异。 1. 核心区别：异常处理机制get() 方法：传统的异常处理get() 方法继承自 java.util.concurrent.Future 接口，它的设计遵循了 Java 传统的异常处理模型，即抛出受检异常（Checked Exceptions）。这意味着当你调用 get() 时，编译器会强制你处理两种可能发生的异常： ExecutionException: 如果异步任务在执行过程中内部抛出了异常，这个异常会被包装在 ExecutionException 中抛出。你需要通过 e.getCause()...

1. 为什么需要 CompletableFuture？在 CompletableFuture 出现之前，Java 5 引入了 Future 接口，用于表示一个异步计算的结果。但 Future 的能力非常有限： 无法主动完成：你无法手动将一个 Future 标记为已完成，并设置其结果。它只能被动地等待执行它的线程完成任务。 阻塞式获取结果：future.get() 方法是阻塞的，调用时会暂停当前线程，直到异步任务完成。这违背了异步编程的初衷。 没有回调机制：你无法在 Future 完成时自动触发某个动作（回调函数），只能通过循环调用 isDone() 来检查，或者直接阻塞在 get() 上。 无法组合：你很难将多个 Future 串联起来，例如当一个 Future 完成后，用其结果去执行另一个异步任务。 CompletableFuture 扩展了 Future 接口，并实现了 CompletionStage 接口，彻底解决了以上痛点。它为异步编程提供了一种功能强大、非阻塞、可组合的范式，是现代 Java 异步编程的基石。 核心思想：CompletableFuture...