java线程的缺陷

Java 编程语言的线程模型可能是此语言中最薄弱的部分。它完全不适合实际复杂程序的要求，而且也完全不是面向对象的。本文建议对 Java 语言进行重大修改和补充，以解决这些问题。

Java 语言的线程模型是此语言的一个最难另人满意的部分。尽管 Java 语言本身就支持线程编程是件好事，但是它对线程的语法和类包的支持太少，只能适用于极小型的应用环境。

关 于 Java 线程编程的大多数书籍都长篇累牍地指出了 Java 线程模型的缺陷，并提供了解决这些问题的急救包(Band-Aid/邦迪创可贴)类库。我称这些类为急救包，是因为它们所能解决的问题本应是由 Java 语言本身语法所包含的。从长远来看，以语法而不是类库方法，将能产生更高效的代码。这是因为编译器和 Java 虚拟器 (JVM) 能一同优化程序代码，而这些优化对于类库中的代码是很难或无法实现的。

在 我的《Taming Java Threads 》（请参阅 参考资料 ）书中以及本文中，我进一步建议对 Java 编程语言本身进行一些修改，以使得它能够真正解决这些线程编程的问题。本文和我这本书的主要区别是，我在撰写本文时进行了更多的思考, 所以对书中的提议加以了提高。这些建议只是尝试性的 -- 只是我个人对这些问题的想法，而且实现这些想法需要进行大量的工作以及同行们的评价。但这是毕竟是一个开端，我有意为解决这些问题成立一个专门的工作组， 如果您感兴趣，请发 e-mail 到 [e-mail] 。一旦我真正着手进行，我就会给您发通知。

这里提出的建议是非常大胆的。有些人建议对 Java 语言规范 (JLS)（请参阅参考资料 ）进行细微和少量的修改以解决当前模糊的 JVM 行为，但是我却想对其进行更为彻底的改进。

在 实际草稿中，我的许多建议包括为此语言引入新的关键字。虽然通常要求不要突破一个语言的现有代码是正确的，但是如果该语言的并不是要保持不变以至于过时的 话，它就必须能引入新的关键字。为了使引入的关键字与现有的标识符不产生冲突，经过细心考虑，我将使用一个 ($) 字符，而这个字符在现有的标识符中是非法的。(例如，使用 $task，而不是 task)。此时需要编译器的命令行开关提供支持，能使用这些关键字的变体，而不是忽略这个美元符号。

task（任务）的概念

Java 线程模型的根本问题是它完全不是面向对象的。面向对象 (OO) 设计人员根本不按线程角度考虑问题；他们考虑的是同步 信息 异步 信息（同步信息被立即处理 -- 直到信息处理完成才返回消息句柄；异步信息收到后将在后台处理一段时间 -- 而早在信息处理结束前就返回消息句柄）。Java 编程语言中的 Toolkit.getImage() 方法就是异步信息的一个好例子。 getImage() 的消息句柄将被立即返回，而不必等到整个图像被后台线程取回。

这是面向对象 (OO) 的处理方法。但是，如前所述，Java 的线程模型是非面向对象的。一个 Java 编程语言线程实际上只是一个run() 过程，它调用了其它的过程。在这里就根本没有对象、异步或同步信息以及其它概念。

对 于此问题，在我的书中深入讨论过的一个解决方法是，使用一个Active_object。 active 对象是可以接收异步请求的对象，它在接收到请求后的一段时间内以后台方式得以处理。在 Java 编程语言中，一个请求可被封装在一个对象中。例如，你可以把一个通过 Runnable 接口实现的实例传送给此 active 对象，该接口的 run() 方法封装了需要完成的工作。该 runnable 对象被此 active 对象排入到队列中，当轮到它执行时，active 对象使用一个后台线程来执行它。

在一个 active 对象上运行的异步信息实际上是同步的，因为它们被一个单一的服务线程按顺序从队列中取出并执行。因此，使用一个 active 对象以一种更为过程化的模型可以消除大多数的同步问题。

在 某种意义上，Java 编程语言的整个 Swing/AWT 子系统是一个 active 对象。向一个 Swing 队列传送一条讯息的唯一安全的途径是，调用一个类似SwingUtilities.invokeLater() 的方法，这样就在 Swing 事件队列上发送了一个 runnable 对象，当轮到它执行时， Swing 事件处理线程将会处理它。

那么我的第一个建议是，向 Java 编程语言中加入一个task （任务）的概念，从而将active 对象集成到语言中。( task的概念是从 Intel 的 RMX 操作系统和 Ada 编程语言借鉴过来的。大多数实时操作系统都支持类似的概念。）

一个任务有一个内置的 active 对象分发程序，并自动管理那些处理异步信息的全部机制。

定 义一个任务和定义一个类基本相同，不同的只是需要在任务的方法前加一个asynchronous 修饰符来指示 active 对象的分配程序在后台处理这些方法。请参考我的书中第九章的基于类方法，再看以下的 file_io 类，它使用了在《 Taming Java Threads 》中所讨论的 Active_object 类来实现异步写操作：

所 有的写请求都用一个dispatch() 过程调用被放在 active-object 的输入队列中排队。在后台处理这些异步信息时出现的任何异常 (exception) 都由 Exception_handler 对象处理，此 Exception_handler 对象被传送到 File_io_task 的构造函数中。您要写内容到文件时，代码如下：

这种基于类的处理方法，其主要问题是太复杂了 -- 对于一个这样简单的操作，代码太杂了。向 Java 语言引入$task 和 $asynchronous 关键字后，就可以按下面这样重写以前的代码：

注 意，异步方法并没有指定返回值，因为其句柄将被立即返回，而不用等到请求的操作处理完成后。所以，此时没有合理的返回值。对于派生出的模型，$task 关键字和 class 一样同效： $task 可以实现接口、继承类和继承的其它任务。标有 asynchronous 关键字的方法由 $task 在后台处理。其它的方法将同步运行，就像在类中一样。

$task 关键字可以用一个可选的 $error 从句修饰 (如上所示)，它表明对任何无法被异步方法本身捕捉的异常将有一个缺省的处理程序。我使用 $ 来代表被抛出的异常对象。如果没有指定 $error 从句，就将打印出一个合理的出错信息（很可能是堆栈跟踪信息）。

注意，为确保线程安全，异步方法的参数必须是不变 (immutable) 的。运行时系统应通过相关语义来保证这种不变性（简单的复制通常是不够的）。

所有的 task 对象必须支持一些伪信息 (pseudo-message)，例如：

除 了常用的修饰符（public 等)， task 关键字还应接受一个 $pooled(n) 修饰符，它导致 task 使用一个线程池，而不是使用单个线程来运行异步请求。 n 指定了所需线程池的大小；必要时，此线程池可以增加，但是当不再需要线程时，它应该缩到原来的大小。伪域 (pseudo-field) $pool_size 返回在 $pooled(n) 中指定的原始 n 参数值。

在 《Taming Java Threads 》的第八章中，我给出了一个服务器端的 socket 处理程序，作为线程池的例子。它是关于使用线程池的任务的一个好例子。其基本思路是产生一个独立对象，它的任务是监控一个服务器端的 socket。每当一个客户机连接到服务器时，服务器端的对象会从池中抓取一个预先创建的睡眠线程，并把此线程设置为服务于客户端连接。socket 服务器会产出一个额外的客户服务线程，但是当连接关闭时，这些额外的线程将被删除。实现 socket 服务器的推荐语法如下：

Socket_server 对象使用一个独立的后台线程处理异步的 listen() 请求，它封装 socket 的“接受”循环。当每个客户端连接时， listen() 请求一个 Client_handler 通过调用 handle() 来处理请求。每个 handle() 请求在它们自己的线程中执行（因为这是一个 $pooled 任务)。

注 意，每个传送到$pooled $task 的异步消息实际上都使用它们自己的线程来处理。典型情况下，由于一个 $pooled $task 用于实现一个自主操作；所以对于解决与访问状态变量有关的潜在的同步问题，最好的解决方法是在 $asynchronous 方法中使用 this 是指向的对象的一个独有副本。这就是说，当向一个 $pooled $task 发送一个异步请求时，将执行一个 clone() 操作，并且此方法的 this 指针会指向此克隆对象。线程之间的通信可通过对 static 区的同步访问实现。

改进synchronized

虽 然在多数情况下，$task 消除了同步操作的要求，但是不是所有的多线程系统都用任务来实现。所以，还需要改进现有的线程模块。 synchronized 关键字有下列缺点： 无法指定一个超时值。 无法中断一个正在等待请求锁的线程。 无法安全地请求多个锁 。(多个锁只能以依次序获得。)

解决这些问题的办法是：扩展synchronized 的语法，使它支持多个参数和能接受一个超时说明（在下面的括弧中指定）。下面是我希望的语法：

 

synchronized(x && y && z) 获得 x、y 和 z 对象的锁。
synchronized(x || y || z) 获得 x、y 或 z 对象的锁。
synchronized( (x && y ) || z) 对于前面代码的一些扩展。
synchronized(...)[1000] 设置 1 秒超时以获得一个锁。
synchronized[1000] f(){...} 在进入 f() 函数时获得 this 的锁，但可有 1 秒超时。

 

TimeoutException是 RuntimeException 派生类，它在等待超时后即被抛出。

超 时是需要的，但还不足以使代码强壮。您还需要具备从外部中止请求锁等待的能力。所以，当向一个等待锁的线程传送一个interrupt() 方法后，此方法应抛出一个 SynchronizationException 对象，并中断等待的线程。这个异常应是 RuntimeException 的一个派生类，这样不必特别处理它。

对synchronized 语法这些推荐的更改方法的主要问题是，它们需要在二进制代码级上修改。而目前这些代码使用进入监控(enter-monitor)和退出监控(exit- monitor)指令来实现 synchronized 。而这些指令没有参数，所以需要扩展二进制代码的定义以支持多个锁定请求。但是这种修改不会比在 Java 2 中修改 Java 虚拟机的更轻松，但它是向下兼容现存的 Java 代码。

另一个可解决的问题是最常见的死锁情况，在这种情况下，两个线程都在等待对方完成某个操作。设想下面的一个例子（假设的）：

设 想一个线程调用a() ，但在获得　 lock1 之后在获得 lock2 之前被剥夺运行权。 第二个线程进入运行，调用 b() ，获得了 lock2 ，但是由于第一个线程占用 lock1 ，所以它无法获得 lock1 ，所以它随后处于等待状态。此时第一个线程被唤醒，它试图获得 lock2 ，但是由于被第二个线程占据，所以无法获得。此时出现死锁。下面的 synchronize-on-multiple-objects 的语法可解决这个问题：

编译器(或虚拟机)会重新排列请求锁的顺序，使lock1 总是被首先获得，这就消除了死锁。

但是，这种方法对多线程不一定总成功，所以得提供一些方法来自动打破死锁。一个简单的办法就是在等待第二个锁时常释放已获得的锁。这就是说，应采取如下的等待方式，而不是永远等待：

如果等待锁的每个程序使用不同的超时值，就可打破死锁而其中一个线程就可运行。我建议用以下的语法来取代前面的代码：

synchronized语句将永远等待，但是它时常会放弃已获得的锁以打破潜在的死锁可能。在理想情况下，每个重复等待的超时值比前一个相差一随机值。

改进wait() 和 notify()

wait()/ notify() 系统也有一些问题： 无法检测 wait() 是正常返回还是因超时返回。 无法使用传统条件变量来实现处于一个“信号”(signaled)状态。 太容易发生嵌套的监控(monitor)锁定。

超时检测问题可以通过重新定义wait() 使它返回一个 boolean 变量 (而不是 void ) 来解决。一个 true 返回值指示一个正常返回，而 false 指示因超时返回。

基 于状态的条件变量的概念是很重要的。如果此变量被设置成false 状态，那么等待的线程将要被阻断，直到此变量进入 true 状态；任何等待 true 的条件变量的等待线程会被自动释放。 (在这种情况下， wait() 调用不会发生阻断。)。通过如下扩展 notify() 的语法，可以支持这个功能：

嵌套监控锁定问题非常麻烦，我并没有简单的解决办法。嵌套监控锁定是一种死锁形式，当某个锁的占有线程在挂起其自身之前不释放锁时，会发生这种嵌套监控封锁。下面是此问题的一个例子（还是假设的），但是实际的例子是非常多的：

此 例中，在get() 和 put() 操作中涉及两个锁：一个在 Stack 对象上，另一个在 LinkedList 对象上。下面我们考虑当一个线程试图调用一个空栈的 pop() 操作时的情况。此线程获得这两个锁，然后调用 wait() 释放 Stack 对象上 的锁，但是没有释放在 list 上的锁。如果此时第二个线程试图向堆栈中压入一个对象，它会在 synchronized(list) 语句上永远挂起，而且永远不会被允许压入一个对象。由于第一个线程等待的是一个非空栈，这样就会发生死锁。这就是说，第一个线程永远无法从 wait() 返回，因为由于它占据着锁，而导致第二个线程永远无法运行到 notify() 语句。

在这个例子中，有很多明显的办法来解决问题：例如，对任何的方法都使用同步。但是在真实世界中，解决方法通常不是这么简单。

一 个可行的方法是，在wait() 中按照反顺序释放当前线程获取的 所有 锁，然后当等待条件满足后，重新按原始获取顺序取得它们。但是，我能想象出利用这种方式的代码对于人们来说简直无法理解，所以我认为它不是一个真正可行的 方法。如果您有好的方法，请给我发 e-mail。

我也希望能等到下述复杂条件被实现的一天。例如：

其中a 、 b 和 c 是任意对象。

修改Thread 类

同 时支持抢占式和协作式线程的能力在某些服务器应用程序中是基本要求，尤其是在想使系统达到最高性能的情况下。我认为 Java 编程语言在简化线程模型上走得太远了，并且 Java 编程语言应支持 Posix/Solaris 的“绿色(green)线程”和“轻便(lightweight)进程”概念（在“（Taming Java Threads ”第一章中讨论）。 这就是说，有些 Java 虚拟机的实现（例如在 NT 上的 Java 虚拟机）应在其内部仿真协作式进程，其它 Java 虚拟机应仿真抢占式线程。而且向 Java 虚拟机加入这些扩展是很容易的。

一 个 Java 的Thread 应始终是抢占式的。这就是说，一个 Java 编程语言的线程应像 Solaris 的轻便进程一样工作。 Runnable 接口可以用于定义一个 Solaris 式的“绿色线程”，此线程必需能把控制权转给运行在相同轻便进程中的其它绿色线程。

例如，目前的语法：

能有效地为Runnable 对象产生一个绿色线程，并把它绑定到由 Thread 对象代表的轻便进程中。这种实现对于现有代码是透明的，因为它的有效性和现有的完全一样。

把Runnable 对象想成为绿色线程，使用这种方法，只需向 Thread 的构造函数传递几个 Runnable 对象，就可以扩展 Java 编程语言的现有语法，以支持在一个单一轻便线程有多个绿色线程。（绿色线程之间可以相互协作，但是它们可被运行在其它轻便进程 ( Thread 对象) 上的绿色进程( Runnable 对象) 抢占。）。例如，下面的代码会为每个 runnable 对象创建一个绿色线程，这些绿色线程会共享由 Thread 对象代表的轻便进程。

现有的覆盖(override)Thread 对象并实现 run() 的习惯继续有效，但是它应映射到一个被绑定到一轻便进程的绿色线程。(在 Thread() 类中的缺省 run() 方法会在内部有效地创建第二个 Runnable 对象。)

线程间的协作

应 在语言中加入更多的功能以支持线程间的相互通信。目前，PipedInputStream 和 PipedOutputStream 类可用于这个目的。但是对于大多数应用程序，它们太弱了。我建议向 Thread 类加入下列函数： 增加一个 wait_for_start() 方法，它通常处于阻塞状态，直到一个线程的 run() 方法启动。(如果等待的线程在调用 run 之前被释放，这没有什么问题）。用这种方法，一个线程可以创建一个或多个辅助线程，并保证在创建线程继续执行操作之前，这些辅助线程会处于运行状态。 （向 Object 类）增加 $send (Object o) 和 Object=$receive() 方法，它们将使用一个内部阻断队列在线程之间传送对象。阻断队列应作为第一个 $send() 调用的副产品被自动创建。 $send() 调用会把对象加入队列。 $receive() 调用通常处于阻塞状态，直到有一个对象被加入队列，然后它返回此对象。这种方法中的变量应支持设定入队和出队的操作超时能力： $send (Object o, long timeout) 和 $receive (long timeout)。

对于读写锁的内部支持

读 写锁的概念应内置到 Java 编程语言中。读写器锁在“Taming Java Threads ”（和其它地方）中有详细讨论，概括地说：一个读写锁支持多个线程同时访问一个对象，但是在同一时刻只有一个线程可以修改此对象，并且在访问进行时不能修 改。读写锁的语法可以借用 synchronized 关键字：

对 于一个对象，应该只有在$writing 块中没有线程时，才支持多个线程进入 $reading 块。在进行读操作时，一个试图进入 $writing 块的线程会被阻断，直到读线程退出 $reading 块。 当有其它线程处于 $writing 块时，试图进入 $reading 或 $writing 块的线程会被阻断，直到此写线程退出 $writing 块。

如果读和写线程都在等待，缺省情况下，读线程会首先进行。但是，可以使用$writer_priority 属性修改类的定义来改变这种缺省方式。如：

访问部分创建的对象应是非法的

当前情况下，JLS 允许访问部分创建的对象。例如，在一个构造函数中创建的线程可以访问正被创建的对象，既使此对象没有完全被创建。下面代码的结果无法确定：

设置x 为 -1 的线程可以和设置 x 为 0 的线程同时进行。所以，此时 x 的值无法预测。

对此问题的一个解决方法是，在构造函数没有返回之前，对于在此构造函数中创建的线程，既使它的优先级比调用new 的线程高，也要禁止运行它的 run() 方法。

这就是说，在构造函数返回之前，start() 请求必须被推迟。

另外，Java 编程语言应可允许构造函数的同步。换句话说，下面的代码（在当前情况下是非法的）会象预期的那样工作：

我认为第一种方法比第二种更简洁，但实现起来更为困难。

volatile关键字应象预期的那样工作

JLS 要求保留对于 volatile 操作的请求。大多数 Java 虚拟机都简单地忽略了这部分内容，这是不应该的。在多处理器的情况下，许多主机都出现了这种问题，但是它本应由 JLS 加以解决的。如果您对这方面感兴趣，马里兰大学的 Bill Pugh 正在致力于这项工作（请参阅参考资料 ）。

访问的问题

如 果缺少良好的访问控制，会使线程编程非常困难。大多数情况下，如果能保证线程只从同步子系统中调用，不必考虑线程安全(threadsafe)问题。我建 议对 Java 编程语言的访问权限概念做如下限制；应精确使用 package 关键字来限制包访问权。我认为当缺省行为的存在是任何一种计算机语言的一个瑕疵，我对现在存在这种缺省权限感到很迷惑（而且这种缺省是“包 (package)”级别的而不是“私有(private)”）。在其它方面，Java 编程语言都不提供等同的缺省关键字。虽然使用显式的 package 的限定词会破坏现有代码，但是它将使代码的可读性更强，并能消除整个类的潜在错误 (例如，如果访问权是由于错误被忽略，而不是被故意忽略)。 重新引入 private protected ，它的功能应和现在的 protected 一样，但是不应允许包级别的访问。 允许 private private 语法指定“实现的访问”对于所有外部对象是私有的，甚至是当前对象是的同一个类的。对于“.”左边的唯一引用（隐式或显式）应是 this 。 扩展 public 的语法，以授权它可制定特定类的访问。例如，下面的代码应允许 Fred 类的对象可调用 some_method() ，但是对其它类的对象，这个方法应是私有的。

这 种建议不同于 C++ 的 "friend" 机制。 在 "friend" 机制中，它授权一个类访问另一个类的所有 私有部分。在这里，我建议对有限的方法集合进行严格控制的访问。用这种方法，一个类可以为另一个类定义一个接口，而这个接口对系统的其余类是不可见的。一 个明显的变化是：

除非域引用的是真正不变 (immutable)的对象或static final 基本类型，否则所有域的定义应是 private 。对于一个类中域的直接访问违反了 OO 设计的两个基本规则：抽象和封装。从线程的观点来看，允许直接访问域只使对它进行非同步访问更容易一些。

增 加$property 关键字。带有此关键字的对象可被一个“bean 盒”应用程序访问，这个程序使用在 Class 类中定义的反射操作(introspection) API，否则与 private private 同效。 $property 属性可用在域和方法，这样现有的 JavaBean getter/setter 方法可以很容易地被定义为属性。

不变性(immutability)

由 于对不变对象的访问不需要同步，所以在多线程条件下，不变的概念（一个对象的值在创建后不可更改）是无价的。Java 编程言语中，对于不变性的实现不够严格，有两个原因：对于一个不变对象，在其被未完全创建之前，可以对它进行访问。这种访问对于某些域可以产生不正确的 值。 对于恒定 (类的所有域都是 final) 的定义太松散。对于由 final 引用指定的对象，虽然引用本身不能改变，但是对象本身可以改变状态。

第一个问题可以解决，不允许线程在构造函数中开始执行 (或者在构造函数返回之前不能执行开始请求)。

对 于第二个问题，通过限定final 修饰符指向恒定对象，可以解决此问题。这就是说，对于一个对象，只有所有的域是 final，并且所有引用的对象的域也都是 final，此对象才真正是恒定的。为了不打破现有代码，这个定义可以使用编译器加强，即只有一个类被显式标为不变时，此类才是不变类。方法如下：

有了$immutable 修饰符后，在域定义中的 final 修饰符是可选的。

最后，当使用内部类(inner class)后，在 Java 编译器中的一个错误使它无法可靠地创建不变对象。当一个类有重要的内部类时(我的代码常有)，编译器经常不正确地显示下列错误信息：

既使空的 final 在每个构造函数中都有初始化，还是会出现这个错误信息。自从在 1.1 版本中引入内部类后，编译器中一直有这个错误。在此版本中（三年以后），这个错误依然存在。现在，该是改正这个错误的时候了。

对于类级域的实例级访问

除 了访问权限外，还有一个问题，即类级（静态）方法和实例（非静态）方法都能直接访问类级（静态）域。这种访问是非常危险的，因为实例方法的同步不会获取类 级的锁，所以一个synchronized static 方法和一个 synchronized 方法还是能同时访问类的域。改正此问题的一个明显的方法是，要求在实例方法中只有使用 static 访问方法才能访问非不变类的 static 域。当然，这种要求需要编译器和运行时间检查。在这种规定下，下面的代码是非法的：

由 于f() 和 g() 可以并行运行，所以它们能同时改变 x 的值（产生不定的结果）。请记住，这里有两个锁： static 方法要求属于 Class 对象的锁，而非静态方法要求属于此类实例的锁。当从实例方法中访问非不变 static 域时，编译器应要求满足下面两个结构中的任意一个：

或则，编译器应获得读/写锁的使用：

另外一种方法是（这也是一种理想的 方法）-- 编译器应 自动 使用一个读/写锁来同步访问非不变 static 域，这样，程序员就不必担心这个问题。

后台线程的突然结束

当所有的非后台线程终止后，后台线程都被突然结束。当后台线程创建了一些全局资源（例如一个数据库连接或一个临时文件），而后台线程结束时这些资源没有被关闭或删除就会导致问题。

对于这个问题，我建议制定规则，使 Java 虚拟机在下列情况下不关闭应用程序：有任何非后台线程正在运行，或者： 有任何后台线程正在执行一个 synchronized 方法或 synchronized 代码块。

后台线程在它执行完synchronized 块或 synchronized 方法后可被立即关闭。

重新引入stop() 、 suspend() 和 resume() 关键字

由 于实用原因这也许不可行，但是我希望不要废除stop() (在 Thread 和 ThreadGroup 中)。但是，我会改变 stop() 的语义，使得调用它时不会破坏已有代码。但是，关于 stop() 的问题，请记住，当线程终止后， stop() 将释放所有锁，这样可能潜在地使正在此对象上工作的线程进入一种不稳定（局部修改）的状态。由于停止的线程已释放它在此对象上的所有锁，所以这些对象无法 再被访问。

对于这个问题，可以重新定义 stop() 的行为，使线程只有在不占有任何锁时才立即终止。如果它占据着锁，我建议在此线程释放最后一个锁后才终止它。可以使用一个和抛出异常相似的机制来实现此行 为。被停止线程应设置一个标志，并且当退出所有同步块时立即测试此标志。如果设置了此标志，就抛出一个隐式的异常，但是此异常应不再能被捕捉并且当线程结 束时不会产生任何输出。注意，微软的 NT 操作系统不能很好地处理一个外部指示的突然停止(abrupt)。（它不把 stop 消息通知动态连接库，所以可能导致系统级的资源漏洞。）这就是我建议使用类似异常的方法简单地导致 run() 返回的原因。

与 这种和异常类似的处理方法带来的实际问题是，你必需在每个synchronized 块后都插入代码来测试“stopped”标志。并且这种附加的代码会降低系统性能并增加代码长度。我想到的另外一个办法是使 stop() 实现一个“延迟的(lazy)”停止，在这种情况下，在下次调用 wait() 或 yield() 时才终止。我还想向 Thread 中加入一个 isStopped() 和 stopped() 方法（此时， Thread 将像 isInterrupted() 和 interrupted() 一样工作，但是会检测 “stop-requested”的状态)。这种方法不向第一种那样通用，但是可行并且不会产生过载。

应 把suspend() 和 resume() 方法放回到 Java 编程语言中，它们是很有用的，我不想被当成是幼儿园的小孩。由于它们可能产生潜在的危险（当被挂起时，一个线程可以占据一个锁）而去掉它们是没有道理的。 请让我自己来决定是否使用它们。如果接收的线程正占据着锁，Sun 公司应该把它们作为调用 suspend() 的一个运行时间异常处理(run-time exception)；或者更好的方法是，延迟实际的挂起过程，直到线程释放所有的锁。

被阻断的 I/O 应正确工作

应 该能打断任何被阻断的操作，而不是只让它们wait() 和 sleep() 。我在“ Taming Java Threads ”的第二章中的 socket 部分讨论了此问题。但是现在，对于一个被阻断的 socket 上的 I/O 操作，打断它的唯一办法是关闭这个 socket，而没有办法打断一个被阻断的文件 I/O 操作。例如，一旦开始一个读请求并且进入阻断状态后，除非到它实际读出一些东西，否则线程一直出于阻断状态。既使关掉文件句柄也不能打断读操作。

还有，程序应支持 I/O 操作的超时。所有可能出现阻断操作的对象（例如 InputStream 对象）也都应支持这种方法：

这和 Socket 类的setSoTimeout(time) 方法是等价的。同样地，应该支持把超时作为参数传递到阻断的调用。

ThreadGroup类

ThreadGroup应该实现 Thread 中能够改变线程状态的所有方法。我特别想让它实现 join() 方法，这样我就可等待组中的所有线程的终止。

总结

以 上是我的建议。就像我在标题中所说的那样，如果我是国王...（哎）。我希望这些改变（或其它等同的方法）最终能被引入 Java 语言中。我确实认为 Java 语言是一种伟大的编程语言；但是我也认为 Java 的线程模型设计得还不够完善，这是一件很可惜的事情。但是，Java 编程语言正在演变，所以还有可提高的前景。

参 考资料本文是对 Taming Java Threads 的更新摘编。该书探讨了在 Java 语言中多线程编程的陷阱和问题，并提供了一个与线程相关的 Java 程序包来解决这些问题。 马里兰大学的 Bill Pugh 正在致力修改 JLS 来提高其线程模型。Bill 的提议并不如本文所推荐的那么广，他主要致力于让现有的线程模型以更为合理方式运行。更多信息可从 www.cs.umd.edu/~pugh/java/memoryModel/ 获得。 从 Sun 网站 可找到全部 Java 语言的规范。 要从一个纯技术角度来审视线程，参阅 Doug Lea 编著的 Concurrent Programming in Java: Design Principles and Patterns 第二版 。这是本很棒的书，但是它的风格是非常学术化的并不一定适合所有的读者。对《 Taming Java Threads 》是个很好的补充读物。 由 Scott Oaks 和 Henry Wong 编写的 Java Threads 比 Taming Java Threads 要轻量些，但是如果您从未编写过线程程序这本书更为适合。Oaks 和 Wong 同样实现了 Holub 提供的帮助类，而且看看对同一问题的不同解决方案总是有益的。 由 Bill Lewis 和 Daniel J. Berg　编写的 Threads Primer: A Guide to Multithreaded Programming 是对线程(不限于 Java)的很好入门介绍。 Java 线程的一些技术信息可在 Sun 网站 上找到。 在 "Multiprocessor Safety and Java" 中 Paul Jakubik 讨论了多线程系统的 SMP 问题。