EffectiveJava - 出师之路

秒速五厘米 2022-10-07 13:56 21阅读 0赞

[Github免费阅读链接][Github]  
阿里巴巴开发者手册

> 仅供学习

### 文章目录 ###

*  Item 1: Consider static factory methods instead of constructors（考虑以静态工厂方法代替构造函数）
 *  Item 2: Consider a builder when faced with many constructor parameters（当构造函数有多个参数时，考虑改用构建器）
 *  Enforce the singleton property with a private constructor or an enum type（使用私有构造函数或枚举类型实施单例属性）
 *  Item 4: Enforce noninstantiability with a private constructor（用私有构造函数实施不可实例化）
 *  Item 5: Prefer dependency injection to hardwiring resources（依赖DI注入优于硬连接资源）
 *  Item 6: Avoid creating unnecessary objects（避免创建不必要的对象）
 *  Item 7: Eliminate obsolete object references（排除过时的对象引用）
 *  Item 8: Avoid finalizers and cleaners（避免使用终结器和清除器）
 *  Item 9: Prefer try-with-resources to try-finally（使用 try-with-resources 优于 try-finally）
 *  Item 10: Obey the general contract when overriding equals（覆盖 equals 方法时应遵守的约定）
 *   *  这里有一个高质量构建 equals 方法的秘诀
 *  Item 11: Always override hashCode when you override equals（当覆盖 equals 方法时，总要覆盖 hashCode 方法）
 *  Item 12: Always override toString（始终覆盖 toString 方法）
 *  Item 13: Override clone judiciously（明智地覆盖 clone 方法）
 *  Item 14: Consider implementing Comparable（考虑实现 Comparable 接口）
 *  Item 15: Minimize the accessibility of classes and members（尽量减少类和成员的可访问性）
 *  Item 16: In public classes, use accessor methods, not public fields（在公共类中，使用访问器方法，而不是公共字段）
 *  Item 17: Minimize mutability（减少可变性）
 *  Item 18: Favor composition over inheritance（优先选择复合而不是继承）
 *  Item 19: Design and document for inheritance or else prohibit it（继承要设计良好并且具有文档，否则禁止使用）
 *  Item 20: Prefer interfaces to abstract classes（接口优于抽象类）
 *  Item 21: Design interfaces for posterity（为后代设计接口）
 *  Item 22: Use interfaces only to define types（接口只用于定义类型）
 *  Item 23: Prefer class hierarchies to tagged classes（类层次结构优于带标签的类）
 *  Item 24: Favor static member classes over nonstatic（静态成员类优于非静态成员类）
 *  Item 25: Limit source files to a single top-level class（源文件仅限有单个顶层类）
 *  Item 26: Don’t use raw types（不要使用原始类型）
 *  Item 27: Eliminate unchecked warnings（消除 unchecked 警告）
 *  Item 28: Prefer lists to arrays（list 优于数组）
 *  Item 29: Favor generic types（优先使用泛型）
 *  Item 30: Favor generic methods（优先使用泛型方法）
 *  Item 31: Use bounded wildcards to increase API flexibility（使用有界通配符增加 API 的灵活性）
 *  Item 32: Combine generics and varargs judiciously（明智地合用泛型和可变参数）
 *  Item 33: Consider typesafe heterogeneous containers（考虑类型安全的异构容器）
 *  Item 34: Use enums instead of int constants（用枚举类型代替 int 常量）
 *  Item 35: Use instance fields instead of ordinals（使用实例字段替代序数）
 *  Item 36: Use EnumSet instead of bit fields（用 EnumSet 替代位字段）
 *  Item 37: Use EnumMap instead of ordinal indexing（使用 EnumMap 替换序数索引）
 *  Item 38: Emulate extensible enums with interfaces（使用接口模拟可扩展枚举）
 *  Item 39: Prefer annotations to naming patterns（注解优于命名模式）
 *  Item 40: Consistently use the Override annotation（坚持使用 @Override 注解）
 *  Item 41: Use marker interfaces to define types（使用标记接口定义类型）
 *  Item 42: Prefer lambdas to anonymous classes（λ 表达式优于匿名类）
 *  Item 43: Prefer method references to lambdas（方法引用优于 λ 表达式）
 *  Item 44: Favor the use of standard functional interfaces（优先使用标准函数式接口）
 *  Item 45: Use streams judiciously（明智地使用流）
 *  Item 46: Prefer side-effect-free functions in streams（在流中使用无副作用的函数）
 *  Item 47: Prefer Collection to Stream as a return type（优先选择 Collection 而不是流作为返回类型）
 *  Item 48: Use caution when making streams parallel（谨慎使用并行流）\*
 *  Item 49: Check parameters for validity（检查参数的有效性）
 *  Item 50: Make defensive copies when needed（在需要时制作防御性副本）
 *  Item 51: Design method signatures carefully（仔细设计方法签名）
 *  Item 52: Use overloading judiciously（明智地使用重载）
 *  Item 53: Use varargs judiciously（明智地使用可变参数）
 *  Item 54: Return empty collections or arrays, not nulls（返回空集合或数组，而不是 null）
 *  Item 55: Return optionals judiciously（明智地的返回 Optional）
 *  Item 56: Write doc comments for all exposed API elements（为所有公开的 API 元素编写文档注释）
 *  Item 57: Minimize the scope of local variables（将局部变量的作用域最小化）
 *  Item 58: Prefer for-each loops to traditional for loops（for-each 循环优于传统的 for 循环）
 *  Item 59: Know and use the libraries（了解并使用库）
 *  Item 60: Avoid float and double if exact answers are required（若需要精确答案就应避免使用 float 和 double 类型）
 *  Item 61: Prefer primitive types to boxed primitives（基本数据类型优于包装类）
 *  Item 62: Avoid strings where other types are more appropriate（其他类型更合适时应避免使用字符串）
 *  Item 63: Beware the performance of string concatenation（当心字符串连接引起的性能问题）
 *  Item 64: Refer to objects by their interfaces（通过接口引用对象）
 *  Item 65: Prefer interfaces to reflection（接口优于反射）
 *  Item 66: Use native methods judiciously（明智地使用本地方法）
 *  Item 67: Optimize judiciously（明智地进行优化）
 *  Item 68: Adhere to generally accepted naming conventions（遵守被广泛认可的命名约定）
 *  Item 69: Use exceptions only for exceptional conditions（仅在确有异常条件下使用异常）
 *  Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors（对可恢复情况使用 checked 异常，对编程错误使用运行时异常）
 *  Item 71: Avoid unnecessary use of checked exceptions（避免不必要地使用 checked 异常）
 *  Item 72: Favor the use of standard exceptions（鼓励复用标准异常）
 *  Item 73: Throw exceptions appropriate to the abstraction（抛出能用抽象解释的异常）
 *  Item 74: Document all exceptions thrown by each method（为每个方法记录会抛出的所有异常）
 *  Item 75: Include failure capture information in detail messages（异常详细消息中应包含捕获失败的信息）
 *  Item 76: Strive for failure atomicity（尽力保证故障原子性）
 *  Item 77: Don’t ignore exceptions（不要忽略异常）
 *  Item 78: Synchronize access to shared mutable data（对共享可变数据的同步访问）
 *  Item 79: Avoid excessive synchronization（避免过度同步）
 *  Item 80: Prefer executors, tasks, and streams to threads（Executor、task、流优于直接使用线程）
 *  Item 81: Prefer concurrency utilities to wait and notify（并发实用工具优于 wait 和 notify）
 *  Item 82: Document thread safety（文档应包含线程安全属性）
 *  Item 83: Use lazy initialization judiciously（明智地使用延迟初始化）
 *  Item 84: Don’t depend on the thread scheduler（不要依赖线程调度器）
 *  Item 85: Prefer alternatives to Java serialization（Java 序列化的替代方案）
 *  Item 86: Implement Serializable with great caution（非常谨慎地实现 Serializable）
 *  Item 87: Consider using a custom serialized form（考虑使用自定义序列化形式）
 *  Item 88: Write readObject methods defensively（防御性地编写 readObject 方法）
 *  Item 89: For instance control, prefer enum types to readResolve（对于实例控制，枚举类型优于 readResolve）
 *  Item 90: Consider serialization proxies instead of serialized instances（考虑以序列化代理代替序列化实例）

# Item 1: Consider static factory methods instead of constructors（考虑以静态工厂方法代替构造函数） #

静态工厂方法不需要在每次调用时创建新对象。对象可控。其次，命名可控，在很多情况下，多个构造函数属于重载，在使用时可能会造成不知道怎么选择构造函数，或者表意不清的情况。选择静态工程方法，可以通过命名表出其需要参数，以及返回对象含义。另外，此item应有别与设计模式的工厂模式，其经验之谈可以属于一种良好的代码规范。  
第三，可以通过静态工厂方法获取返回类型的任何子类的对象。但是在很多情况下，如果没有比较好的文档说明，当你去创建一个对象的时候，可能没有意识到其实可以通过静态工程方法，即其类方法来轻易获取一个对象。

# Item 2: Consider a builder when faced with many constructor parameters（当构造函数有多个参数时，考虑改用构建器） #

建造者模式的链式处理是一个较好的方案，去处理参数过多，参数非空或特定值等情况。其实还有在对象创建完成之前不允许使用对象的情况。

// Builder Pattern
    public class NutritionFacts { 
        private final int servingSize;
        private final int servings;
        private final int calories;
        private final int fat;
        private final int sodium;
        private final int carbohydrate;
    
        public static class Builder { 
            // Required parameters
            private final int servingSize;
            private final int servings;
            // Optional parameters - initialized to default values
            private int calories = 0;
            private int fat = 0;
            private int sodium = 0;
            private int carbohydrate = 0;
    
            public Builder(int servingSize, int servings) { 
                this.servingSize = servingSize;
                this.servings = servings;
            }
    
            public Builder calories(int val) { 
                calories = val;
                return this;
            }
    
            public Builder fat(int val) { 
                fat = val;
                return this;
            }
    
            public Builder sodium(int val) { 
                sodium = val;
                return this;
            }
    
            public Builder carbohydrate(int val) { 
                carbohydrate = val;
                return this;
            }
    
            public NutritionFacts build() { 
                return new NutritionFacts(this);
            }
        }
    
        private NutritionFacts(Builder builder) { 
            servingSize = builder.servingSize;
            servings = builder.servings;
            calories = builder.calories;
            fat = builder.fat;
            sodium = builder.sodium;
            carbohydrate = builder.carbohydrate;
        }
    }

建造者模式非常适合于类层次结构。使用构建器的并行层次结构，每个构建器都嵌套在相应的类中。抽象类有抽象类构建器；具体类有具体类构建器。  
每个内部 Builder 类要对每个字段建立相应方法，代码比较冗长。若将「构建机制」独立出来，或能广泛适应相似结构的构建需求。以下是针对原文案例的简要修改，仅供参考：

class EntityCreator<T> { 
    
        private Class<T> classInstance;
        private T entityObj;
    
        public EntityCreator(Class<T> classInstance, Object... initParams) throws Exception { 
            this.classInstance = classInstance;
            Class<?>[] paramTypes = new Class<?>[initParams.length];
            for (int index = 0, length = initParams.length; index < length; index++) { 
                String checkStr = initParams[index].getClass().getSimpleName();
                if (checkStr.contains("Integer")) { 
                    paramTypes[index] = int.class;
                }
                if (checkStr.contains("Double")) { 
                    paramTypes[index] = double.class;
                }
                if (checkStr.contains("Boolean")) { 
                    paramTypes[index] = boolean.class;
                }
                if (checkStr.contains("String")) { 
                    paramTypes[index] = initParams[index].getClass();
                }
            }
            Constructor<T> constructor = classInstance.getDeclaredConstructor(paramTypes);
            constructor.setAccessible(true);
            this.entityObj = constructor.newInstance(initParams);
        }
    
        public EntityCreator<T> setValue(String paramName, Object paramValue) throws Exception { 
            Field field = classInstance.getDeclaredField(paramName);
            field.setAccessible(true);
            field.set(entityObj, paramValue);
            return this;
        }
    
        public T build() { 
            return entityObj;
        }
    }

# Enforce the singleton property with a private constructor or an enum type（使用私有构造函数或枚举类型实施单例属性） #

[参见线程安全的单例模式][Link 1]  
为了使一个单例类变成可串行化的，仅仅在声明中添加“implements Serializable”是不够的。因为一个串行化的对象在每次返串行化的时候，都会创建一个新的对象，而不仅仅是一个对原有对象的引用。为了防止这种情况，可以在单例类中加入readResolve 方法。否则，每次反序列化实例时，都会创建一个新实例。

# Item 4: Enforce noninstantiability with a private constructor（用私有构造函数实施不可实例化） #

# Item 5: Prefer dependency injection to hardwiring resources（依赖DI注入优于硬连接资源） #

// Dependency injection provides flexibility and testability
    public class SpellChecker { 
    	//声明
        private final Lexicon dictionary;
        public SpellChecker(Lexicon dictionary) { 
            this.dictionary = Objects.requireNonNull(dictionary);
        }
        public boolean isValid(String word) {  ... }
        public List<String> suggestions(String typo) {  ... }
    }

并设计传递资源，那么这个类其实可以使用多种Lexicon的实现方式。

# Item 6: Avoid creating unnecessary objects（避免创建不必要的对象） #

复用单个对象通常是合适的，不必每次需要时都创建一个新的功能等效对象。复用可以更快、更流行。如果对象是不可变的，那么它总是可以被复用的。  
通过维护自己的对象池来避免创建对象不是一个好主意，除非池中的对象非常重量级。证明对象池是合理的对象的典型例子是数据库连接。建立连接的成本非常高，因此复用这些对象是有意义的。然而，一般来说，维护自己的对象池会使代码混乱，增加内存占用，并损害性能。现代 JVM 实现具有高度优化的垃圾收集器，在轻量级对象上很容易胜过这样的对象池。

**基本类型优于包装类，还应提防意外的自动装箱。**

# Item 7: Eliminate obsolete object references（排除过时的对象引用） #

解决途径，引用置null，作用域，weakhashmap

# Item 8: Avoid finalizers and cleaners（避免使用终结器和清除器） #

# Item 9: Prefer try-with-resources to try-finally（使用 try-with-resources 优于 try-finally） #

代码冗余，异常不易跟踪。建议使用try-with-resources：

// try-with-resources - the the best way to close resources!
    static String firstLineOfFile(String path) throws IOException { 
        try (BufferedReader br = new BufferedReader(new FileReader(path))) { 
            return br.readLine();
        }
    }

// try-with-resources on multiple resources - short and sweet
    static void copy(String src, String dst) throws IOException { 
        try (InputStream in = new FileInputStream(src);OutputStream out = new FileOutputStream(dst)) { 
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0)
                out.write(buf, 0, n);
        }
    }

# Item 10: Obey the general contract when overriding equals（覆盖 equals 方法时应遵守的约定） #

*  类的每个实例本质上都是唯一的。
 *  该类不需要提供「逻辑相等」测试。
 *  超类已经覆盖了 equals，超类行为适合于这个类。
 *  类是私有的或包私有的，并且你确信它的 equals 方法永远不会被调用。

equals 方法实现了等价关系。它应有这些属性：

反身性：对于任何非空的参考值 x，x.equals(x) 必须返回 true。

对称性：对于任何非空参考值 x 和 y，x.equals(y) 必须在且仅当 y.equals(x) 返回 true 时返回 true。

传递性：对于任何非空的引用值 x, y, z，如果 x.equals(y) 返回 true，y.equals(z) 返回 true，那么 x.equals(z) 必须返回 true。

一致性：对于任何非空的引用值 x 和 y, x.equals(y) 的多次调用必须一致地返回 true 或一致地返回 false，前提是不修改 equals 中使用的信息。

对于任何非空引用值 x，x.equals(null) 必须返回 false。

## 这里有一个高质量构建 equals 方法的秘诀 ##

1.  使用 == 运算符检查参数是否是对该对象的引用。 如果是，返回 true。这只是一种性能优化，但如果比较的代价可能很高，那么这种优化是值得的。
2.  使用 instanceof 运算符检查参数是否具有正确的类型。 如果不是，返回 false。通常，正确的类型是方法发生的类。有时候，它是由这个类实现的某个接口。如果类实现了一个接口，该接口对 equals 约定进行了改进，以允许跨实现该接口的类进行比较，则使用该接口。集合接口，如 Set、List、Map 和 Map.Entry 具有此属性。
3.  将参数转换为正确的类型。 因为在这个强制类型转换之前有一个实例测试，所以它肯定会成功。
4.  对于类中的每个「重要」字段，检查参数的字段是否与该对象的相应字段匹配。 如果所有这些测试都成功，返回 true；否则返回 false。如果第 2 步中的类型是接口，则必须通过接口方法访问参数的字段；如果是类，你可以根据字段的可访问性直接访问它们。

对于类型不是 float 或 double 的基本类型字段，使用 == 运算符进行比较；对于对象引用字段，递归调用 equals 方法；对于 float 字段，使用 static Float.compare(float,float) 方法；对于 double 字段，使用 Double.compare(double, double)。float 和 double 字段的特殊处理是由于 Float.NaN、-0.0f 和类似的双重值的存在而必须的；请参阅 JLS 15.21.1 或 Float.equals 文档。虽然你可以将 float 和 double 字段与静态方法 Float.equals 和 Double.equals 进行比较，这将需要在每个比较上进行自动装箱，这将有较差的性能。对于数组字段，将这些指导原则应用于每个元素。如果数组字段中的每个元素都很重要，那么使用 Arrays.equals 方法之一。

# Item 11: Always override hashCode when you override equals（当覆盖 equals 方法时，总要覆盖 hashCode 方法） #

在覆盖了 equals 方法的类中，必须覆盖 hashCode 方法。 如果你没有这样做，该类将违反 hashCode 方法的一般约定，这将阻止该类在 HashMap 和 HashSet 等集合中正常运行。  
当你无法覆盖 hashCode 方法时，将违反第二个关键条款：相等的对象必须具有相等的散列码。  
一个好的散列算法倾向于为不相等的实例生成不相等的散列码。这正是 hashCode 方法约定第三部分的含义。理想情况下，一个散列算法应该在所有 int 值上均匀合理分布所有不相等实例集合。

有一个简单的办法生成hashcode：

1.  声明一个名为 result 的 int 变量，并将其初始化为对象中第一个重要字段的散列码 c，如步骤 2.a 中计算的那样。（回想一下 Item-10 中的重要字段会对比较产生影响）
2.  对象中剩余的重要字段 f，执行以下操作：  
    a. 为字段计算一个整数散列码 c：  
    i.如果字段是基本数据类型，计算 Type.hashCode(f)，其中 type 是与 f 类型对应的包装类。  
    ii.如果字段是对象引用，并且该类的 equals 方法通过递归调用 equals 方法来比较字段，则递归调用字段上的 hashCode 方法。如果需要更复杂的比较，则为该字段计算一个「canonical representation」，并在 canonical representation 上调用 hashCode 方法。如果字段的值为空，则使用 0（或其他常数，但 0 是惯用的）。  
    iii.如果字段是一个数组，则将其每个重要元素都视为一个单独的字段。也就是说，通过递归地应用这些规则计算每个重要元素的散列码，并将每个步骤 2.b 的值组合起来。如果数组中没有重要元素，则使用常量，最好不是 0。如果所有元素都很重要，那么使用 Arrays.hashCode。  
    b. 将步骤 2.a 中计算的散列码 c 合并到 result 变量，如下所示：  
    result = 31 \* result + c;  
    3、Return result.  
    返回 result 变量

**选择 31 是因为它是奇素数。如果是偶数，乘法运算就会溢出，信息就会丢失，因为乘法运算等同于移位。使用素数的好处不太明显，但它是传统用法。31 有一个很好的特性，可以用移位和减法来代替乘法，从而在某些体系结构上获得更好的性能：31 \* i == (i <<5) – i。现代虚拟机自动进行这种优化。**

com.google.common.hash.Hashing \[Guava\] 存在比较优秀的hash算法。

# Item 12: Always override toString（始终覆盖 toString 方法） #

虽然 Object 提供 toString 方法的实现，但它返回的字符串通常不是类的用户希望看到的。它由后跟「at」符号（@）的类名和 hash 代码的无符号十六进制表示（例如 PhoneNumber@163b91）组成。toString 的通用约定是这么描述的，返回的字符串应该是「简洁但信息丰富的表示，易于阅读」。虽然有人认为 PhoneNumber@163b91 简洁易懂，但与 707-867-5309 相比，它的信息量并不大。toString 约定接着描述，「建议所有子类覆盖此方法。」

# Item 13: Override clone judiciously（明智地覆盖 clone 方法） #

[贴个链接][Link 2]

# Item 14: Consider implementing Comparable（考虑实现 Comparable 接口） #

一个类实现 Comparable，表明实例具有自然顺序。对实现 Comparable 的对象数组进行排序非常简单：

Arrays.sort(a);

**例如，考虑 BigDecimal 类，它的 compareTo 方法与 equals 不一致。如果你创建一个空的 HashSet 实例，然后添加 new BigDecimal(“1.0”) 和 new BigDecimal(“1.00”)，那么该 HashSet 将包含两个元素，因为添加到该集合的两个 BigDecimal 实例在使用 equals 方法进行比较时结果是不相等的。但是，如果你使用 TreeSet 而不是 HashSet 执行相同的过程，那么该集合将只包含一个元素，因为使用 compareTo 方法比较两个 BigDecimal 实例时结果是相等的。**

在 Java 8 中，Comparator 接口配备了一组比较器构造方法，可以流畅地构造比较器。然后可以使用这些比较器来实现 Comparator 接口所要求的 compareTo 方法。。Comparator 类提供的构造方法覆盖了所有 Java 数值基本类型。总之，无论何时实现具有排序性质的值类，都应该让类实现 Comparable 接口，这样就可以轻松地对实例进行排序、搜索，并与依赖于此接口的集合实现进行互操作。在 compareTo 方法的实现中比较字段值时，避免使用 < 和 > 操作符，应使用包装类中的静态比较方法或 Comparator 接口中的 comparator 构造方法。

# Item 15: Minimize the accessibility of classes and members（尽量减少类和成员的可访问性） #

经验法则很简单：让每个类或成员尽可能不可访问。换句话说，在不影响软件正常功能时，使用尽可能低的访问级别。  
对于顶级（非嵌套）类和接口，只有两个可能的访问级别：包私有和公共。如果用 public 修饰符声明一个顶级类或接口，它将是公共的；否则，它将是包私有的。如果顶级类或接口可以设置为包私有，那么就应该这么做。通过将其设置为包私有，可以使其成为实现的一部分，而不是导出的 API 的一部分，并且可以在后续版本中修改、替换或删除它，而不必担心损害现有的客户端。如果将其公开，就有义务永远提供支持，以保持兼容性。

对于成员（字段、方法、嵌套类和嵌套接口），有四个可能的访问级别，这里按可访问性依次递增的顺序列出：

*  private  
    私有，成员只能从声明它的顶级类内部访问。
 *  package-private  
    包级私有，成员可以从包中声明它的任何类访问。技术上称为默认访问，即如果没有指定访问修饰符（接口成员除外，默认情况下，接口成员是公共的），就会得到这个访问级别。
 *  protected  
    保护，成员可以通过声明它的类的子类（会受一些限制 \[JLS, 6.6.2\]）和声明它的包中的任何类访问。
 *  public  
    公共，该成员可以从任何地方访问。

**带有公共可变字段的类通常不是线程安全的。**

除了作为常量的公共静态 final 字段外，public 类应该没有公共字段。确保公共静态 final 字段引用的对象是不可变的。

# Item 16: In public classes, use accessor methods, not public fields（在公共类中，使用访问器方法，而不是公共字段） #

// Encapsulation of data by accessor methods and mutators
    class Point { 
        private double x;
        private double y;
        public Point(double x, double y) { 
            this.x = x;
            this.y = y;
        }
        public double getX() {  return x; }
        public double getY() {  return y; }
        public void setX(double x) {  this.x = x; }
        public void setY(double y) {  this.y = y; }
    }

# Item 17: Minimize mutability（减少可变性） #

不可变类是实例不能被修改的类。每个实例中包含的所有信息在对象的生命周期内都是固定的，因此永远不会观察到任何更改。Java 库包含许多不可变的类，包括 String、基本类型的包装类、BigInteger 和 BigDecimal。这么做有很好的理由：不可变类比可变类更容易设计、实现和使用。它们不太容易出错，而且更安全。

要使类不可变，请遵循以下 5 条规则：

*  不要提供修改对象状态的方法（这类方法也被称为修改器）
 *  确保类不能被继承。
 *  所有字段用 final 修饰。
 *  所有字段设为私有。
 *  确保对任何可变组件的独占访问。

**值得注意的是，算术操作创建和返回一个新的 Complex 实例，而不是修改这个实例。这种模式称为函数式方法，因为方法返回的结果是将函数应用到其操作数，而不是修改它。**

不可变对象本质上是线程安全的；它们不需要同步。 它们不会因为多线程并发访问而损坏。这无疑是实现线程安全的最简单方法。由于任何线程都无法观察到另一个线程对不可变对象的任何影响，因此 可以自由共享不可变对象。 同时，不可变类应该鼓励客户端尽可能复用现有的实例。一种简单的方法是为常用值提供公共静态 final 常量。

不可变类可以提供静态工厂（Item-1），这些工厂缓存经常请求的实例，以避免在现有实例可用时创建新实例。所有包装类和 BigInteger 都是这样做的。使用这种静态工厂会导致客户端共享实例而不是创建新实例，从而减少内存占用和垃圾收集成本。在设计新类时，选择静态工厂而不是公共构造函数，这将使你能够灵活地在以后添加缓存，而无需修改客户端。

优秀的不可变类的设计方式如下：

// Immutable class with static factories instead of constructors
    public class Complex {
        private final double re;
        private final double im;
        private Complex(double re, double im) {
            this.re = re;
            this.im = im;
        }
        public static Complex valueOf(double re, double im) {
            return new Complex(re, im);
        }
        ... // Remainder unchanged
    }

CountDownLatch 类体现了这些原则。它是可变的，但是它的状态空间故意保持很小。创建一个实例，使用它一次，它就完成了使命：一旦倒计时锁存器的计数达到零，你可能不会复用它。

# Item 18: Favor composition over inheritance（优先选择复合而不是继承） #

与其扩展现有类，不如为新类提供一个引用现有类实例的私有字段。这种设计称为复合，因为现有的类是新类的一个组件。新类中的每个实例方法调用现有类实例的对应方法，并返回结果。这称为转发，新类中的方法称为转发方法。生成的类将非常坚固，不依赖于现有类的实现细节。即使向现有类添加新方法，也不会对新类产生影响。

这里有一个使用复合和转发方法的案例，用以替代 InstrumentedHashSet。

// Wrapper class - uses composition in place of inheritance
    public class InstrumentedSet<E> extends ForwardingSet<E> { 
    
        private int addCount = 0;
    
        public InstrumentedSet(Set<E> s) { 
            super(s);
        }
    
        @Override
        public boolean add(E e) { 
            addCount++;
            return super.add(e);
        }
    
        @Override
        public boolean addAll(Collection<? extends E> c) { 
            addCount += c.size();
            return super.addAll(c);
        }
    
        public int getAddCount() { 
            return addCount;
        }
    }
    
    // Reusable forwarding class
    public class ForwardingSet<E> implements Set<E> { 
        private final Set<E> s;
        public ForwardingSet(Set<E> s) {  this.s = s; }
        public void clear() {  s.clear(); }
        public boolean contains(Object o) {  return s.contains(o); }
        public boolean isEmpty() {  return s.isEmpty(); }
        public int size() {  return s.size(); }
        public Iterator<E> iterator() {  return s.iterator(); }
        public boolean add(E e) {  return s.add(e); }
        public boolean remove(Object o) {  return s.remove(o); }
        public boolean containsAll(Collection<?> c)
        {  return s.containsAll(c); }
        public boolean addAll(Collection<? extends E> c)
        {  return s.addAll(c); }
        public boolean removeAll(Collection<?> c)
        {  return s.removeAll(c); }
        public boolean retainAll(Collection<?> c)
        {  return s.retainAll(c); }
        public Object[] toArray() {  return s.toArray(); }
        public <T> T[] toArray(T[] a) {  return s.toArray(a); }
    
        @Override
        public boolean equals(Object o){  return s.equals(o); }
    
        @Override
        public int hashCode() {  return s.hashCode(); }
    
        @Override
        public String toString() {  return s.toString(); }
    }

包装器类的缺点很少。一个需要注意的点是：包装器类不适合在回调框架中使用，在回调框架中，对象为后续调用(「回调」)将自定义传递给其他对象。因为包装对象不知道它对应的包装器，所以它传递一个对它自己的引用（this），回调避开包装器。这就是所谓的「自用」问题。有些人担心转发方法调用的性能影响或包装器对象的内存占用影响。这两种方法在实践中都没有多大影响。编写转发方法很麻烦，但是你必须只为每个接口编写一次可复用的转发类，而且可能会为你提供转发类。

只有子类确实是超类的子类型的情况下，继承才合适。换句话说，两个类 A、B 之间只有 B 满足「is-a」关系时才应该扩展 A。如果你想让 B 扩展 A，那就问问自己：每个 B 都是 A 吗？如果不能对这个问题给出肯定回答，B 不应该扩展 A；如果答案是否定的，通常情况下，B 应该包含 A 的私有实例并暴露不同的 API：A 不是 B 的基本组成部分，而仅仅是其实现的一个细节。

在 Java 库中有许多明显违反这一原则的地方。例如，stack 不是 vector，因此 Stack 不应该继承 Vector。类似地，property 列表不是 hash 表，因此 Properties 不应该继承 Hashtable。在这两种情况下，复合都是可取的。

如果在复合适用的地方使用了继承，就会不必要地暴露实现细节。生成的 API 将你与原始实现绑定在一起，永远限制了类的性能。更严重的是，通过暴露内部组件，你可以让客户端直接访问它们。至少，它会导致语义混乱。例如，如果 p 引用了一个 Properties 类的实例，那么 p.getProperty(key) 可能会产生与 p.get(key) 不同的结果：前者考虑了默认值，而后者（从 Hashtable 继承而来）则不会。最严重的是，客户端可以通过直接修改超类来破坏子类的不变量。对于 Properties 类，设计者希望只允许字符串作为键和值，但是直接访问底层 Hashtable 允许违反这个不变性。一旦违反，就不再可能使用 Properties API 的其他部分（加载和存储）。当发现这个问题时，已经来不及纠正了，因为客户端依赖于非字符串键和值的使用。

# Item 19: Design and document for inheritance or else prohibit it（继承要设计良好并且具有文档，否则禁止使用） #

# Item 20: Prefer interfaces to abstract classes（接口优于抽象类） #

1、抽象类的局限：一个类要实现抽象类定义的类型，该类必须是抽象类的子类。因为 Java 只允许单一继承，这种限制对抽象类而言严重制约了它们作为类型定义的使用。

2、接口的优点：任何定义了所有必需的方法并遵守通用约定的类都允许实现接口，而不管该类驻留在类层次结构中何处。

但是，你可以通过提供一个抽象骨架实现类来结合接口和抽象类的优点。接口定义了类型，可能提供了一些默认方法，而骨架实现类在基本接口方法之上实现了其余的非基本接口方法。扩展骨架实现需要完成实现接口的大部分工作。这是模板方法模式 \[Gamma95\]。  
按照惯例，骨架实现类称为 AbstractInterface，其中 Interface 是它们实现的接口的名称。例如，Collections Framework 提供了一个骨架实现来配合每个主要的集合接口：AbstractCollection、AbstractSet、AbstractList 和 AbstractMap。可以说，将它们称为 SkeletalCollection、SkeletalSet、SkeletalList 和 SkeletalMap 是有意义的，但 Abstract 的用法现在已经根深蒂固。如果设计得当，骨架实现（无论是单独的抽象类，还是仅仅由接口上的默认方法组成）可以使程序员非常容易地提供他们自己的接口实现。

# Item 21: Design interfaces for posterity（为后代设计接口） #

默认方法的声明包括一个默认实现，所有实现接口但不实现默认方法的类都使用这个默认实现。虽然 Java 使得向现有接口添加方法成为可能，但不能保证这些方法在所有现有实现中都能工作。默认方法被「注入」到现有的实现中，而无需实现者的知情或同意。在 Java 8 之前，编写这些实现时都默认它们的接口永远不会获得任何新方法。

尽管默认方法现在已经是 Java 平台的一部分，但是谨慎地设计接口仍然是非常重要的。虽然默认方法使向现有接口添加方法成为可能，但这样做存在很大风险。 如果一个接口包含一个小缺陷，它可能会永远影响它的使用者；如果接口有严重缺陷，它可能会毁掉包含它的 API。

# Item 22: Use interfaces only to define types（接口只用于定义类型） #

不要使用接口定义常量。

# Item 23: Prefer class hierarchies to tagged classes（类层次结构优于带标签的类） #

标签类很少有合适的使用场景。如果想编写一个带有显式标签字段的类，请考虑是否可以删除标签并用层次结构替换。当遇到具有标签字段的现有类时，请考虑将其重构为层次结构。

# Item 24: Favor static member classes over nonstatic（静态成员类优于非静态成员类） #

如果声明的成员类不需要访问外部的实例，那么应始终在声明中添加 static 修饰符，使其成为静态的而不是非静态的成员类。如果省略这个修饰符，每个实例都有一个隐藏的对其外部实例的额外引用。如前所述，存储此引用需要时间和空间。更糟糕的是，它可能会在满足进行垃圾收集条件时仍保留外部类的实例（Item-7）。由于引用是不可见的，因此通常很难检测到。

私有静态成员类的一个常见用法是表示由其外部类表示的对象的组件。例如，考虑一个 Map 实例，它将 key 与 value 关联起来。许多 Map 实现的内部对于映射中的每个 key-value 对都有一个 Entry 对象。虽然每个 entry 都与 Map 关联，但 entry 上的方法（getKey、getValue 和 setValue）不需要访问 Map。因此，使用非静态成员类来表示 entry 是浪费：私有静态成员类是最好的。如果你不小心在 entry 声明中省略了静态修饰符，那么映射仍然可以工作，但是每个 entry 都包含对 Map 的多余引用，这会浪费空间和时间。

如果所讨论的类是导出类的公共成员或受保护成员，那么在静态成员类和非静态成员类之间正确选择就显得尤为重要。在本例中，成员类是导出的 API 元素，在后续版本中，不能在不违反向后兼容性的情况下将非静态成员类更改为静态成员类。

# Item 25: Limit source files to a single top-level class（源文件仅限有单个顶层类） #

就是不要定义两个并行的类

// Two classes defined in one file. Don't ever do this!
    class Utensil { 
        static final String NAME = "pot";
    }
    
    class Dessert { 
        static final String NAME = "pie";
    }

# Item 26: Don’t use raw types（不要使用原始类型） #

使用泛型

# Item 27: Eliminate unchecked warnings（消除 unchecked 警告） #

当你使用泛型编程时，你将看到许多编译器警告：unchecked 强制转换警告、unchecked 方法调用警告、unchecked 可变参数类型警告和 unchecked 自动转换警告。使用泛型的经验越丰富，遇到的警告就越少，但是不要期望新编写的代码能够完全正确地编译。

**如果不能消除警告，但是可以证明引发警告的代码是类型安全的，那么（并且只有在那时）使用 SuppressWarnings(“unchecked”) 注解来抑制警告。**

SuppressWarnings 注解可以用于任何声明中，从单个局部变量声明到整个类。总是在尽可能小的范围上使用 SuppressWarnings 注解。 通常用在一个变量声明或一个非常短的方法或构造函数。不要在整个类中使用 SuppressWarnings。这样做可能会掩盖关键警告。

每次使用 SuppressWarnings(“unchecked”) 注解时，要添加一条注释，说明这样做是安全的。 这将帮助他人理解代码，更重要的是，它将降低其他人修改代码而产生不安全事件的几率。如果你觉得写这样的注释很难，那就继续思考合适的方式。你最终可能会发现，unchecked 操作毕竟是不安全的。

# Item 28: Prefer lists to arrays（list 优于数组） #

数组和泛型之间的第二个主要区别：数组是具体化的 \[JLS, 4.7\]。这意味着数组在运行时知道并强制执行他们的元素类型。如前所述，如果试图将 String 元素放入一个 Long 类型的数组中，就会得到 ArrayStoreException。相比之下，泛型是通过擦除来实现的 \[JLS, 4.6\]。这意味着它们只在编译时执行类型约束，并在运行时丢弃（或擦除）元素类型信息。擦除允许泛型与不使用泛型的遗留代码自由交互操作（Item-26），确保在 Java 5 中平稳地过渡。

总之，数组和泛型有非常不同的类型规则。数组是协变的、具体化的；泛型是不变的和可被擦除的。因此，数组提供了运行时类型安全，而不是编译时类型安全，对于泛型反之亦然。一般来说，数组和泛型不能很好地混合。如果你发现将它们混合在一起并得到编译时错误或警告，那么你的第一个反应该是将数组替换为 list。

# Item 29: Favor generic types（优先使用泛型） #

class DelayQueue<E extends Delayed> implements BlockingQueue<E>

# Item 30: Favor generic methods（优先使用泛型方法） #

# Item 31: Use bounded wildcards to increase API flexibility（使用有界通配符增加 API 的灵活性） #

里氏替换原则指出：任何父类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当衍生类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而衍生类也能够在父类的基础上增加新的行为。

// Wildcard type for a parameter that serves as an E producer
    public void pushAll(Iterable<? extends E> src) { 
        for (E e : src)
            push(e);
    }
    // Wildcard type for parameter that serves as an T producer
    public Chooser(Collection<? extends T> choices)

但是不要使用有界通配符类型作为返回类型。 它将强制用户在客户端代码中使用通配符类型，而不是为用户提供额外的灵活性。

如果你编写的库将被广泛使用，则必须考虑通配符类型的正确使用。记住基本规则：生产者使用 extends，消费者使用 super（PECS）。还要记住，所有的 comparable 和 comparator 都是消费者。

# Item 32: Combine generics and varargs judiciously（明智地合用泛型和可变参数） #

如果选择使用泛型（或参数化）可变参数编写方法，首先要确保该方法是类型安全的，然后使用 @SafeVarargs 对其进行注释，不然可能会出现问题。

// Safe method with a generic varargs parameter
    @SafeVarargs
    static <T> List<T> flatten(List<? extends T>... lists) { 
      List<T> result = new ArrayList<>();
      for (List<? extends T> list : lists)
        result.addAll(list);
      return result;
    }

# Item 33: Consider typesafe heterogeneous containers（考虑类型安全的异构容器） #

# Item 34: Use enums instead of int constants（用枚举类型代替 int 常量） #

枚举是通过 public static final 修饰的字段为每个枚举常量导出一个实例的类。枚举类型实际上是 final 类型，因为没有可访问的构造函数。客户端既不能创建枚举类型的实例，也不能继承它，所以除了声明的枚举常量之外，不能有任何实例。换句话说，枚举类型是实例受控的类。  
要将数据与枚举常量关联，可声明实例字段并编写一个构造函数，该构造函数接受数据并将其存储在字段中。

# Item 35: Use instance fields instead of ordinals（使用实例字段替代序数） #

不要从枚举的序数派生与枚举关联的值；而是将其存储在实例字段中

public enum Ensemble { 
        SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5),SEXTET(6), SEPTET(7), OCTET(8), DOUBLE_QUARTET(8),NONET(9), DECTET(10),TRIPLE_QUARTET(12);
    
        private final int numberOfMusicians;
    
        Ensemble(int size) {  this.numberOfMusicians = size; }
    
        public int numberOfMusicians() {  return numberOfMusicians; }
    }

# Item 36: Use EnumSet instead of bit fields（用 EnumSet 替代位字段） #

> EnumSet 是一个专为枚举设计的集合类，EnumSet中的所有元素都必须是指定枚举类型的枚举值，该枚举类型在创建EnumSet时显式或隐式地指定。  
> EnumSet的集合元素也是有序的，EnumSet以枚举值在Enum类内的定义顺序来决定集合元素的顺序。  
> EnumSet在内部以位向量的形式存储，这种存储形式非常紧凑、高效,因此EnumSet对象占用内存很小，而且运行效率很好。尤其是进行批量操作（如调用containsAll()和retainAll()方法）时，如果其参数也是EnumSet集合，则该批量操作的执行速度也非常快。  
> EnumSet集合不允许加入null元素，如果试图插入null元素，EnumSet将抛出NullPointerException异常。  
> EnumSet类没有暴露任何构造器来创建该类的实例，程序应该通过它提供的类方法来创建EnumSet对象。  
> 如果只是想判断EnumSet是否包含null元素或试图删除null元素都不会抛出异常，只是删除操作将返回false，因为没有任何null元素被删除。

// Bit field enumeration constants - 过时
    public class Text { 
        public static final int STYLE_BOLD = 1 << 0; // 1
        public static final int STYLE_ITALIC = 1 << 1; // 2
        public static final int STYLE_UNDERLINE = 1 << 2; // 4
        public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8
        // Parameter is bitwise OR of zero or more STYLE_ constants
        public void applyStyles(int styles) {  ... }
    }

位字段表示方式允许使用位运算高效地执行 Set 操作，如并集和交集。但是位字段具有 int 枚举常量所有缺点，甚至更多。当位字段被打印为数字时，它比简单的 int 枚举常量更难理解。没有一种简单的方法可以遍历由位字段表示的所有元素。最后，你必须预测在编写 API 时需要的最大位数，并相应地为位字段（通常是 int 或 long）选择一种类型。一旦选择了一种类型，在不更改 API 的情况下，不能超过它的宽度（32 或 64 位）。

// EnumSet - a modern replacement for bit fields
    public class Text { 
        public enum Style {  BOLD, ITALIC, UNDERLINE, STRIKETHROUGH }
        // Any Set could be passed in, but EnumSet is clearly best
        public void applyStyles(Set<Style> styles) {  ... }
    }

text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));

一些使用枚举而不是 int 常量的程序员在需要传递常量集时仍然坚持使用位字段。没有理由这样做，因为存在更好的选择。java.util 包提供 EnumSet 类来有效地表示从单个枚举类型中提取的值集。这个类实现了 Set 接口，提供了所有其他 Set 实现所具有的丰富性、类型安全性和互操作性。但在内部，每个 EnumSet 都表示为一个位向量。如果底层枚举类型有 64 个或更少的元素（大多数都是），则整个 EnumSet 用一个 long 表示，因此其性能与位字段的性能相当。批量操作（如 removeAll 和 retainAll）是使用逐位算法实现的，就像手动处理位字段一样。但是，你可以避免因手工修改导致产生不良代码和潜在错误：EnumSet 为你完成了这些繁重的工作。

总之，因为枚举类型将在 Set 中使用，没有理由用位字段表示它。 EnumSet 类结合了位字段的简洁性和性能，以及 Item-34 中描述的枚举类型的许多优点。EnumSet 的一个真正的缺点是，从 Java 9 开始，它不能创建不可变的 EnumSet，在未来发布的版本中可能会纠正这一点。同时，可以用 Collections.unmodifiableSet 包装 EnumSet，但简洁性和性能将受到影响。

# Item 37: Use EnumMap instead of ordinal indexing（使用 EnumMap 替换序数索引） #

建议使用方式

// Using an EnumMap to associate data with an enum
    Map<Plant.LifeCycle, Set<Plant>> plantsByLifeCycle =new EnumMap<>(Plant.LifeCycle.class);
    
    for (Plant.LifeCycle lc : Plant.LifeCycle.values())
        plantsByLifeCycle.put(lc, new HashSet<>());
    
    for (Plant p : garden)
        plantsByLifeCycle.get(p.lifeCycle).add(p);
    
    System.out.println(plantsByLifeCycle);

# Item 38: Emulate extensible enums with interfaces（使用接口模拟可扩展枚举） #

# Item 39: Prefer annotations to naming patterns（注解优于命名模式） #

命名模式：比如@test注解，在早期是需要在方法名前加test字符开头来表示这是一个测试方法。

Test 注解类型的声明本身带有 Retention 注解和 Target 注解。这种注解类型声明上的注解称为元注解。

*  @Retention(RetentionPolicy.RUNTIME) 元注解表明测试注解应该在运行时保留。没有它，测试工具将无法识别测试注解。
 *  @Target.get(ElementType.METHOD) 元注解表明测试注解仅对方法声明合法：它不能应用于类声明、字段声明或其他程序元素。

保留策略决定了在什么位置丢弃注解。Java 定义了 3 种策略，它们被封装到 java.lang.annotation.RetentionPolicy 枚举中。这 3 种策略分别是 SOURCE、CLASS 和 RUNTIME。

--------------------

**注解的保留策略**  
使用 SOURCE 保留策略的注解，只在源文件中保留，在编译期间会被抛弃。  
使用 CLASS 保留策略的注解，在编译时被存储到 .class 文件中。但是，在运行时不能通过 JVM 得到这些注解。  
使用 RUNTIME 保留策略的注解，在编译时被存储到 .class 文件中，并且在运行时可以通过 JVM 获取这些注解。因此，RUNTIME 保留策略提供了最永久的注解。

**ElementType 各常量定义的范围**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]  
[注解相关][Link 3]

# Item 40: Consistently use the Override annotation（坚持使用 @Override 注解） #

Java 库包含几种注解类型。对于大多数的程序员来说，其中最重要的是 @Override。此注解只能在方法声明上使用，带有该注解的方法声明将覆盖超类型中的声明。如果你坚持使用这个注解，它将帮助你减少受到有害错误的影响。

# Item 41: Use marker interfaces to define types（使用标记接口定义类型） #

标记接口是一种不包含任何方法声明的接口，它只是指定（或「标记」）一个类，该类实现了具有某些属性的接口。例如，考虑 Serializable 接口。标记接口定义的类型由标记类的实例实现；标记注解不会。

标记接口相对于标记注解的另一个优点是可以更精确地定位它们。 如果注解类型使用 @Target(ElementType.TYPE) 声明，它可以应用于任何类或接口。假设你有一个只适用于特定接口来实现的标记。如果将其定义为标记接口，则可以让它扩展其适用的惟一接口，确保所有标记的类型也是其适用的惟一接口的子类型。

相对于标记接口，标记注解的主要优势是它们可以是其他注解功能的一部分。

# Item 42: Prefer lambdas to anonymous classes（λ 表达式优于匿名类） #

方法和类不同，lambda 表达式缺少名称和文档；如果一个算法并非不言自明，或者有很多行代码，不要把它放在 lambda 表达式中。

# Item 43: Prefer method references to lambdas（方法引用优于 λ 表达式） #

Java 提供了一种方法来生成比 lambda 表达式更简洁的函数对象：方法引用。下面是一个程序的代码片段，该程序维护从任意键到 Integer 类型值的映射。

map.merge(key, 1, (count, incr) -> count + incr);

一个方法的参数越多，就可以通过一个方法引用消除越多的刻板模式。然而，在某些 lambda 表达式中，您选择的参数名提供了有用的文档，使得 lambda 表达式比方法引用更易于阅读和维护，即使 lambda 表达式更长。

许多方法引用引用静态方法，但是有四种方法不引用静态方法。其中两个是绑定和非绑定实例方法引用。在绑定引用中，接收对象在方法引用中指定。绑定引用在本质上与静态引用相似：函数对象接受与引用方法相同的参数。在未绑定引用中，在应用函数对象时通过方法声明参数之前的附加参数指定接收对象。在流管道中，未绑定引用通常用作映射和筛选函数（Item-45）。最后，对于类和数组，有两种构造函数引用。构造函数引用用作工厂对象。五种方法参考文献汇总如下表：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]

# Item 44: Favor the use of standard functional interfaces（优先使用标准函数式接口） #

# Item 45: Use streams judiciously（明智地使用流） #

流 API 是流畅的：它被设计成允许使用链式调用将组成管道的所有调用写到单个表达式中。实际上，可以将多个管道链接到一个表达式中。

# Item 46: Prefer side-effect-free functions in streams（在流中使用无副作用的函数） #

如果你是流的新手，可能很难掌握它们。仅仅将计算表示为流管道是困难的。当你成功时，你的程序可以运行，但你可能意识不到什么好处。流不仅仅是一个 API，它是一个基于函数式编程的范式。为了获得流提供的可表达性、速度以及在某些情况下的并行性，你必须采纳范式和 API。

流的操作类型分为以下几种：

1、Intermediate

一个流可以后面跟随零个或多个 intermediate 操作。其目的主要是打开流，做出某种程度的数据映射/过滤，然后返回一个新的流，交给下一个操作使用。这类操作都是惰性化的（lazy），就是说，仅仅调用到这类方法，并没有真正开始流的遍历。常见的操作：map（mapToInt、flatMap 等）、filter、distinct、sorted、peek、limit、skip、parallel、sequential、unordered

2、Terminal

一个流只能有一个 terminal 操作，当这个操作执行后，流就被使用「光」了，无法再被操作。所以这必定是流的最后一个操作。Terminal 操作的执行，才会真正开始流的遍历，并且会生成一个结果，或者一个 side effect。常见的操作：forEach、forEachOrdered、toArray、reduce、collect、min、max、count、anyMatch、allMatch、noneMatch、findFirst、findAny、iterator

在对于一个流进行多次转换操作 (Intermediate 操作)，每次都对流的每个元素进行转换，而且是执行多次，这样时间复杂度就是 N（转换次数）个 for 循环里把所有操作都做掉的总和吗？其实不是这样的，转换操作都是 lazy 的，多个转换操作只会在 Terminal 操作的时候融合起来，一次循环完成。我们可以这样简单的理解，流里有个操作函数的集合，每次转换操作就是把转换函数放入这个集合中，在 Terminal 操作的时候循环流对应的集合，然后对每个元素执行所有的函数。

3、short-circuiting

对于一个 intermediate 操作，如果它接受的是一个无限大（infinite/unbounded）的流，但返回一个有限的新流。

对于一个 terminal 操作，如果它接受的是一个无限大的流，但能在有限的时间计算出结果。当操作一个无限大的流，而又希望在有限时间内完成操作，则在管道内拥有一个 short-circuiting 操作是必要非充分条件。常见的操作：anyMatch、allMatch、 noneMatch、findFirst、findAny、limit

总之，流管道编程的本质是无副作用的函数对象。这适用于传递给流和相关对象的所有函数对象。Terminal 操作 forEach 只应用于报告由流执行的计算结果，而不应用于执行计算。为了正确使用流，你必须了解 collector。最重要的 collector 工厂是 toList、toSet、toMap、groupingBy 和 join。

# Item 47: Prefer Collection to Stream as a return type（优先选择 Collection 而不是流作为返回类型） #

Collection 接口是 Iterable 的一个子类型，它有一个流方法，因此它提供了迭代和流两种访问方式。因此，Collection 或其适当的子类通常是公共序列返回方法的最佳返回类型。 数组还提供了使用 Arrays.asList 和 Stream.of 方法进行简单迭代和流访问。如果返回的序列足够小，可以轻松地装入内存，那么最好返回标准集合实现之一，例如 ArrayList 或 HashSet。但是 不要将一个大的序列存储在内存中，只是为了将它作为一个集合返回。

# Item 48: Use caution when making streams parallel（谨慎使用并行流）\* #

Java 7 引入了 fork-join 包，这是一个用于并行分解的高性能框架。Java 8 引入了流，它可以通过对 parallel 方法的一次调用来并行化。用 Java 编写并发程序变得越来越容易，但是编写正确且快速的并发程序却和以前一样困难。在并发编程中，安全性和活性的违反是不可避免的，并行流管道也不例外。

通常，并行性带来的性能提升在 ArrayList、HashMap、HashSet 和 ConcurrentHashMap 实例上的流效果最好；int 数组和 long 数组也在其中。 这些数据结构的共同之处在于，它们都可以被精确且廉价地分割成任意大小的子程序，这使得在并行线程之间划分工作变得很容易。stream 库用于执行此任务的抽象是 spliterator，它由流上的 spliterator 方法返回并可迭代。

所有这些数据结构的另一个重要共同点是，当按顺序处理时，它们提供了从优秀到优秀的引用位置：顺序元素引用一起存储在内存中。这些引用引用的对象在内存中可能彼此不太接近，这降低了引用的位置。引用位置对于并行化批量操作非常重要：如果没有它，线程将花费大量时间空闲，等待数据从内存传输到处理器的缓存中。具有最佳引用位置的数据结构是基本数组，因为数据本身是连续存储在内存中的。

流管道 Terminal 操作的性质也会影响并行执行的有效性。如果与管道的总体工作相比，在 Terminal 操作中完成了大量的工作，并且该操作本质上是顺序的，那么管道的并行化将具有有限的有效性。并行性的最佳 Terminal 操作是缩减，其中来自管道的所有元素都使用流的缩减方法之一进行组合，或者使用预先打包的缩减，如最小、最大、计数和和。anyMatch、allMatch 和 noneMatch 的短路操作也适用于并行性。流的 collect 方法执行的操作称为可变缩减，它们不是并行性的好候选，因为组合集合的开销是昂贵的。

并行化流不仅会导致糟糕的性能，包括活动失败；它会导致不正确的结果和不可预知的行为（安全故障）。

# Item 49: Check parameters for validity（检查参数的有效性） #

不要认为对参数的任意限制都是一件好事。相反，你应该把方法设计得既通用又实用。对参数施加的限制越少越好，假设该方法可以对它所接受的所有参数值进行合理的处理。然而，一些限制常常是实现抽象的内在限制。

# Item 50: Make defensive copies when needed（在需要时制作防御性副本） #

假定你的类的客户端会尽最大努力破坏它的不变量。 即参数传递时有必要考虑copy一份。

# Item 51: Design method signatures carefully（仔细设计方法签名） #

*  避免长参数列表。 设定四个或更少的参数。
 *  不要提供过于便利的方法。 每种方法都应该各司其职。太多的方法使得类难以学习、使用、记录、测试和维护。

有三种方法可以缩短过长的参数列表。一种方法是将方法分解为多个方法，每个方法只需要参数的一个子集。如果操作不当，这可能导致产生太多的方法，但它也可以通过增加正交性来帮助减少方法数量。例如，考虑 java.util.List 接口。它不提供查找子列表中元素的第一个或最后一个索引的方法，这两个方法都需要三个参数。相反，它提供了 subList 方法，该方法接受两个参数并返回子列表的视图。

缩短长参数列表的第二种技术是创建 helper 类来保存参数组。通常，这些 helper 类是静态成员类（Item-42）。如果经常出现的参数序列表示一些不同的实体，则推荐使用这种技术。例如，假设你正在编写一个表示纸牌游戏的类，你发现会不断地传递一个序列，其中包含两个参数，分别表示纸牌的等级和花色。如果你添加一个 helper 类来表示一张卡片，并用 helper 类的一个参数替换参数序列中的每个出现的参数，那么你的 API 以及类的内部结构都可能受益。

*  对于参数类型，优先选择接口而不是类（Item-64）。
 *  双元素枚举类型优于 boolean 参数， 除非布尔值的含义在方法名中明确。

# Item 52: Use overloading judiciously（明智地使用重载） #

重载方法的选择是静态的，而覆盖法的选择是动态的。 方法可以重载，但并不意味着就应该这样做。通常，最好避免重载具有相同数量参数的多个签名的方法。在某些情况下，特别是涉及构造函数的情况下，可能难以遵循这个建议。在这些情况下，你至少应该避免同一组参数只需经过类型转换就可以被传递给不同的重载方法。如果这是无法避免的，例如，因为要对现有类进行改造以实现新接口，那么应该确保在传递相同的参数时，所有重载的行为都是相同的。如果你做不到这一点，程序员将很难有效地使用重载方法或构造函数，他们将无法理解为什么它不能工作。

# Item 53: Use varargs judiciously（明智地使用可变参数） #

该条看适用情况。

# Item 54: Return empty collections or arrays, not nulls（返回空集合或数组，而不是 null） #

# Item 55: Return optionals judiciously（明智地的返回 Optional） #

在 Java 8 之前，在编写在某些情况下无法返回值的方法时，可以采用两种方法。要么抛出异常，要么返回 null（假设返回类型是对象引用类型）。这两种方法都不完美。应该为异常条件保留异常（Item-69），并且抛出异常代价高昂，因为在创建异常时捕获整个堆栈跟踪。返回 null 没有这些缺点，但是它有自己的缺点。如果方法返回 null，客户端必须包含特殊情况代码来处理 null 返回的可能性，除非程序员能够证明 null 返回是不可能的。如果客户端忽略检查 null 返回并将 null 返回值存储在某个数据结构中，那么 NullPointerException 可能会在将来的某个时间，在代码中的某个与该问题无关的位置产生。

理论上应返回 T，但在某些情况下可能无法返回 T 的方法可以将返回值声明为 Optional。这允许该方法返回一个空结果来表明它不能返回有效的结果。具备 Optional 返回值的方法比抛出异常的方法更灵活、更容易使用，并且比返回 null 的方法更不容易出错。

# Item 56: Write doc comments for all exposed API elements（为所有公开的 API 元素编写文档注释） #

# Item 57: Minimize the scope of local variables（将局部变量的作用域最小化） #

# Item 58: Prefer for-each loops to traditional for loops（for-each 循环优于传统的 for 循环） #

# Item 59: Know and use the libraries（了解并使用库） #

不要白费力气重新发明轮子。如果你需要做一些看起来相当常见的事情，那么库中可能已经有一个工具可以做你想做的事情。如果有，使用它；如果你不知道，检查一下。一般来说，库代码可能比你自己编写的代码更好，并且随着时间的推移可能会得到改进。这并不反映你作为一个程序员的能力。规模经济决定了库代码得到的关注要远远超过大多数开发人员所能承担的相同功能。

# Item 60: Avoid float and double if exact answers are required（若需要精确答案就应避免使用 float 和 double 类型） #

# Item 61: Prefer primitive types to boxed primitives（基本数据类型优于包装类） #

# Item 62: Avoid strings where other types are more appropriate（其他类型更合适时应避免使用字符串） #

# Item 63: Beware the performance of string concatenation（当心字符串连接引起的性能问题） #

不要使用字符串连接操作符合并多个字符串，除非性能无关紧要。否则使用 StringBuilder 的 append 方法。或者，使用字符数组，再或者一次只处理一个字符串，而不是组合它们。

# Item 64: Refer to objects by their interfaces（通过接口引用对象） #

# Item 65: Prefer interfaces to reflection（接口优于反射） #

# Item 66: Use native methods judiciously（明智地使用本地方法） #

本地方法有时候性能优异，但不推荐随意使用。

# Item 67: Optimize judiciously（明智地进行优化） #

考虑API设计决策的性能结果。不要努力写快的程序，要努力写好程序；速度自然会提高。但是在设计系统时一定要考虑性能，特别是在设计API、线路层协议和持久数据格式时。当你完成了系统的构建之后，请度量它的性能。如果足够快，就完成了。如果没有，利用分析器找到问题的根源，并对系统的相关部分进行优化。第一步是检查算法的选择：再多的底层优化也不能弥补算法选择的不足。根据需要重复这个过程，在每次更改之后测量性能，直到你满意为止。

# Item 68: Adhere to generally accepted naming conventions（遵守被广泛认可的命名约定） #

# Item 69: Use exceptions only for exceptional conditions（仅在确有异常条件下使用异常） #

# Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors（对可恢复情况使用 checked 异常，对编程错误使用运行时异常） #

# Item 71: Avoid unnecessary use of checked exceptions（避免不必要地使用 checked 异常） #

# Item 72: Favor the use of standard exceptions（鼓励复用标准异常） #

# Item 73: Throw exceptions appropriate to the abstraction（抛出能用抽象解释的异常） #

# Item 74: Document all exceptions thrown by each method（为每个方法记录会抛出的所有异常） #

# Item 75: Include failure capture information in detail messages（异常详细消息中应包含捕获失败的信息） #

# Item 76: Strive for failure atomicity（尽力保证故障原子性） #

# Item 77: Don’t ignore exceptions（不要忽略异常） #

# Item 78: Synchronize access to shared mutable data（对共享可变数据的同步访问） #

当多个线程共享可变数据时，每个读取或写入数据的线程都必须执行同步。 在缺乏同步的情况下，不能保证一个线程的更改对另一个线程可见。同步共享可变数据失败的代价是活性失败和安全失败。这些故障是最难调试的故障之一。它们可能是间歇性的，并与时间相关，而且程序行为可能在不同 VM 之间发生根本的变化。如果只需要线程间通信，而不需要互斥，那么 volatile 修饰符是一种可接受的同步形式，但是要想正确使用它可能会比较棘手。

# Item 79: Avoid excessive synchronization（避免过度同步） #

比较好的开发习惯是，你应该在同步区域内做尽可能少的工作。获取锁，检查共享数据，根据需要进行转换，然后删除锁。如果你必须执行一些耗时的活动，请设法将其移出同步区域。  
为了避免死锁和数据损坏，永远不要从同步区域内调用外来方法。更一般地说，将你在同步区域内所做的工作量保持在最小。在设计可变类时，请考虑它是否应该执行自己的同步。在多核时代，比以往任何时候都更重要的是不要过度同步。只有在有充分理由时，才在内部同步类，并清楚地记录你的决定。

# Item 80: Prefer executors, tasks, and streams to threads（Executor、task、流优于直接使用线程） #

# Item 81: Prefer concurrency utilities to wait and notify（并发实用工具优于 wait 和 notify） #

# Item 82: Document thread safety（文档应包含线程安全属性） #

每个类都应该措辞严谨的描述或使用线程安全注解清楚地记录其线程安全属性。synchronized 修饰符在文档中没有任何作用。有条件的线程安全类必须记录哪些方法调用序列需要外部同步，以及在执行这些序列时需要获取哪些锁。如果你编写一个无条件线程安全的类，请考虑使用一个私有锁对象来代替同步方法。这将保护你免受客户端和子类的同步干扰，并为你提供更大的灵活性，以便在后续的版本中采用复杂的并发控制方式。

# Item 83: Use lazy initialization judiciously（明智地使用延迟初始化） #

应该正常初始化大多数字段，而不是延迟初始化。如果必须延迟初始化字段以实现性能目标或 break a harmful initialization circularity，则使用适当的延迟初始化技术。对于字段，使用双重检查模式；对于静态字段，the lazy initialization holder class idiom. 例如，可以容忍重复初始化的实例字段，还可以考虑单检查模式。

# Item 84: Don’t depend on the thread scheduler（不要依赖线程调度器） #

当面对一个几乎不能工作的程序时，而原因是由于某些线程相对于其他线程没有获得足够的 CPU 时间，那么 通过调用 Thread.yield 来「修复」程序 你也许能勉强让程序运行起来，但它是不可移植的。在一个 JVM 实现上提高性能的相同的 yield 调用，在第二个 JVM 实现上可能会使性能变差，而在第三个 JVM 实现上可能没有任何影响。Thread.yield 没有可测试的语义。 更好的做法是重构应用程序，以减少并发运行线程的数量。  
不要依赖线程调度器来判断程序的正确性。生成的程序既不健壮也不可移植。因此，不要依赖 Thread.yield 或线程优先级。这些工具只是对调度器的提示。线程优先级可以少量地用于提高已经工作的程序的服务质量，但绝不应该用于「修复」几乎不能工作的程序。

# Item 85: Prefer alternatives to Java serialization（Java 序列化的替代方案） #

序列化的一个根本问题是它的可攻击范围太大，且难以保护，而且问题还在不断增多：通过调用 ObjectInputStream 上的 readObject 方法反序列化对象图。这个方法本质上是一个神奇的构造函数，可以用来实例化类路径上几乎任何类型的对象，只要该类型实现 Serializable 接口。在反序列化字节流的过程中，此方法可以执行来自任何这些类型的代码，因此所有这些类型的代码都在攻击范围内。

如果无法避免序列化，并且不能绝对确定反序列化数据的安全性，那么可以使用 Java 9 中添加的对象反序列化筛选，并将其移植到早期版本（java.io.ObjectInputFilter）。该工具允许你指定一个过滤器，该过滤器在反序列化数据流之前应用于数据流。它在类粒度上运行，允许你接受或拒绝某些类。默认接受所有类，并拒绝已知潜在危险类的列表称为黑名单；在默认情况下拒绝其他类，并接受假定安全的类的列表称为白名单。优先选择白名单而不是黑名单， 因为黑名单只保护你免受已知的威胁。

# Item 86: Implement Serializable with great caution（非常谨慎地实现 Serializable） #

# Item 87: Consider using a custom serialized form（考虑使用自定义序列化形式） #

# Item 88: Write readObject methods defensively（防御性地编写 readObject 方法） #

# Item 89: For instance control, prefer enum types to readResolve（对于实例控制，枚举类型优于 readResolve） #

# Item 90: Consider serialization proxies instead of serialized instances（考虑以序列化代理代替序列化实例） #

[Github]: https://github.com/clxering/Effective-Java-3rd-edition-Chinese-English-bilingual
[Link 1]: https://blog.csdn.net/littlewhitevg/article/details/114294475
[Link 2]: https://github.com/clxering/Effective-Java-3rd-edition-Chinese-English-bilingual/blob/dev/Chapter-3/Chapter-3-Item-13-Override-clone-judiciously.md
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]: /images/20221005/0a2ba14cdc014a3da4e56accd6460e87.png
[Link 3]: https://github.com/clxering/Effective-Java-3rd-edition-Chinese-English-bilingual/blob/dev/Chapter-6/Chapter-6-Item-39-Prefer-annotations-to-naming-patterns.md
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]: /images/20221005/cfe5904a37784bdfb26edf2ec68f80b9.png