Search Results

　　如果方法抛出的异常与它所执行的任务没有明显的联系，这种情形将会使人不知所措。当方法传递由低层抽象抛出的异常时，往往会发生这种情况。除了使人感到困惑之外，这也“污染”了具有实现细节的更高层的 API 。如果高层的实现在后续的发行版本中发生了变化，它所抛出的异常也可能会跟着发生变化，从而潜在地破坏现有的客户端程序。 　　为了避免这个问题， **更高层的实现应该捕获低层的异常，同时抛出可以按照高层抽象进行解释的异常。**这种做法称为异常转译 （exception translation），如下代码所示： /* Exc...

　　当许多线程可以运行时，线程调度器决定哪些线程可以运行以及运行多长时间。任何合理的操作系统都会尝试公平地做出这个决定，但是策略可能会有所不同。因此，编写良好的程序不应该依赖于此策略的细节。任何依赖线程调度器来保证正确性或性能的程序都可能是不可移植的。 　　编写健壮、响应快、可移植程序的最佳方法是确保可运行线程的平均数量不显著大于处理器的数量。这使得线程调度器几乎没有选择：它只运行可运行线程，直到它们不再可运行为止。即使在完全不同的线程调度策略下，程序的行为也没有太大的变化。注意，可运行线程的数量与线程总数不相同，...

　　本书旨在帮助您有效地使用 Java 编程语言及其基本库：java.lang，java.util 和 java.io 以及如 java.util.concurrent 和 java.util.function 等子包，其他库也会不时讨论。 　　这本书由九十项组成，每一个项传达一条规则。这些实践通常被最优秀和经验最丰富的程序员认为是有益的。这些项被松散地分为 11 章，每章涵盖软件设计的一个广泛方面。这本书并不打算让人从头到尾地阅读：每一项或多或少都是独立的。这些项被大量交叉引用，因此你可以很容易地规划你自己的阅读...

　　正如 85 条和第 86 条提到的，以及本章一直在讨论的，决定实现 Serializable 接口，会增加出错和出现安全问题的可能性，因为它允许利用语言之外的机制来创建实例，而不是使用普通的构造器。然而，有一种方法可以极大的减少这些风险。就是序列化代理模式（seralization proxy pattern）。 　　序列化代理模式相当简单。首先，为可序列化的类设计一个私有的静态嵌套类，精确地表示外围类的逻辑状态。这个嵌套类被称为序列化代理（seralization proxy），它应该有一个单独的构造器，其参...

　　第 3 条讲述了 Singletion（单例）模式，并且给出了以下这个 Singletion 示例。这个类限制了对其构造器的访问，以确保永远只创建一个实例。 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public void leaveTheBuilding() { ... } } 　　正如在第 3 条中所提到的，如果在这个类上面增...

　　第 50 条介绍了一个不可变的日期范围类，它包含可变的私有变量 Date。该类通过在其构造器和访问方法（accessor）中保护性的拷贝 Date 对象，极力维护其约束条件和不可变性。该类代码如下所示： // Immutable class that uses defensive copying public final class Period { private final Date start; private final Date end; /** * @param s...

　　当你在时间紧迫的情况下编写类时，通常应该将精力集中在设计最佳的 API 上。有时，这意味着发布一个「一次性」实现，你也知道在将来的版本中会替换它。通常这不是一个问题，但是如果类实现 Serializable 接口并使用默认的序列化形式，你将永远无法完全摆脱这个「一次性」的实现。它将永远影响序列化的形式。这不仅仅是一个理论问题。这种情况发生在 Java 库中的几个类上，包括 BigInteger。 　　在没有考虑默认序列化形式是否合适之前，不要接受它。 接受默认的序列化形式应该是一个三思而后行的决定，即从灵活性、...

　　使类的实例可序列化非常简单，只需实现 Serializable 接口即可。因为这很容易做到，所以有一个普遍的误解，认为序列化只需要程序员付出很少的努力。而事实上要复杂得多。虽然使类可序列化的即时代价可以忽略不计，但长期代价通常是巨大的。 　　实现 Serializable 接口的一个主要代价是，一旦类的实现被发布，它就会降低更改该类实现的灵活性。 当类实现 Serializable 时，其字节流编码（或序列化形式）成为其导出 API 的一部分。一旦广泛分发了一个类，通常就需要永远支持序列化的形式，就像需要支持导...

　　当序列化在 1997 年添加到 Java 中时，它被认为有一定的风险。这种方法曾在研究语言（Modula-3）中尝试过，但从未在生产语言中使用过。虽然程序员不费什么力气就能实现分布式对象，这一点很吸引人，但代价也不小，如：不可见的构造函数、API 与实现之间模糊的界线，还可能会出现正确性、性能、安全性和维护方面的问题。支持者认为收益大于风险，但历史证明并非如此。 　　在本书之前的版本中描述的安全问题，和人们担心的一样严重。21 世纪初仅停留在讨论的漏洞在接下来的 10 年间变成了真实严重的漏洞，其中最著名的包括...

　　延迟初始化是延迟字段的初始化，直到需要它的值。如果不需要该值，则不会初始化字段。这种技术既适用于静态字段，也适用于实例字段。虽然延迟初始化主要是一种优化，但是它也可以用于破坏类中的有害循环和实例初始化 [Bloch05, Puzzle 51]。 　　与大多数优化一样，延迟初始化的最佳建议是「除非需要，否则不要这样做」（详见第 67 条）。延迟初始化是一把双刃剑。它降低了初始化类或创建实例的成本，代价是增加了访问延迟初始化字段的成本。根据这些字段中最终需要初始化的部分、初始化它们的开销以及初始化后访问每个字段的频...

　　描述一个方法所抛出的异常，是正确使用这个方法时所需文档的重要组成部分。因此，花点时间仔细地为每个方法抛出的异常建立文档是特别重要的。 　　始终要单独地声明受检异常， 并且利用 Javadoc 的 ＠throws 标签， 准确地记录下抛出每个异常的条件。 如果一个公有方法可能抛出多个异常类，则不要使用“快捷方式”声明它会抛出这些异常类的某个超类。永远不要声明一个公有方法直接「throws Exception」，或者更糟糕的是声明它直接「throws Throwable」，这是非常极端的例子。这样的声明不仅没有为程...

　　类在其方法并发使用时的行为是其与客户端约定的重要组成部分。如果你没有记录类在这一方面的行为，那么它的用户将被迫做出假设。如果这些假设是错误的，生成的程序可能缺少足够的同步（详见 78 条）或过度的同步（详见 79 条）。无论哪种情况，都可能导致严重的错误。 　　你可能听说过，可以通过在方法的文档中查找 synchronized 修饰符来判断方法是否线程安全。这个观点有好些方面是错误的。在正常操作中，Javadoc 的输出中没有包含同步修饰符，这是有原因的。方法声明中 synchronized 修饰符的存在是实现...

　　本书第 1 版中专门用了一个条目来说明如何正确地使用 wait 和 notify ( Bloch01，详见第 50 条） 。它提出的建议仍然有效，并且在本条目的最后也对此做了概述，但是这条建议现在远远没有之前那么重要了。这是因为几乎没有理由再使用 wait 和 notify 了。自从 Java 5 发行版本开始， Java 平台就提供了更高级的并发工具，它们可以完成以前必须在 wait 和 notify 上手写代码来完成的各项工作。 既然正确地使用 wait 和 notify 比较困难，就应该用更高级的并发工具...

　　本书第 1 版中阐述了简单的工作队列（work queue）[Bloch01 ，详见第 49 条］代码。它利用一个后台线程，允许客户端可以插入异步处理任务到队列中。当不再需要这个工作队列时，客户端可以调用一个方法，让后台线程在完成队列中所有工作后，优雅的终止自己。这个实现仅比玩具复杂一点，即使这样，它依然需要整整一页精妙的代码，如果你不能正确的实现，将很容易会出现安全性和活性失败。幸运的是，你再不需要写这类代码了。 　　到本书第二版出版的时候， Java 平台中已经增加了 java.util.concurren...

　　第 78 条告诫过我们缺少同步的危险性。本条目则关注相反的问题。依据情况的不同，过度同步则可能导致性能降低、死锁，甚至不确定的行为。 　　为了避免活性失败和安全性失败，在一个被同步的方法或者代码块中，永远不要放弃对客户端的控制。 换句话说，在一个被同步的区域内部，不要调用设计成要被覆盖的方法，或者是由客户端以函数对象的形式提供的方法（详见第 24 条） 。从包含该同步区域的类的角度来看，这样的方法是外来的（ alien ） 。这个类不知道该方法会做什么事情，也无法控制它。根据外来方法的作用，从同步区域中调用它会...

　　关键字 synchronized 可以保证在同一时刻，只有一个线程可以执行某一个方法，或者某一个代码块。许多程序员把同步的概念仅仅理解为一种互斥（ mutual exclusion ）的方式，即，当一个对象被一个线程修改的时候，可以阻止另一个线程观察到对象内部不一致的状态。按照这种观点，对象被创建的时候处于一致的状态（详见第 17 条），当有方法访问它的时候，它就被锁定了。这些方法观察到对象的状态，并且可能会引起状态转变（ statetransition ），即把对象从一种一致的状态转换到另一种一致的状态。正确...

　　尽管这条建议看上去是显而易见的，但是它却常常被违反，因而值得再次提出来。当 API 的设计者声明一个方法将抛出某个异常的时候，他们等于正在试图说明某些事情。所以，请不要忽略它！要忽略一个异常非常容易，只需将方法调用通过 try 语句包围起来，并包含一个空的 catch 块： // Empty catch block ignores exception - Highly suspect! try { ... } catch ( SomeException e ) { } 　　空的 catch 块会使异常...

　　当对象抛出异常之后，通常我们期望这个对象仍然保持在一种定义良好的可用状态之中， 即使失败是发生在执行某个操作的过程中间。对于受检异常而言，这尤为重要，因为调用者期望能从这种异常中进行恢复。一般而言，失败的方法调用应该使对象保持在被调用之前的状态。 具有这种属性的方法被称为具有失败原子性 （failure atomic）。 　　有几种途径可以实现这种效果。最简单的办法莫过于设计一个不可变的对象 （详见第 17 条） 。如果对象是不可变的，失败原子性就是显然的。如果一个操作失败了，它可能会阻止创建新的对象，但是永远...

　　当程序由于未被捕获的异常而失败的时’候，系统会自动地打印出该异常的堆栈轨迹。在堆栈轨迹中包含该异常的字符串表示法 （string representation），即它的 toString 方法的调用结果。它通常包含该异常的类名，紧随其后的是细节消息 （detail message）。通常，这只是程序员或者网站可靠性工程师在调查软件失败原因时必须检查的信息。如果失败的情形不容易重现，要想获得更多的信息会非常困难，甚至是不可能的。因此，异常类型的 toString 方法应该尽可能多地返回有关失败原因的信息，这一点特...

Most of the time, you only want your code to run if something is true (or false). For example, say you want to find the smaller of two numbers: if the first number is less than the second, then that's what you want to return. If the second is less than the fir...