汪文君是汇丰软件（广东）研发中心的数据服务中心技术经理和技术专家。他目前的工作重心在于实时数据data pipeline平台的建设和架构设计。在加入汇丰之前，他拥有超过7年的移动通信行业经验，并且在移动互联网、云计算以及B2C电子商务平台的开发和架构方面也有深厚造诣。汪文君热衷于技术知识的分享与技术细节的打磨，他已经录制了十几套技术视频，这些内容在网络上广为传播。

线程是程序执行的独立路径，每个线程有自己的局部变量和生命周期。在Java编程中，我们通过JVM创建多个线程，包括主线程和其他自定义线程。初始示例展示了如何并行执行两个任务，但发现它们并未真正并发，因为主线程的无限循环阻止了新线程的启动。修正后的代码利用匿名内部类创建线程并调用start方法，实现了听音乐和看新闻的交替输出。

Java中的Thread类提供了start方法来启动线程。start方法会检查线程状态，确保线程未被启动或已终止，并将线程加入到ThreadGroup中。如果线程已被启动或处于终止状态，它会抛出异常。实际的run方法是在JNI方法start0中由JVM调用执行的。通过示例代码展示了重复启动线程和试图重新激活已结束生命周期线程的不同结果。

Thread类中的run方法与Runnable接口密切相关。Runnable接口允许我们将线程控制逻辑和业务逻辑分离，提供更灵活、安全的多线程编程方式。模板设计模式在Thread中有所应用，例如模拟营业大厅叫号机程序时，可以使用Thread类来实现这一功能。

然而，在多线程环境下，票号分配问题可能会出现号码重复的情况。初始代码中，每个TicketWindow线程独立计数票号，导致了这个问题。通过将index变量设为静态，确保了在多个线程间票号的唯一性。但这种方法对于共享资源较多或计算复杂的场景不适用。相比之下，使用Runnable接口创建线程能更好地处理这类问题，因为它更容易实现线程间的同步和资源保护。

多线程编程的核心概念包括线程的生命周期、线程安全以及如何使用Thread类和Runnable接口来创建并执行任务。理解线程生命周期有助于我们掌握线程同步和阻塞机制，这对于解决共享资源问题至关重要。例如，在一个有四个窗口（线程）的场景中，确保每个窗口正确地访问和修改共享资源是至关重要的。

总之，Java中的多线程编程涉及到线程的创建、执行以及管理。通过使用Thread类或Runnable接口，我们可以实现并行任务处理，并通过理解线程生命周期来优化同步和阻塞策略，保证在多线程环境中数据的一致性和完整性。

第1章 快速认识线程

线程命名对于问题排查和跟踪至关重要。系统默认为未命名的线程赋予"Thread-"前缀与自增数字作为名称。建议为线程指定有含义的名字，如使用"ALEX-"加编号。线程启动前可修改名称，但运行后则不可更改。每个线程都有一个父线程，通常是创建它的线程本身。线程可以被组织到ThreadGroup中，若无特别设定，子线程会默认加入父线程所在的组。

线程和线程组是Java并发编程的基础概念。main线程属于名为"main"的ThreadGroup。新线程除非指定，否则与父线程同属一个ThreadGroup。Thread类构造函数中的stackSize参数影响线程栈大小，进而限制递归深度或并发数量。然而，通常无需手动设置stackSize，而是通过系统参数xss控制。

JVM内存结构包括虚拟机栈、程序计数器、本地方法栈、堆内存和方法区。其中，虚拟机栈是线程私有的，存储执行方法所需信息如局部变量、操作栈等。其大小由-xss参数设定。随着栈内存增大，可容纳的栈帧增多，但创建的线程数量减少，因为每个线程需要独立的栈空间。堆内存作为共享区域，存放所有对象，影响进程总内存和线程数量。

JDK1.8后，持久代被元空间取代，作为堆的一部分存储类的元数据。每个类加载器有独立的线性分配内存区域。与JDK1.7相比，1.8中已无持久代，而是元空间。线程与虚拟机栈的关系在于，栈内存大小直接限制线程创建数量。

Java程序执行时，内存分布受线程影响，特别是虚拟机栈。它存储方法执行所需信息，其大小通过-xss参数配置。增大栈内存可容纳更多栈帧，但减少线程数量，因为每个线程需独立栈空间。堆内存作为共享区域，影响进程总内存和线程数量。

进程内存中，堆内存对线程数量的影响不如栈内存明显。JVM中的线程数量受限于堆内存、栈内存大小以及操作系统限制。守护线程是特殊线程，用于后台任务如垃圾回收，当无非守护线程时，JVM通常会退出。

Java中控制线程的方法包括`Thread.sleep`和`TimeUnit`，后者更简洁高效。`Thread.yield`提示当前运行线程放弃CPU资源，但调度器不一定立即执行。`sleep`暂停指定时间，而`yield`仅提供可能的上下文切换点。设置线程优先级虽可行，但受操作系统和系统负载影响，不建议依赖于它进行业务设计。

Java中，线程优先级如t1默认为5，t2设为6，其内部创建的t3继承优先级6。获取线程ID的方法保证全局唯一，即使main函数中的线程ID可能不从0开始。识别当前执行线程和理解线程上下文类加载器的作用也是编程关键。

线程中断机制涉及`interrupt`、`interrupted`和`isInterrupted`方法。当线程执行可中断方法如`sleep`时，捕获到中断信号会清除标志，导致`isInterrupted()`始终返回false。通过`interrupted()`立即清除并判断一次中断状态。未执行可中断方法前设置中断标识，执行后会立即中断。

使用`join`方法能让调用线程等待另一个线程结束或达到指定时间，期间处于阻塞状态。多线程编程中，通过`join`确保执行顺序，如主线程控制两个子线程的执行先后。实际应用中，如航班查询APP，使用`join`处理串行任务局部并行化，提高用户体验。

处理search请求时，主线程创建多个查询线程并行搜索航班信息，最后整合结果。模拟不同航空公司查询时间差异用随机值。关闭线程不推荐使用已弃用的`stop`方法，而应采用正常结束、捕获中断信号或设置volatile开关等方式。示例代码展示了这些安全关闭线程的方法及其实际应用场景。

第2章 深入理解Thread构造函数

在多线程环境下，数据不一致的问题尤为突出。一个生动的例子是营业大厅的叫号机程序：如果没有适当的控制，多个线程同时操作共享变量可能导致号码遗漏、重复或超出最大值。这些问题的根源在于CPU时间片轮询调度和内存模型的复杂性。为解决这些挑战，Java引入了`synchronized`关键字，它提供了一种排他机制，确保同一时刻只有一个线程执行特定代码块或方法，从而保证共享变量的互斥访问，防止数据不一致。

通过修改叫号机程序加入`synchronized`，观察到无论运行多少次，都不会再出现数据不一致的问题。接下来的内容将深入探讨`synchronized`的底层原理和使用细节。例如，如何使用JConsole监控Java虚拟机（JVM）线程，以及在分析过程中可能遇到的情况。

使用JConsole时，首先打开工具并选择要分析的JVM进程，然后连接到该进程进入控制台。在“线程”选项卡中，可以看到大部分线程处于阻塞状态，只有一个线程在等待（sleeping）。通过jstack命令查看线程堆栈信息，可以发现某个线程持有锁并休眠，导致其他线程无法访问资源。这通常会表现为某些线程被阻塞，而其他线程则在等待获取相同的锁。

`synchronized`的使用中需要注意几个陷阱和问题。首先，与monitor关联的对象不能为空，否则会导致错误。其次，synchronized作用域过大会影响效率，应尽量缩小至共享资源的读写范围。此外，不同monitor试图锁定同一方法可能会导致互斥问题，因为monitor锁必须基于相同的引用才能互斥。还有可能因多个锁交叉使用而产生死锁，这可能是由于交叉锁、内存不足、数据交换问题、数据库锁或文件锁等引起的。

Java中`synchronized`的用法可以通过实例来理解。例如，在给定的代码中，有两个静态方法method1和method2，分别被声明为同步方法和同步代码块。当多线程运行时，它们会竞争访问同一monitor（类的Class对象）的锁。通过JStack工具分析线程堆栈信息，可以发现一个线程持有锁并休眠，而另一个线程因尝试获取锁而阻塞。这表明不同静态方法间的同步实际上是共享同一个monitor的锁。

死锁是多线程编程中的另一大挑战。它可能由交叉锁、内存不足、数据交换问题、数据库锁或文件锁等引起。例如，一个示例代码展示了因交叉锁导致的死锁：两个线程分别持有对方需要的锁，导致双方都无法继续执行，从而陷入僵局。

多线程环境下编程的关键在于理解和避免数据不一致与死锁问题。通过合理使用工具如JConsole，以及对`synchronized`和死锁原理的深入理解，开发者可以构建出更为健壮、高效的多线程应用程序。

第4章 线程安全与数据同步

在多线程环境下，消息处理机制对系统性能和并发能力有着显著影响。同步阻塞方式中，客户端会因长时间等待服务器响应而降低系统吞吐量，且频繁创建和销毁线程会导致开销增加。相比之下，异步非阻塞方式允许客户端在提交请求后立即返回，通过服务端的线程池管理和事件队列实现任务异步处理，减少了上下文切换开销。然而，这种方式需要客户端额外查询结果，但能有效避免大量线程带来的性能瓶颈。

EventQueue是多线程环境下实现生产者和消费者通信的一种方式。Producer线程快速提交事件，Consumer线程处理这些事件。当队列满时，Producer会被阻塞；而Consumer处理事件后通过wait和notify机制通知Producer继续提交。需要注意的是，wait和notify方法必须在同步方法中使用，以确保对共享资源的安全访问。wait方法会使调用线程进入等待状态，直到其他线程调用notify或notifyAll唤醒。相比之下，sleep方法会让线程暂停执行一段时间，但不涉及锁的管理。

多线程环境下EventQueue可能存在数据一致性问题。例如，当队列为空时，两个线程同时执行操作可能导致错误；同样，队列元素数量也可能因特定顺序的执行而超过限制。这些问题源于同步机制的不足。为解决这些问题，可以将临界值判断由if语句改为while循环，并使用notifyAll方法来唤醒所有等待的线程。

传统的synchronized关键字在多线程通信中存在缺陷，如无法控制阻塞时长和不可中断性。为了解决这些局限，作者构建了一个自定义显式锁——BooleanLock。该类实现了Lock接口，包含当前持有锁的线程、一个布尔值表示锁状态以及一个阻塞列表用于存储等待锁的线程。lock()方法在同步代码块中实现，若锁已锁定，则调用者线程加入阻塞队列并等待。unlock()方法确保只有加锁的线程可以解锁，并唤醒等待的线程。此外，BooleanLock还提供了lock(long mills)方法，增加了超时功能；当在指定时间内未能获取锁时，会抛出TimeoutException。

通过示例，展示了多个线程如何使用BooleanLock的lock()方法竞争获取锁，确保每次只有一个线程执行同步代码块。同时，讲解了BooleanLock的可中断性，即使主动打断其中一个线程，被中断的线程也会抛出异常，解决了synchronized无法中断的问题。然而，被中断的线程可能还在blockList中，为避免内存泄漏，需要在lock()方法中处理中断情况。

总的来说，异步非阻塞的消息处理机制和自定义显式锁如BooleanLock，都是优化多线程环境下通信效率的有效手段。通过合理使用这些工具，可以提高系统性能、并发能力和数据一致性，解决传统同步机制带来的问题。

第5章 线程间通信

在Java编程中，线程和线程组是两个重要的概念。线程是程序中的一个执行流，而线程组则是对线程的一种组织形式，它允许我们将多个线程归类到一起，以便于管理和控制。默认情况下，新创建的线程会加入到包含main方法的主线程所在的ThreadGroup中。

线程与线程组之间存在着父子关系的结构。当创建一个ThreadGroup时，可以指定它的名称和父线程组。通过代码示例，我们可以看到如何创建不同类型的ThreadGroup，并观察它们之间的继承关系。此外，我们还可以使用ThreadGroup的方法来复制线程和线程组数组，了解这些方法的内部工作原理以及在使用时需要注意的事项。

ThreadGroup的主要作用是对线程进行组织，而非直接管理。它提供了一些基本操作，如activeCount、activeGroupCount等，用于获取线程或子组的状态信息。通过activeCount可以估算group中的活跃线程数，但结果可能不准确；而activeGroupCount则返回的是活跃的子group数量。ThreadGroup还有getName、getParent等方法用于查询组的信息，以及list方法来输出所有活跃线程的信息。

设置线程组的最大优先级时，不能超过其父组的限制，并且改变操作会影响到当前组及其所有子组。例如，可以使用ThreadGroup的方法来设置线程组中的daemon属性为true，当该组内无活跃线程时，整个线程组将自动销毁。这在处理异步任务时非常有用，比如Google Guava库中的EventBus事件处理机制，就利用类似的方式处理subscriber执行任务时可能发生的错误。

Java中提供了UncaughtExceptionHandler接口来处理线程运行时的异常。当线程出现未捕获的异常时，会通过这个接口回调，提供错误信息。我们可以通过`setUncaughtExceptionHandler`和`setDefaultUncaughtExceptionHandler`方法分别设置特定线程或全局的异常处理器，而`getUncaughtExceptionHandler`和`getDefaultUncaughtExceptionHandler`则用于获取对应的异常处理器。

处理线程运行时异常的机制遵循一定的顺序：首先检查该ThreadGroup是否有父组，如果有则调用父组的uncaughtException方法；其次，如果设置了全局默认的UncaughtExceptionHandler，也会执行其uncaughtException方法；若既没有父ThreadGroup，也没有全局默认的Handler，那么异常会直接输出到System.err。

另外，Java还提供了在JVM退出前注入Hook线程的功能。通过Runtime类的`addShutdownHook`方法可以添加一个或多个钩子线程，这些线程会在主应用程序的所有非守护线程结束或者收到系统中断信号时启动。这允许我们在程序关闭之前执行特定任务，比如清理资源、发出警告等。

然而，需要注意的是，如果使用-9参数强制 kill 进程，Hook线程将不会被执行，可能导致资源未释放。因此，在编写Hook线程时应避免进行耗时操作，以确保应用程序能及时退出。在实际开发中，可以利用Hook线程来防止应用程序重复启动，例如在程序启动时创建一个lock文件，当接收到进程中断信号时删除该文件，从而避免了在同一台机器上多次运行同一程序的情况。

总的来说，Java中的线程和线程组提供了强大的工具，帮助我们组织和控制多线程环境下的执行流程。通过理解它们的工作原理和使用方法，我们可以更有效地编写出健壮、高效的并发代码。

第6章 ThreadGroup详细讲解

线程池是一种管理预创建线程的资源池，它允许任务在提交后由池中的某个线程执行。通过一个任务队列来缓冲待处理的任务，并根据配置参数动态调整线程数量，以适应任务量的变化，从而优化系统资源利用。当任务过多，线程池会包含一种拒绝策略，用于决定如何处理无法立即执行的新任务。此外，线程工厂允许定制线程属性，如是否为守护线程和线程名称，进一步增强了线程池的功能。

线程池的实现通常涉及多个类，例如LinkedRunnableQueue和BasicThreadPool。前者是一个存放Runnable任务的队列，通过同步方法offer和take来控制任务的添加和移除。当队列满时，会触发预设的拒绝策略。后者作为线程池的核心，包含初始化线程数量、最大线程数量等属性，并使用ThreadFactory创建线程。它通过RunnableQueue管理任务，同时监控活跃线程数并在需要时进行维护。

线程池的工作流程如下：当一个Runnable任务通过execute方法提交给线程池后，会被放入runnableQueue队列中。线程池内部有一个自维护的线程，负责动态调整线程数量。如果队列中有任务且活动线程少于核心线程数，新线程将被创建；若队列有任务且活动线程少于最大线程数，线程池会继续扩容；反之，如果队列无任务且活动线程超过核心线程数，多余的线程会被销毁。在使用过程中，可以通过观察活跃线程的数量来确认线程池的运行状态。

线程池广泛应用于需要并发执行多个任务的场景，如网络请求、数据库操作或计算密集型任务。尽管可以手动创建一个简单的线程池，但通常推荐使用Java标准库中的ExecutorService，因为它提供了更高级的功能和更好的性能。通过实际示例，可以学习如何从头开始构建一个线程池，这有助于理解其工作原理。然而，这样的自定义实现可能存在一些问题，如继承结构不合理、缺乏任务返回机制或构造函数过多等。鼓励读者尝试优化这些基本的线程池实现，以深化对ExecutorService的理解。

总之，线程池是一种有效的并发处理工具，它通过管理预创建的线程来提高系统资源利用率，并支持动态调整线程数量以适应任务量的变化。理解其工作原理和使用场景，有助于在实际项目中更有效地利用多核处理器的优势。尽管可以手动构建线程池，但标准库提供的ExecutorService通常提供了更好的功能和性能。通过实践和优化自定义实现，可以深化对并发编程的理解。

第8章 线程池原理以及自定义线程池

第一部分 多线程基础

Java中类的生命周期历经加载、连接和初始化三个阶段。加载阶段定位并读取class文件；连接阶段包括验证、准备和解析，确保类文件正确性，分配静态变量内存，转换符号引用为直接引用；初始化阶段赋予静态变量初始值，由主动使用如new对象、访问静态变量或方法触发，被动使用则不触发。验证是加载阶段的关键步骤，旨在确认字节流符合JVM规范，排除安全隐患。

接口方法解析遵循特定规则：在接口方法表中查找class_index中的Simple时，若为类而非接口，返回错误；继续自下而上搜索类方法，直至找到或抛出NoSuchMethodError异常。初始化阶段的核心是执行<clinit>()方法，它由编译器生成，负责所有类变量赋值和静态语句块执行，确保变量初始化顺序，父类的<clinit>()先于子类执行，保证父类静态变量优先赋值。即使没有静态变量或代码块，<clinit>()仍会被生成。

多线程环境下，<clinit>()的同步特性对单例模式采用Holder方式的安全性至关重要。这种同步机制确保在并发场景中，类的初始化过程只被执行一次，避免数据竞争和不一致。通过这些细致的过程控制，Java保证了程序执行的稳定性和正确性。

第9章 类的加载过程

Java虚拟机（JVM）内部存在三种主要的类加载器：根类加载器、扩展类加载器和系统类加载器。根类加载器负责核心库的加载，如java.lang包；扩展类加载器则处理JAVA_HOME下的jre\lib\ext中的类库，其路径可以通过java.ext.dirs属性获取；系统类加载器主要负责classpath下的资源，它继承自扩展类加载器，并可通过java.class.path属性定位。此外，JVM允许用户自定义类加载器以满足特定需求，如OSGI、Tomcat的隔离等。自定义类加载器需继承ClassLoader并实现findClass方法来执行特殊的类加载逻辑。

实现自定义类加载器的过程包括使用defineClass方法定义class，将class文件读入内存，并处理路径转换和异常情况。一个示例是创建了一个名为"My ClassLoader"的基础ClassLoader，它能从磁盘加载class文件。在使用defineClass时，需要注意字节数组可能包含多个类的情况，全限定类名的格式处理也非常重要。

自定义类加载器的使用通常涉及对静态代码块执行的理解。虽然loadClass方法完成了类的加载阶段，但不包括初始化过程，因此静态代码块可能不会立即执行。双亲委托机制在类加载过程中起着关键作用：当一个类需要被加载时，从当前类加载器开始，逐级向上请求父类加载器进行加载。如果所有父级加载器都无法完成任务，当前类加载器会尝试使用自己的findClass方法。这种机制确保了系统类由根加载器负责，而用户定义的类则由相应的类加载器处理。

例如，在多线程环境下，`BrokerDelegateClassLoader`是一个继承自ClassLoader的类，它通过同步和缓存机制保证每个类仅被加载一次。对于以`java.`或`javax.`开头的类，它会委托给系统类加载器；其他类则首先尝试用自己的方式加载，失败后依次请求父类加载器或系统类加载器。如果所有尝试都失败，程序将抛出ClassNotFoundException。此外，该讨论还涉及了类加载器的命名空间概念，表明同一个类加载器实例只会加载同一份类，而不同的类加载器会加载独立的类实例。

JVM中类加载器的工作原理涉及到运行时包的概念。当类被加载时，首先检查缓存中是否存在，若不存在，则进行首次加载。运行时包由类加载器的命名空间和类的全限定名称组成，用于隔离不同类加载器加载的同类实例，以确保安全性和封装性。初始类加载器列表记录了将该类加载器作为父级的所有类，当这些父级被回收或不再需要时，对应的类也会被回收。

为了使用BrokerDelegateClassLoader加载非标准路径下的String.class，可能需要修改源码。然而，即使找到目标class文件，JVM出于安全考虑可能会抛出SecurityException。这种实验主要是为了让读者深入理解Java的类加载机制，而非实际应用场景。

第10章 JVM类加载器

线程上下文类加载器的由来和作用。由于JVM类加载器双亲委托机制的限制，第三方厂商提供的SPI实现无法被根加载器加载。为解决这个问题，JDK引入了线程上下文类加载器，使得子类加载器可以负责加载这些实现，打破了传统的父委托模式。这一设计在处理如JDBC、JNDI等SPI时变得普遍。尽管这种方式存在争议，甚至有人认为它构成了Java设计的一个缺陷，但它确实为应用程序提供了灵活的类加载方式，特别是在处理不同来源的类库时。



第11章 线程上下文类加载器

第二部分 Java ClassLoader

在多线程编程中，volatile关键字扮演着关键角色。它确保所有线程都能看到共享变量的最新状态，避免死锁和数据不一致性问题。当一个线程修改了volatile修饰的变量后，其他线程能立即读取到更新后的值，这得益于Java内存模型（JMM）对内存可见性的保障。JMM规定所有变量存储于主内存，每个线程有自己的工作内存，操作仅限于工作内存中，且线程间不能直接访问对方的工作内存。

尽管volatile提供了可见性，但它并不保证原子性。例如，简单的赋值语句如`y = x`看似原子，但实际涉及从主内存读取、工作内存修改再到主内存刷新的两个步骤，因此非原子操作可能导致数据不一致。为了确保原子性，可以使用`synchronized`关键字或Java Util Concurrency（JUC）包中的锁。

volatile还禁止指令重排序以保证顺序性，但这仅限于对volatile变量的操作。对于其他变量，JMM允许进行指令重排序，这可能影响程序的正确运行。为保证可见性和有序性，Java提供了volatile和synchronized两种机制。volatile用于确保变量即时可见且防止指令重排序，但不提供原子性保障；而synchronized通过锁定对象实现同步，能保证原子性、可见性和有序性，但可能导致线程阻塞。

在设计单例模式时，开发者面临多种选择，如懒汉式加同步、Double-Check、Volatile+Double-Check、Holder方式和枚举方式。懒汉式加同步确保了唯一性，但性能较低；Double-Check允许多线程同时访问，但可能产生空指针异常；volatile关键字在Volatile+Double-Check中防止指令重排序，提供安全的双检查机制；Holder方式利用类加载特性，在程序启动时初始化单例，既安全又高效；枚举方式天然不可继承且线程安全，不过无法实现懒加载。

在实际开发中，作者倾向于选择Holder和枚举方式来设计单例。这些方法结合了内存可见性、顺序性和原子性的保障，同时考虑到了性能和代码简洁性。理解Java内存模型、CPU缓存一致性问题以及并发编程的原子性、有序性和可见性特性，对于编写正确且高效的多线程程序至关重要。

在处理共享变量时，开发者需要关注数据的一致性、可见性和顺序性。JMM通过内存屏障等技术实现volatile的语义，确保了不同线程间对volatile变量操作的可见性和顺序性。然而，对于非volatile变量，JMM允许进行指令重排序，这可能导致数据在多线程环境中的不一致。因此，在编写并发代码时，理解何时使用volatile和synchronized至关重要。

总的来说，volatile关键字在多线程编程中起着关键作用，它确保了共享变量的可见性，并通过禁止指令重排序保证了一定程度的顺序性。然而，它并不提供原子性保障，对于需要原子操作的场景，开发者应考虑使用`synchronized`或JUC包中的锁。同时，在设计单例模式时，需权衡性能、安全性和代码简洁性，选择最适合的方法实现。深入理解Java内存模型和并发编程的基本概念，有助于编写出高效且正确的多线程程序。

第三部分 深入理解volatile关键字

监控任务执行的整个生命周期，通过观察者模式来解决线程运行过程中状态获取的问题。传统的Thread类使用可能会导致数据不一致的安全隐患，因为共享变量的存在。因此，提出了Observable接口，它定义了任务执行的四个阶段：开始、进行中、完成和错误，并提供了start和interrupt方法，同时屏蔽了Thread其他API。进一步扩展，我们定义了TaskLifecycle接口，包含了在任务生命周期各阶段触发回调的方法。

为了实现可观察的任务，我们用Task函数式接口替换了Runnable，这样可以封装任务的逻辑。关键类ObservableThread继承自Thread并实现了Observable，构造时传入Task的具体实现。在run方法中，通过调用update方法来触发相应的事件，进而通知观察者任务的执行状态。这样一来，在整个任务生命周期中，我们就能追踪和处理各种情况，无需担心多线程带来的数据竞争问题。

ObservableThread是一个泛型类，它能监听任务执行过程中的事件，如计算结果。为了确保生命周期监控的有效性，run方法被重写为final，防止子类进行覆盖。ObservableThread的run方法作为事件源，而TaskLifecycle接口则在任务的不同阶段触发回调。这样的设计使得我们能够实时跟踪和管理任务的状态，提升了系统的稳定性和可维护性。

总的来说，通过观察者模式和一系列接口的设计，我们构建了一个能够全面监控任务执行生命周期的系统。这不仅解决了状态获取的问题，还提高了数据的安全性和系统的稳定性。同时，通过使用函数式接口替代理解式接口，我们也简化了代码结构，使得任务的管理和追踪更为直观和高效。

第15章 监控任务的生命周期

机场的安检流程中存在线程安全问题。在设计的一个模拟非线程安全的安检口类里，旅客（作为独立执行的线程）通过出示登机牌和身份证接受检查。然而，当多个线程同时调用pass方法时，可能会导致数据不一致的问题。例如，登机牌和身份证的信息可能错误匹配，即使它们的首字母相同。这是因为多线程间的交错执行可能导致检查结果出错或信息混淆。为解决这个问题，分析了错误产生的根源，发现需要对共享资源进行同步保护。具体来说，可以在pass方法上添加synchronized关键字，确保同一时间只有一个线程能执行这个方法。这样实现了单线程执行的设计模式，有效防止了数据不一致的问题。简而言之，线程安全的类设计要求在多个线程访问共享资源时，能够正确地控制这些访问，避免出现数据错误或程序异常。

进一步讨论中，提到了一个关于哲学家吃面的问题。这个问题描述了一个多进程（或线程）竞争有限资源的情景：五位哲学家用筷子（代表线程锁）尝试从五个碗中取食物（代表共享资源）。如果每个哲学家都只关注获取自己左侧的筷子，而不考虑其他筷子的状态，就可能出现所有哲学家都无法进食的情况，即死锁。这进一步强调了设计线程安全类的重要性以及在使用synchronized关键字保证同步时需考虑性能开销。

在使用synchronized来控制同步时，应尽可能减小同步代码块的范围。这是因为同步会阻止其他线程进入被保护的代码区域，可能导致不必要的阻塞和降低系统并发性。因此，尽管synchronized是处理多线程共享资源问题的强大工具，但过度或不适当使用可能会带来性能上的负面影响。

总的来说，线程安全是软件设计中的关键考虑因素，特别是在处理多个线程同时访问共享数据的情况下。通过理解线程安全的概念、识别潜在的问题（如死锁），以及有效地应用同步机制（如synchronized），开发者可以创建出更稳定、可靠的多线程应用程序。

第16章 Single Thread Execution设计模式

在多线程环境中处理共享资源时，同步操作是防止数据不一致的关键。然而，当读操作远多于写操作时，直接采用排他锁可能导致性能瓶颈。为优化这种情况，读写锁分离设计模式应运而生。它允许多个线程同时进行读操作，但确保同一时间只有一个线程执行写操作。

设计中定义了Lock和ReadWriteLock两个接口。Lock用于基本的加锁和解锁操作，而ReadWriteLock则负责创建读锁和写锁，并提供查询当前读写线程数量的方法。实现部分通过ReadWriteLockImpl类管理不同类型的锁，以及ReadLock类处理读锁的具体操作。这样设计有助于在保证数据一致性的同时，提升多读场景下的系统效率。

使用读写锁时，根据不同的操作同步使用不同的锁。例如，readLock用于读取共享资源，writeLock则用于执行写操作。当没有线程等待写操作且偏向写锁为真时，读线程可以获取锁进行读操作。然而，一旦有写线程等待并要求写锁，读线程将被阻塞，直到写线程完成其操作并释放锁。

读线程解锁时会释放对资源的访问权，同时可能唤醒等待的写线程。写线程在完成操作后，不仅需要释放锁，还需要更新状态信息，以便后续的读写操作能够正确进行。

为了比较不同锁解决方案的性能，进行了三组测试。测试对比了StampedLock、ReadWriteLock和synchronized关键字在不同数量读写线程下的表现。结果显示，当读操作远多于写操作时，StampedLock表现出色，其乐观机制使得它成为JDK 1.8中的首选锁解决方案，被誉为“lock家族的宠儿”。相比之下，synchronized的性能相对较差。

总的来说，读写锁分离设计模式通过区分读和写操作，有效提升了多读场景下的系统效率。而StampedLock凭借其优化的机制，在大多数情况下，特别是读多于写的场景中，展现出优秀的性能表现。然而，选择哪种锁解决方案应根据具体的应用场景和需求进行评估。

第17章 读写锁分离设计模式

不可变对象设计模式在多线程环境中的应用至关重要。它确保一旦创建，对象的状态就不能更改，从而避免数据竞争和死锁，提升系统性能。通过这种方式，无需使用synchronized关键字或显式锁（如Lock），实现无锁编程，减少了同步机制的依赖，降低性能开销。

Java核心类库中就有很多不可变对象的例子，比如String类。其所有方法都不需要同步处理，但在多线程环境下依然保持安全。Actor模型和函数式编程语言Clojure也广泛采用了不可变对象的概念来实现无锁并发。通过限制外部对共享资源的修改，不可变对象能防止数据冲突，进一步简化了线程安全问题。

设计不可变对象时，遵循的关键原则之一是使用final修饰符，以防止类被继承和实例被改变。然而，这并不足以确保完全不可变。例如，即使一个类被声明为final，其内部返回的可变数据结构（如List）仍可能被外部修改。因此，需要采取额外措施，比如返回不可修改的列表或创建一份新的列表副本，以进一步限制对外部的修改可能性。

总的来说，不可变对象设计模式在多线程环境中具有显著优势，它通过防止状态变化来简化并发控制，减少同步需求，并有助于提高系统的稳定性和性能。同时，在实现不可变性时，需要注意细节，确保所有可能被外部修改的部分都被妥善处理。这样，才能充分利用不可变对象带来的好处，构建出高效、可靠的多线程应用程序。

第18章 不可变对象设计模式

Future设计模式是处理耗时任务的一种非阻塞解决方案。以定制西服为例，当你下单后会得到一张Future作为凭据，无需等待，随时可用凭据获取完成的西装。从JDK 1.5开始，Java提供了Future接口，而JDK 1.8引入了功能更强大的CompletableFuture。

Future模式的核心在于FutureTask和FutureService。FutureTask负责保存计算结果并处理线程间的通信，如结果的保存与线程同步。FutureService则用于提交任务，支持无返回值或需要结果的任务。这使得程序在执行耗时操作的同时进行其他任务，提升效率。

使用FutureService时，通过submit方法提交任务，任务会立即返回，不会阻塞当前线程。然而，当调用get方法获取结果时，线程可能因等待任务完成而进入阻塞状态。为解决这个问题，FutureService引入了回调机制。在提交任务时，可以提供一个Callback接口实例，当任务执行完毕后，call方法会被调用，从而避免了通过get方法获取结果导致的阻塞，提升程序响应性和资源利用率。

然而，目前的FutureService还有改进空间。例如，增加get方法的超时功能，允许用户设定等待结果的最大时间；提供取消任务的支持，让用户在必要时能中断正在执行的任务；以及处理运行时错误的回调机制，确保即使在异常情况下，也能得到及时的通知和适当的处理。

综上所述，Future设计模式及其相关实现，如FutureTask和FutureService，为处理耗时任务提供了非阻塞的方式。通过回调机制优化了结果获取过程，提升了程序效率和用户体验。然而，还有许多潜在的优化点，如超时功能、取消任务支持和错误处理，有待进一步完善。

第19章 Future设计模式

Guarded Suspension设计模式，它确保线程在条件不满足时挂起等待。该模式用于解决当访问对象的条件未达到时，线程暂停并等待条件变为真再继续访问的问题，与Balking模式相反，后者在条件不满足时会放弃操作。Guarded Suspension是生产者消费者模式、Worker Thread设计模式等的基础，并广泛应用于Java并发包中的BlockingQueue。通过示例，展示了如何在队列满或空时挂起线程，确保数据一致性和控制操作范围。尽管该模式相对简单，但它在多线程设计中扮演重要角色。



第20章 Guarded Suspension设计模式

线程上下文设计模式在编程中扮演着关键角色，尤其当处理涉及全局信息的对象时。这些对象，如用户信息和运行时数据，被封装在所谓的“上下文”中，确保在整个系统或阶段的生命周期内可访问。为了保证上下文的唯一性和避免资源竞争，单例模式常被用来创建贯穿整个程序的上下文实例。

在复杂的多步骤任务中，传递大量参数会变得冗余且难以管理。线程上下文设计模式提供了解决方案，允许将相关数据绑定到特定线程，从而简化参数传递并确保每个线程的数据独立性。一个常见的应用例子是Java中的ApplicationContext和ActionContext，它们为每个线程维护独立的实例，确保了线程安全性和数据隔离。

然而，这种上下文管理方式并非没有潜在问题。如果不妥善处理，可能会导致内存泄漏。例如，如果使用不当，ThreadLocal对象可能会在不再需要时仍占用内存。Java自JDK 1.2以来提供的ThreadLocal类，为每个线程创建独立的变量副本，实现了数据隔离，避免了多线程间的干扰。

初始化ThreadLocal时，可以通过initialValue()方法设置初始值，如果不设置，默认返回null。set()方法用于存储数据，get()方法用于获取数据。当线程访问ThreadLocal时，它会在与之关联的ThreadLocalMap中查找对应的数据。如果该位置为空，ThreadLocal会调用initialValue()创建默认值或由开发者提供的初始值。

ThreadLocalMap是每个线程私有的，存储着ThreadLocal实例和它们的数据副本。为了防止内存溢出，设计时使用了WeakReference，这样当ThreadLocal对象不再被其他强引用所持有时，垃圾回收器可以将其清理掉。早期的JDK版本中，由于ThreadLocalMap使用HashMap实现，可能导致内存泄漏。为了解决这个问题，现代JDK版本采取了一些措施：使用WeakReference使得GC能自动回收 Entry；在get和set操作中增加检查，清理已被垃圾回收的Entry。

尽管这些改进有助于防止内存泄漏，但仍有潜在风险。例如，当显式将ThreadLocal对象设置为null后，除非相关线程结束，其值可能仍然不被释放，导致潜在的内存泄漏。此外，单个ThreadLocal与多个ThreadLocal对ThreadLocalMap的影响不同，这提醒我们在使用时需注意资源管理。

总的来说，线程上下文设计模式通过将数据绑定到特定线程，提供了高效且安全的数据管理和参数传递方式。然而，实现过程中需要关注内存管理问题，并根据具体需求选择合适的上下文管理策略。

第21章 线程上下文设计模式

Balking设计模式描绘了在多个线程监控同一共享变量时，若一执行线程发现已有其他线程处理相关变化，则自动放弃自身任务的情境。一个生动的例子是餐馆中服务员对顾客需求的响应，以及Word文档编辑中的自动保存与手动保存功能的协调。以Word为例，当自动保存线程在准备执行前察觉到用户已进行手动保存操作，它就会立即停止当前的保存行为。这种模式的关键在于某个线程能识别出其他线程正在执行相同任务，并选择退出，从而防止资源冲突。

本章节将通过一个模拟Word文档编辑和保存功能的实例来深入理解Balking模式。在这个例子中，用户进行文档编辑时，系统会启动编辑操作。同时，考虑到可能存在的资源加载或数据初始化需求，文中提到Balking模式可以有效应用。特别是在那些在整个程序生命周期内只需加载一次的资源情况下，通过该模式，我们可以避免不必要的重复加载，从而优化系统性能。

例如，在加载大型图片或者复杂的数据结构时，如果知道这些资源在整个应用程序运行期间只需要被加载和初始化一次，那么使用Balking模式就能确保这一过程只发生一次。这样不仅减少了不必要的计算和内存占用，还提高了程序的响应速度和整体效率。

通过这样的应用，Balking模式帮助我们实现了资源共享的高效管理，使得多线程环境下的任务执行更加有序、资源利用更加合理。在实际编程中，理解并灵活运用这种设计模式，将有助于我们构建出更为稳定、高效的并发系统。

第22章 Balking设计模式

Latch设计模式在编程领域中扮演着关键角色，它帮助我们管理多线程间的同步执行。想象一下，一群程序员计划一同出游，他们会在某个指定地点集合，然后集体前往目的地。这个场景就像Latch，所有程序员（线程）必须到达集合点（满足条件），才能一起行动。如果有人迟到，其他人就得稍作等待。CountDownLatch是Latch模式中的一员，它允许我们设定一个阈值，只有当所有任务（线程）完成到这个阈值时，后续的代码流程才会继续。这种策略在处理多线程并行执行的任务上非常有效，比如同时查询多个数据源并整合结果，这样能提升程序性能和响应速度。

在测试用例中，我们可能需要使用Latch来同步不同任务的执行顺序。例如，我们可能会创建一个场景，模拟多个程序员到达集合点的过程。首先，我们需要定义每个程序员（线程）作为单独的任务，并为他们设定到达集合点的时间（完成任务的条件）。然后，我们可以利用CountDownLatch来确保所有程序员都到达集合点后，再进行下一步操作，比如出发前往目的地。

然而，在实际编程中，我们可能遇到更复杂的情况。例如，有时我们需要在所有子任务完成后执行额外的操作，或者当某个特定的任务完成时触发某些行为。为此，Latch模式允许我们实现回调接口。这样，一旦所有的子任务都顺利完成，我们就能够调用预先定义的函数，进行后续处理。这种设计使得程序员能够在确保所有相关操作完成后，再进行下一步逻辑，从而提供了多线程同步的强大且灵活的控制机制。

考虑到实际应用中的多样性，Latch模式还支持根据需要调整同步策略。比如，我们可能希望在某些子任务完成时立即执行回调函数，而无需等待所有任务都结束。这种灵活性使得Latch模式能够适应各种复杂的多线程同步场景。

总的来说，Latch设计模式通过提供一种控制多线程同步的方法，使得程序员能够在确保所有相关操作完成后进行后续处理。它允许我们定义明确的执行顺序，处理并行任务，并在必要时执行额外的操作。无论是在简单的任务调度还是复杂的系统中，Latch模式都是一种强大且有用的工具。

第23章 Latch设计模式

Thread-Per-Message设计模式提倡为每条处理的消息分配一个独立线程，以此提升系统吞吐量。这个概念类似于电话接线员对多个投诉的并行处理。然而，这种策略并非没有局限性：首先，JVM内线程的数量是有限的；其次，长时间运行的线程可能会导致栈溢出的问题；再者，对于短暂的任务，频繁地创建和销毁线程会带来性能开销。

尽管存在这些限制，Thread-Per-Message模式在特定环境下依然适用，比如事件驱动编程模型。通过引入线程池技术，可以有效规避频繁线程操作带来的额外开销，并对线程数量进行控制。线程池确保了资源的高效利用，同时避免了因线程过多而导致的系统过载。

在日常开发中，这种设计模式被广泛应用。例如，在处理客户端连接请求时，服务器可能会采用Thread-Per-Message策略来并发处理多个请求。然而，当线程池中的所有线程都被占满时，新的连接请求将不得不等待，直到有线程空闲出来。这可能导致新用户的响应时间变长，影响用户体验。

为了解决这个问题并减少创建线程的开销，开发者通常会倾向于使用线程池。线程池通过复用已存在的线程来处理任务，减少了线程创建和销毁的频繁操作，从而提升了系统性能和资源利用率。此外，线程池还可以设置最大线程数，防止因过多线程导致的系统资源耗尽。

综上所述，Thread-Per-Message设计模式在提升系统吞吐量方面具有优势，但同时也伴随着线程数量限制、栈溢出风险以及频繁线程创建开销等问题。通过引入线程池技术，我们可以克服这些挑战，实现更高效、稳定和资源友好的任务处理。

第24章 Thread-Per-Message设计模式

Two Phase Termination设计模式应用于线程结束时的资源释放，分为受理终止和执行释放两阶段，确保安全、完全地结束线程并控制资源释放。当客户端发送"quit"或出现异常，示例展示了如何在处理连接的线程中应用此模式，安全关闭socket。

LRUCache是一种基于LRU算法的缓存实现，包含keyList管理键顺序和Cache存储数据。put方法添加新值时，若容量满则移除最早元素；get尝试从缓存获取，不存在则加载并调用put。为解决内存溢出，引入Soft Reference，当JVM内存不足时回收此类引用，通过SoftLRUCache实现灵活的内存管理。

SoftLRUCache使用Value被声明为SoftReference< V >，put时封装V为new SoftReference<>(V)，get先从cache获取SoftReference再通过其get得到值。即使长时间运行，SoftReference特性避免JVM内存溢出。Weak Reference在任何GC中都会回收，应用较少；Phantom Reference配合ReferenceQueue使用，执行预清理操作，比Java的finalization更灵活。

SocketCleaningTracker包含启动的Cleaner线程监控ReferenceQueue，当Socket被垃圾回收，Cleaner从队列移除对应的Tracker并关闭资源。这利用PhantomReference跟踪对象生命周期，确保资源及时释放，体现Two Phase Termination技巧。内容还涉及SoftReference、WeakReference，并通过实现LRU算法的Cache进行扩展讨论。

第25章 Two Phase Termination设计模式

Worker-Thread设计模式借鉴了工厂流水线的运作原理，其中任务处理流程可以被类比为上游工人完成部分工作后将半成品传递给下游工人继续加工。在软件开发中，这种模式的一个典型应用是线程池技术，它允许系统预创建一组线程，它们等待执行提交的任务，如实现了Runnable接口的对象。

这个设计模式包含三个核心角色：

1. **流水线工人**：在实际应用中，这些工人对应于负责处理任务的线程。例如，在Java中，我们可以使用Thread类或其子类来实现这类角色。

2. **传送带**：在Worker-Thread模式中，这个角色通常由某种形式的任务队列或通道承担，如BlockingQueue或PriorityBlockingQueue。它负责存储待处理的任务，并确保任务能够有序地传递给工人线程。

3. **产品组装说明书**：这一角色通过抽象类或接口来定义，它规定了任务的通用格式和处理规则。例如，在Java中，Runnable接口就是这样的一个规范，它要求实现类提供一个run方法供线程执行。

为了更好地组织任务处理流程，设计者可能会引入额外的元素：

- **产品**：在流水线比喻中，这是工人处理的对象，对应于软件中的具体任务或数据。

- **生产计划**：这可能涉及到如何分配任务给不同工人，或者何时启动和停止工作等策略。

模式的具体实现可能会有所不同，但基本思路是创建一组可以复用的工人（线程），并将任务放入一个队列中。然后，每个工人从队列中取出一个任务并执行它，直到所有任务完成或系统被要求停止。

在Java中，我们可以使用Executor框架来构建这样的线程池。ExecutorService接口提供了管理异步任务执行的方法，如submit、execute和shutdown等。通过构造不同类型的ThreadPoolExecutor实例，我们可以根据具体需求调整线程数量、任务处理策略（如是否允许并行处理）以及队列容量。

例如：
```java
ExecutorService executor = Executors.newFixedThreadPool(10);
executor.submit(new RunnableTask());
executor.shutdown();
```
上述代码创建了一个包含10个线程的固定大小线程池，并提交了一个RunnableTask实例。当所有任务执行完毕或调用shutdown时，线程池会停止接收新任务并等待现有任务完成。

通过这种方式，我们可以利用多核处理器的优势，提高程序的并发性和整体性能。同时，线程池还提供了易于管理、故障隔离和资源回收等优点，有助于构建健壮和高效的系统。

第26章 Worker-Thread设计模式

主动对象（Active Object）设计模式是一种构建异步处理系统的方法，它让对象能够在独立线程中运行并处理消息。这种模式通过将接口方法转化为异步执行，利用特定的Message类封装参数和实现，并可能返回Future类型的结果来处理延迟响应。

书中以System.gc()方法为例解释了主动对象如何处理异步消息：调用者与执行者在不同的线程中，消息作为参数传递给执行线程。标准的Active Objects设计包括将接口方法转换为异步执行，通过Message封装参数和实现，并可能返回Future来处理延迟响应。

OrderService接口是一个例子，它定义了带有返回值的方法（使用Future）和无返回值的方法。OrderServiceImpl实现了这些接口方法，其中findOrderDetails方法利用了第19章创建的Future立即返回结果，而order方法则通过休眠模拟长时间执行。

为了与消息队列交互，设计了一个OrderServiceProxy作为OrderService的代理，它将每个接口方法封装成MethodMessage并提交给消息队列。MethodMessage是一个抽象类，用于收集接口方法参数，并提供execute方法供工作线程调用。

FindOrderDetailsMessage和OrderMessage是MethodMessage的子类，分别对应服务中的查找订单详情和下订单两个方法。ActiveMessageQueue作为工作线程模式中的“传送带”，存放通过代理提交的MethodMessage，启动一个ActiveDaemonThread来异步执行这些消息。

ActiveDaemonThread是一个守护线程，负责从队列中获取MethodMessage并执行其execute方法。OrderServiceFactory是一个工具类，用于创建OrderServiceProxy并保持ActiveMessageQueue的唯一性。

测试代码展示了如何通过OrderServiceFactory将普通对象转换为异步执行的对象。后续章节将进一步设计一个通用的Active Objects框架，利用JDK动态代理技术简化接口方法封装为Message的过程，提升框架的灵活性和易用性。

ActiveMessage和Builder类用于构建消息。Builder提供了withObjects、forService等方法来构造消息，build方法则生成ActiveMessage实例。@ActiveMethod注解标记接口方法使其成为单独由线程执行的“Active-Method”。ActiveServiceFactory是核心类，负责创建Service代理和构建ActiveMessage，对被@ActiveMethod标记的方法进行特殊处理。

通过active方法生成的动态代理实例，其方法调用会经过ActiveInvocationHandler。符合规则的@ActiveMethod会被转换为ActiveMessage并加入队列，而非@ActiveMethod的方法则直接执行。这样，接口方法可以灵活地以同步或异步方式执行。

通用ActiveObjects框架利用ActiveMessageQueue和ActiveDaemonThread协作，将任意接口方法转换为异步执行。使用示例展示了如何创建并调用异步方法，主线程立即返回，而实际处理在其他线程中进行。这种模式结合代理、同步队列和工作线程设计，实现了保留接口调用形式的同时实现方法的异步化。

第27章 Active Objects设计模式

Event Bus是一种设计模式，用于在Java应用程序中实现组件间的解耦通信。它通过事件发布（post）和订阅者注册（register）机制，允许消息在不同组件之间高效、灵活地传递。核心类包括Bus接口、Registry（注册表）、Dispatcher（调度器）等。

Bus接口提供了基本操作，如发送事件、注册和取消注册接收者。根据需求，Event Bus可以实现同步（EventBus）或异步（AsyncEventBus）模式。同步EventBus在接收到事件后立即处理，而异步EventBus则使用线程池，每个消息一个线程，以提高并发执行效率。

为了简化事件处理的代码，Java中的Event Bus设计引入了注解@Subscribe。通过在方法上使用这个注解，可以指定处理特定主题（topic）的事件。同一个订阅者可以处理来自不同主题的事件，只需在其方法上标记不同的主题。

Dispatcher类是Event Bus的核心组件，它负责将事件分发给注册表中关注相应主题的接收者。构造器接受一个线程执行器和异常处理器作为参数。在dispatch方法中，Dispatcher根据主题从Registry获取订阅者，并通过反射调用其处理事件的方法。如果某个主题未找到绑定的接收者，会通过异常处理器进行处理。

Subscriber类封装了事件处理的方法和对象，它包含被@Subscribe注解的方法，用于在调度过程中被调用。EventBus将方法调用包装成Runnable执行，以处理可能出现的异常。定义了EventExceptionHandler接口，在消息推送出错时回调，提供异常信息。EventContext接口提供了获取事件源、订阅者、订阅方法和事件本身的信息。

Java中的Event Bus设计不仅限于同步和异步模式，还支持顺序执行和每个线程独立执行的Executor实现，以及基础的EventContext实现类。这些组件共同构成了事件驱动架构的关键部分，使得普通类中的方法能够轻松地通过注解实现事件回调功能。

在实际项目中，Event Bus可以用于多种场景，如监控目录变化。结合WatchService类，可以创建一个基于事件的通知系统，实时监控文件或目录的变动，提供高效的数据采集方案。示例代码展示了如何使用WatchService和异步EventBus实现目录监控：创建WatchService，为指定路径注册感兴趣的事件（如文件修改、删除和创建）。当这些事件发生时，通过EventBus发布FileChangeEvent。FileChangeListener类的方法被标记为@Subscribe，会在目录有变化时接收到并处理这些事件。将FileChangeListener注册到异步EventBus并启动监控程序后，即可实现实时监控指定目录下的文件变动，并在控制台输出相关事件信息。

总之，Java中的Event Bus设计提供了一种强大且灵活的通信机制，它通过解耦组件、支持同步和异步处理以及与WatchService等工具结合，实现了高效的消息传递和事件驱动编程。

第28章 Event Bus设计模式

事件驱动架构（EDA）是一种松耦合、可扩展的架构模式，它依赖于Events（数据）、Event Handlers（处理方法）和Event Loop（管理流程的机制）。Events至少包含类型和数据属性，决定哪个Handler执行；Event Handlers负责操作Events，如过滤或转换数据；Event Loop从消息队列中移除Events并按类型分配给相应Handler。在FooEventDrivenExample中，展示了这三个组件协同工作的示例。

设计同步EDA框架的步骤包括定义Message（事件信息）、Channel（处理特定类型消息）、Dynamic Router（帮助Event找到正确Channel）和核心元素如Event与EventDispatcher。EventDispatcher是单线程环境中的基础Router实现，通过路由表存储Message类型和处理它们的Channel对应关系。如果找不到匹配的Channel，会抛出MessageMatcherException。一个测试案例展示了如何使用EventDispatcher：创建InputEvent和ResultEvent消息类，以及处理这些事件的InputEventHandler和ResultEventHandler。在main方法中实例化EventDispatcher、注册Channel与Handler绑定，然后发送InputEvent。这演示了EventDispatcher作为Router的角色，提供松耦合控制，让各部分无需了解彼此细节即可协同工作。

为应对高并发场景，后续章节将扩展EDA框架支持并发任务执行。`AsyncChannel`类处理事件消息的异步通道，可自定义线程池大小或使用默认值（CPU核心数两倍）。`dispatch`方法final修饰防止子类重写，提供抽象`handle`方法处理具体消息，并有关闭ExecutorService的方法。配合使用的`AsyncEventDispatcher`作为动态路由器，根据事件类型路由到对应的异步通道。它使用线程安全的ConcurrentHashMap存储通道，在接收到消息时分发给相应通道处理。

EDA在简单聊天应用中实践：用户上线、下线或发送消息产生不同类型的Event（如UserOnlineEvent、UserOfflineEvent和UserChatEvent）。这些Event通过`AsyncEventDispatcher`异步分发，不会因处理速度慢阻塞后续Event。Event被各种Handler接收并处理，输出到控制台。应用中创建多个UserChatThread代表聊天室用户，它们发送在线、聊天和下线等Event给dispatcher。注册不同Channel处理不同类型的Event，实现事件的异步处理和解耦。测试程序模拟三个用户同时上线、聊天和下线，展示了EDA框架在简单聊天应用中的工作流程。

测试程序使用三个User线程模拟用户行为，如上线、发言和下线。尽管没有同步控制消息事件，但因为Events设计为不可变对象，每个Channel处理时创建新实例，避免多线程间的资源竞争。这让人联想到生产者消费者模式，若用EDA框架重写，可减少线程间交互和队列同步需求，简化为直接提交消息、Handler自动消费的流程。

Java高并发编程详解