Java线程模型缺陷

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 ，但是由于被第二个线程占据，所以无法获得。此时出现死锁。

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

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

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

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

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

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

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

　　嵌套监控锁定问题非常麻烦，我并没有简单的解决办法。嵌套监控锁定是一种死锁形式，当某个锁的占有线程在挂起其自身之前不释放锁时，会发生这种嵌套监控封锁。

　　此例中，在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 ”（和其它地方）中有详细讨论，概括地说：一个读写锁支持多个线程同时访问一个对象，但是在同一时刻只有一个线程可以修改此对象，并且在访问进行时不能修改。

　　对于一个对象，应该只有在$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 域，这样，程序员就不必担心这个问题。

　　后台线程的突然结束

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

　　对于这个问题，我建议制定规则，使 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 编程语言正在演变，所以还有可提高的前景。