写着写着发现简书提醒我文章接近字数极限，建议我换一篇写了。

建议52：推荐使用String直接量赋值

一般对象都是通过new关键字生成的，但是String还有第二种生成方式，也就是我们经常使用的直接声明方式，这种方式是极力推荐的，但不建议使用new String（"A"）的方式赋值。为什么呢？我们看如下代码：

public class Client58 {
    public static void main(String[] args) {
        String str1 = "詹姆斯";
        String str2 = "詹姆斯";
        String str3 = new String("詹姆斯");
        String str4 = str3.intern();
        // 两个直接量是否相等
        System.out.println(str1 == str2);
        // 直接量和对象是否相等
        System.out.println(str1 == str3);
        // 经过intern处理后的对象与直接量是否相等
        System.out.println(str1 == str4);
    }
}

注意看上面的程序，我们使用"=="判断的是两个对象的引用地址是否相同，也就是判断是否为同一个对象，打印的结果是true,false,true。即有两个直接量是同一个对象(进过intern处理后的String与直接量是同一个对象)，但直接通过new生成的对象却与之不等，原因何在？

原因是Java为了避免在一个系统中大量产生String对象(为什么会大量产生，因为String字符串是程序中最经常使用的类型)，于是就设计了一个字符串池(也叫作字符串常量池，String pool或String Constant Pool或String Literal Pool),在字符串池中容纳的都是String字符串对象，它的创建机制是这样的：创建一个字符串时，首先检查池中是否有字面值相等的字符串，如果有，则不再创建，直接返回池中该对象的引用，若没有则创建之，然后放到池中，并返回新建对象的引用，这个池和我们平常说的池非常接近。对于此例子来说，就是创建第一个"詹姆斯"字符串时，先检查字符串池中有没有该对象，发现没有，于是就创建了"詹姆斯"这个字符串并放到池中，待创建str2字符串时，由于池中已经有了该字符串，于是就直接返回了该对象的引用，此时，str1和str2指向的是同一个地址，所以使用"=="来判断那当然是相等的了。

那为什么使用new String("詹姆斯")就不相等了呢？因为直接声明一个String对象是不检查字符串池的，也不会把对象放到字符串池中，那当然"=="为false了。

那为什么intern方法处理后即又相等了呢？因为intern会检查当前对象在对象池中是否存在字面值相同的引用对象，如果有则返回池中的对象，如果没有则放置到对象池中，并返回当前对象。

可能有人要问了，放到池中，是不是要考虑垃圾回收问题呀？不用考虑了，虽然Java的每个对象都保存在堆内存中但是字符串非常特殊，它在编译期已经决定了其存在JVM的常量池(Constant Pool),垃圾回收不会对它进行回收的。

通过上面的介绍，我们发现Java在字符串的创建方面确实提供了非常好的机制，利用对象池不仅可以提高效率，同时减少了内存空间的占用，建议大家在开发中使用直接量赋值方式，除非必要才建立一个String对象。

建议54：正确使用String、StringBuffer、StringBuilder

CharSequence接口有三个实现类与字符串有关，String、StringBuffer、StringBuilder，虽然它们都与字符串有关，但其处理机制是不同的。

String类是不可变的量，也就是创建后就不能再修改了，比如创建了一个"abc"这样的字符串对象，那么它在内存中永远都会是"abc"这样具有固定表面值的一个对象，不能被修改，即使想通过String提供的方法来尝试修改，也是要么创建一个新的字符串对象，要么返回自己，比如：

String  str = "abc";
String str1 = str.substring(1);

其中str是一个字符串对象，其值是"abc",通过substring方法又重新生成了一个字符串str1，它的值是"bc",也就是说str引用的对象一但产生就永远不会变。为什么上面还说有可能不创建对象而返回自己呢？那是因为采用substring(0)就不会创建对象。JVM从字符串池中返回str的引用，也就是自身的引用。

StringBuffer是一个可变字符串，它与String一样，在内存中保存的都是一个有序的字符序列(char 类型的数组)，不同点是StringBuffer对象的值是可改变的，例如：

StringBuffer sb = new StringBuffer("a");
sb.append("b");

从上面的代码可以看出sb的值在改变，初始化的时候是"a" ，经过append方法后，其值变成了"ab"。可能有人会问了，这与String类通过 "+" 连接有什么区别呢？例如：

String s = "a";
s = s + "b";

有区别，字符串变量s初始化时是 "a" 对象的引用，经过加号计算后，s变量就修改为了 “ab” 的引用，但是初始化的 “a” 对象还没有改变，只是变量s指向了新的引用地址，再看看StringBuffer的对象，它的引用地址虽不变，但值在改变。

StringBuffer和StringBuilder基本相同，都是可变字符序列，不同点是：StringBuffer是线程安全的，StringBuilder是线程不安全的，翻翻两者的源代码，就会发现在StringBuffer的方法前都有关键字syschronized,这也是StringBuffer在性能上远远低于StringBuffer的原因。

在性能方面，由于String类的操作都是产生String的对象，而StringBuilder和StringBuffer只是一个字符数组的再扩容而已，所以String类的操作要远慢于StringBuffer 和 StringBuilder。

弄清楚了三者之间的原理，我们就可以在不同的场景下使用不同的字符序列了：

• 使用String类的场景：在字符串不经常变化的场景中可以使用String类，例如常量的声明、少量的变量运算等；
• 使用StringBuffer的场景：在频繁进行字符串的运算(如拼接、替换、删除等)，并且运行在多线程的环境中，则可以考虑使用StringBuffer，例如XML解析、HTTP参数解析和封装等；
• 使用StringBuilder的场景：在频繁进行字符串的运算(如拼接、替换、删除等)，并且运行在单线程的环境中，则可以考虑使用StringBuilder，如SQL语句的拼接，JSON封装等。
  　　
  **注意：在适当的场景选用字符串类型 **

事实上这个问题被多个地方研究了很多次，我自己也写了一篇专门的文章来介绍String类：
http://www.jianshu.com/p/e494552f2cf0

建议55：注意字符串的位置

看下面一段程序：

public class Client55 {
    public static void main(String[] args) {
        String str1 = 1 + 2 + "apples";
        String str2 = "apples" + 1 + 2;
        System.out.println(str1);
        System.out.println(str2);
    }
}

想想两个字符串输出的结果的苹果数量是否一致，如果一致，会是几呢？

答案是不一致，str1的值是"3apples" ,str2的值是“apples12”，这中间悬殊很大，只是把“apples” 调换了一下位置，为何会发生如此大的变化呢？

这都源于java对于加号的处理机制：在使用加号进行计算的表达式中，只要遇到String字符串，则所有的数据都会转换为String类型进行拼接，如果是原始数据，则直接拼接，如是是对象，则调用toString方法的返回值然后拼接，如：

str =  str + new ArrayList();

上面就是调用ArrayList对象的toString方法返回值进行拼接的。再回到前面的问题上，对与str1 字符串，Java的执行顺序是从左到右，先执行1+2，也就是算术加法运算，结果等于3，然后再与字符串进行拼接，结果就是 "3 apples",其它形式类似于如下计算：

String str1 = (1 + 2 ) + "apples" ;

而对于str2字符串，由于第一个参与运算的是String类型，加1后的结果是“apples 1” ，这仍然是一个字符串，然后再与2相加，结果还是一个字符串，也就是“apples12”。这说明如果第一个参数是String，则后续的所有计算都会转变为String类型，谁让字符串是老大呢！

注意： 在“+” 表达式中，String字符串具有最高优先级。

建议57：推荐在复杂字符串操作中使用正则表达式

这是一个很自然的选择，因为正则表达式实在是太强大了。

建议58：强烈建议使用UTF编码

Java的乱码问题由来已久，有经验的开发人员肯定遇到过乱码，有时从Web接收的乱码，有时从数据库中读取的乱码，有时是在外部接口中接收的乱码文件，这些都让我们困惑不已，甚至是痛苦不堪，看如下代码：

public class Client58 {
    public static void main(String[] args) throws UnsupportedEncodingException {
        String str = "汉字";
        // 读取字节
        byte b[] = str.getBytes("UTF-8");
        // 重新生成一个新的字符串
        System.out.println(new String(b));
    }
}

Java文件是通过IDE工具默认创建的，编码格式是GBK，大家想想看上面的输出结果会是什么？可能是乱码吧？两个编码格式不同。我们暂时不说结果，先解释一下Java中的编码规则。Java程序涉及的编码包括两部分：

• (1)、Java文件编码：如果我们使用记事本创建一个.java后缀的文件，则文件的编码格式就是操作系统默认的格式。如果是使用IDE工具创建的，如Eclipse，则依赖于IDE的设置，Eclipse默认是操作系统编码（Windows一般为GBK）；

• (2)、Class文件编码：通过javac命令生成的后缀名为.class的文件是UTF-8编码的UNICODE文件，这在任何操作系统上都是一样的，只要是.class文件就会使UNICODE格式。需要说明的是，UTF是UNICODE的存储和传输格式，它是为了解决UNICODE的高位占用冗余空间而产生的，使用UTF编码就意味着字符集使用的是UNICODE.

再回到我们的例子上，getBytes方法会根据指定的字符集取出字节数组(这里按照UNICODE格式来提取)，然后程序又通过new String(byte [] bytes)重新生成一个字符串，来看看String的这个构造函数：通过操作系统默认的字符集解码指定的byte数组，构造一个新的String，结果已经很清楚了，如果操作系统是UTF-8的话，输出就是正确的，如果不是，则会是乱码。由于这里使用的是默认编码GBK，那么输出的结果也就是乱码了。我们再详细分解一下运行步骤：

• 步骤1：创建Client58.java文件：该文件的默认编码格式GBK（如果是Eclipse，则可以在属性中查看到）。

• 步骤2：编写代码(如上)；

• 步骤3：保存，使用javac编译，注意我们没有使用"javac -encoding GBK Client58.java" 显示声明Java的编码方式，javac会自动按照操作系统的编码(GBK)读取Client58.java文件，然后将其编译成.class文件。

• 步骤4：生成.class文件。编译结束，生成.class文件，并保存到硬盘上，此时 .class文件使用的UTF-8格式编码的UNICODE字符集，可以通过javap 命令阅读class文件，其中" 汉字"变量也已经由GBK转变成UNICODE格式了。

• 步骤5：运行main方法，提取"汉字"的字节数组。"汉字" 原本是按照UTF-8格式保存的，要再提取出来当然没有任何问题了。

• 步骤6：重组字符串，读取操作系统默认的编码GBK，然后重新编码变量b的所有字节。问题就在这里产生了：因为UNICODE的存储格式是两个字节表示一个字符(注意：这里是指UCS-2标准)，虽然GBK也是两个字节表示一个字符，但两者之间没有映射关系，只要做转换只能读取映射表，不能实现自动转换----于是JVM就按照默认的编码方式(GBK)读取了UNICODE的两个字节。

• 步骤7：输出乱码，程序运行结束，问题清楚了，解决方案也随之产生，方案有两个。

• 步骤8：修改代码，明确指定编码即可，代码如下：
  System.out.println(new String(b,"UTF-8"));

• 步骤9：修改操作系统的编码方式，各个操作系统的修改方式不同，不再赘述。

我们可以把字符串读取字节的过程看做是数据传输的需要(比如网络、存储)，而重组字符串则是业务逻辑的需求，这样就可以是乱码重现：通过JDBC读取的字节数组是GBK的，而业务逻辑编码时采用的是UTF-8，于是乱码就产生了。对于此类问题，最好的解决办法就是使用统一的编码格式，要么都用GBK，要么都用UTF-8，各个组件、接口、逻辑层、都用UTF-8，拒绝独树一帜的情况。

问题清楚了，我们看看以下代码：

public class Client58 {
    public static void main(String[] args) throws UnsupportedEncodingException {
        String str = "汉字";
        // 读取字节
        byte b[] = str.getBytes("GB2312");
        // 重新生成一个新的字符串
        System.out.println(new String(b));
    }
}

仅仅修改了读取字节的编码方式(修改成了GB2312)，结果会怎样呢？又或者将其修改成GB18030，结果又是怎样的呢？结果都是"汉字"，不是乱码。这是因为GB2312是中文字符集的V1.0版本，GBK是V2.0版本，GB18030是V3.0版本，版本是向下兼容的，只是它们包含的汉字数量不同而已，注意UNICODE可不在这个序列之内。

注意：一个系统使用统一的编码。

建议60：性能考虑，数组是首选

数组在实际的系统开发中用的越来越少了，我们通常只有在阅读一些开源项目时才会看到它们的身影，在Java中它确实没有List、Set、Map这些集合类用起来方便，但是在基本类型处理方面，数组还是占优势的，而且集合类的底层也都是通过数组实现的，比如对一数据集求和这样的计算：

//对数组求和
    public static int sum(int datas[]) {
        int sum = 0;
        for (int i = 0; i < datas.length; i++) {
            sum += datas[i];
        }
        return sum;
    }

对一个int类型 的数组求和，取出所有数组元素并相加，此算法中如果是基本类型则使用数组效率是最高的，使用集合则效率次之。再看使用List求和：

// 对列表求和计算
    public static int sum(List<Integer> datas) {
        int sum = 0;
        for (int i = 0; i < datas.size(); i++) {
            sum += datas.get(i);
        }
        return sum;
    }

注意看sum += datas.get(i);这行代码，这里其实已经做了一个拆箱动作，Integer对象通过intValue方法自动转换成了一个int基本类型，对于性能濒于临界的系统来说该方案是比较危险的，特别是大数量的时候，首先，在初始化List数组时要进行装箱操作，把一个int类型包装成一个Integer对象，虽然有整型池在，但不在整型池范围内的都会产生一个新的Integer对象，而且众所周知，基本类型是在栈内存中操作的，而对象是堆内存中操作的，栈内存的特点是：速度快，容量小；堆内存的特点是：速度慢，容量大（从性能上讲，基本类型的处理占优势）。其次，在进行求和运算时(或者其它遍历计算)时要做拆箱动作，因此无谓的性能消耗也就产生了。在实际测试中发现：对基本类型进行求和运算时，数组的效率是集合的10倍。

注意：性能要求较高的场景中使用数组代替集合。

建议64：多种最值算法，适时选择

对一批数据进行排序，然后找出其中的最大值或最小值，这是基本的数据结构知识。在Java中我们可以通过编写算法的方式，也可以通过数组先排序再取值的方式来实现，下面以求最大值为例，解释一下多种算法：

(1)、自行实现，快速查找最大值　　
先看看用快速查找法取最大值的算法，代码如下：

public static int max(int[] data) {
    int max = data[0];
    for (int i : data) {
        max = max > i ? max : i;
    }
    return max;
}

这是我们经常使用的最大值算法，也是速度最快的算法。它不要求排序，只要遍历一遍数组即可找出最大值。

(2)、先排序，后取值
对于求最大值，也可以采用先排序后取值的方式，代码如下：

public static int max(int[] data) {
    Arrays.sort(data);
    return data[data.length - 1];
}

从效率上讲，当然是自己写快速查找法更快一些了，只用遍历一遍就可以计算出最大值，但在实际测试中发现，如果数组量少于10000，两个基本上没有区别，但在同一个毫秒级别里，此时就可以不用自己写算法了，直接使用数组先排序后取值的方式。

如果数组元素超过10000，就需要依据实际情况来考虑：自己实现，可以提高性能；先排序后取值，简单，通俗易懂。排除性能上的差异，两者都可以选择，甚至后者更方便一些，也更容易想到。

现在问题来了，在代码中为什么先使用data.clone拷贝再排序呢？那是因为数组也是一个对象，不拷贝就改变了原有的数组元素的顺序吗？除非数组元素的顺序无关紧要。那如果要查找仅次于最大值的元素(也就是老二)，该如何处理呢？要注意，数组的元素时可以重复的，最大值可能是多个，所以单单一个排序然后取倒数第二个元素时解决不了问题的。

此时，就需要一个特殊的排序算法了，先要剔除重复数据，然后再排序，当然，自己写算法也可以实现，但是集合类已经提供了非常好的方法，要是再使用自己写算法就显得有点重复造轮子了。数组不能剔除重复数据，但Set集合却是可以的，而且Set的子类TreeSet还能自动排序，代码如下：

public static int getSecond(Integer[] data) {
    //转换为列表
    List<Integer> dataList = Arrays.asList(data);
    //转换为TreeSet，剔除重复元素并升序排列
    TreeSet<Integer> ts = new TreeSet<Integer>(dataList);
    //取得比最大值小的最大值，也就是老二了
    return ts.lower(ts.last());
}

剔除重复元素并升序排列，这都是由TreeSet类实现的，然后可再使用lower方法寻找小于最大值的值，大家看，上面的程序非常简单吧?那如果是我们自己编写代码会怎么样呢？那至少要遍历数组两遍才能计算出老二的值，代码复杂度将大大提升。因此在实际应用中求最值，包括最大值、最小值、倒数第二小值等，使用集合是最简单的方式，当然从性能方面来考虑，数组才是最好的选择。

注意：最值计算时使用集合最简单，使用数组性能最优。

建议82：由点及面，集合大家族总结

Java中的集合类实在是太丰富了，有常用的ArrayList、HashMap,也有不常用的Stack、Queue，有线程安全的Vector、HashTable，也有线程不安全的LinkedList、TreeMap，有阻塞式的ArrayBlockingQueue，也有非阻塞式的PriorityQueue等，整个集合大家族非常庞大，可以划分以下几类：

• (1)、List：实现List接口的集合主要有：ArrayList、LinkedList、Vector、Stack，其中ArrayList是一个动态数组，LinkedList是一个双向链表，Vector是一个线程安全的动态数组，Stack是一个对象栈，遵循先进后出的原则。

• (2)、Set：Set是不包含重复元素的集合，其主要实现类有：EnumSet、HashSet、TreeSet，其中EnumSet是枚举类型专用Set，所有元素都是枚举类型；HashSet是以哈希码决定其元素位置的Set，其原理与HashMap相似，它提供快速的插入和查找方法；TreeSet是一个自动排序的Set，它实现了SortedSet接口。

• (3)、Map：Map是一个大家族，他可以分为排序Map和非排序Map，排序Map主要是TreeMap类，他根据key值进行自动排序；非排序Map主要包括：HashMap、HashTable、Properties、EnumMap等，其中Properties是HashTable的子类，它的主要用途是从Property文件中加载数据，并提供方便的操作，EnumMap则是要求其Key必须是某一个枚举类型。
  Map中还有一个WeakHashMap类需要说明，它是一个采用弱键方式实现的Map类，它的特点是：WeakHashMap对象的存在并不会阻止垃圾回收器对键值对的回收，也就是说使用WeakHashMap装载数据不用担心内存溢出的问题，GC会自动删除不用的键值对，这是好事。但也存在一个严重的问题：GC是静悄悄的回收的(何时回收，God，Knows！)我们的程序无法知晓该动作，存在着重大的隐患。

• (4)、Queue：对列，它分为两类，一类是阻塞式队列，队列满了以后再插入元素会抛出异常，主要包括：ArrayBlockingQueue、PriorityQueue、LinkedBlockingQueue，其中ArrayBlockingQueue是一个以数组方式实现的有界阻塞队列；另一类是非阻塞队列，无边界的，只要内存允许，都可以持续追加元素，我们经常使用的是PriorityQuene类。
  还有一种队列，是双端队列，支持在头、尾两端插入和移除元素，它的主要实现类是：ArrayDeque、LinkedBlockingDeque、LinkedList。

• (5)、数组：数组与集合的最大区别就是数组能够容纳基本类型，而集合就不行，更重要的一点就是所有的集合底层存储的都是数组。

• (6)、工具类：数组的工具类是java.util.Arrays和java.lang.reflect.Array，集合的工具类是java.util.Collections，有了这两个工具类，操作数组和集合就会易如反掌，得心应手。

• (7)、扩展类：集合类当然可以自行扩展了，想写一个自己的List？没问题，但最好的办法还是"拿来主义"，可以使用Apache的common-collections扩展包，也可以使用Google的google-collections扩展包，这些足以应对我们的开发需要。

建议83：推荐使用枚举定义常量

常量声明是每一个项目都不可或缺的，在Java1.5之前，我们只有两种方式的声明：类常量和接口常量，若在项目中使用的是Java1.5之前的版本，基本上都是如此定义的。不过，在1.5版本以后有了改进，即新增了一种常量声明方式：枚举声明常量，看如下代码：

enum Season {
    Spring, Summer, Autumn, Winter;
}

这是一个简单的枚举常量命名，清晰又简单。顺便提一句，JLS(Java Language Specification，Java语言规范)提倡枚举项全部大写，字母之间用下划线分割，这也是从常量的角度考虑的(当然，使用类似类名的命名方式也是比较友好的)。

那么枚举常量与我们经常使用的类常量和静态常量相比有什么优势？问得好，枚举的优点主要表现在四个方面：

1.枚举常量简单：简不简单，我们来对比一下两者的定义和使用情况就知道了。先把Season枚举翻写成接口常量，代码如下：

interface Season {
    int SPRING = 0;
    int SUMMER = 1;
    int AUTUMN = 2;
    int WINTER = 3;
}

此处定义了春夏秋冬四个季节，类型都是int，这与Season枚举的排序值是相同的。首先对比一下两者的定义，枚举常量只需定义每个枚举项，不需要定义枚举值，而接口常量(或类常量)则必须定义值，否则编译不通过，即使我们不需要关注其值是多少也必须定义；其次，虽然两者被引用的方式相同(都是 “类名 . 属性”，如Season.SPRING),但是枚举表示的是一个枚举项，字面含义是春天，而接口常量确是一个int类型，虽然其字面含义也是春天，但在运算中我们势必要关注其int值。

2.枚举常量属于稳态型:例如我们要描述一下春夏秋冬是什么样子，使用接口常量应该是这样写。

public void describe(int s) {
        // s变量不能超越边界，校验条件
        if (s >= 0 && s < 4) {
            switch (s) {
            case Season.SPRING:
                System.out.println("this is spring");
                break;
            case Season.SUMMER:
                System.out.println("this is summer");
                break;
                ......
            }
        }
    }

很简单，先使用switch语句判断哪一个是常量，然后输出。但问题是我们得对输入值进行检查，确定是否越界，如果常量非常庞大，校验输入就成了一件非常麻烦的事情，但这是一个不可逃避的过程，特别是如果我们的校验条件不严格，虽然编译能照样通过，但是运行期就会产生无法预知的后果。

我们再来看看枚举常量是否能够避免校验的问题，代码如下：

public void describe(Season s){
    switch(s){
    case Spring:
        System.out.println("this is "+Season.Spring);
        break;
    case Summer:
        System.out.println("this is summer"+Season.Summer);
        break;
        ......
    }
}

不用校验，已经限定了是Season枚举，所以只能是Season类的四个实例，即春夏秋冬4个枚举项，想输入一个int类型或其它类型？门都没有！这是我们最看重枚举的地方：在编译期间限定类型，不允许发生越界的情况。

3.枚举具有内置方法：有一个简单的问题：如果要列出所有的季节常量，如何实现呢？接口常量或类常量可以通过反射来实现，这没错，只是虽然能实现，但会非常繁琐，大家可以自己写一个反射类实现此功能(当然，一个一个地动手打印出输出常量，也可以算是列出)。对于此类问题可以非常简单的解决，代码如下：

public void query() {
    for (Season s : Season.values()) {
        System.out.println(s);
    }
}

通过values方法获得所有的枚举项，然后打印出来即可。如此简单，得益于枚举内置的方法，每个枚举都是java.lang.Enum的子类，该基类提供了诸如获得排序值的ordinal方法、compareTo比较方法等，大大简化了常量的访问。

4.枚举可以自定义的方法：这一点似乎并不是枚举的优点，类常量也可以有自己的方法呀，但关键是枚举常量不仅可以定义静态方法，还可以定义非静态方法，而且还能够从根本上杜绝常量类被实例化。比如我们要在常量定义中获得最舒服季节的方法，使用常量枚举的代码如下：

enum Season {
        Spring, Summer, Autumn, Winter;
        public static Season getComfortableSeason(){
            return Spring;
        }
}

我们知道，每个枚举项都是该枚举的一个实例，对于我们的例子来说，也就表示Spring其实是Season的一个实例，Summer也是其中一个实例，那我们在枚举中定义的静态方法既可以在类(也就是枚举Season)中引用，也可以在实例(也就是枚举项Spring、Summer、Autumn、Winter)中引用，看如下代码：

public static void main(String[] args) {
    System.out.println("The most comfortable season is "+Season.getComfortableSeason());
}

那如果使用类常量要如何实现呢？代码如下：

class Season {
    public final static int SPRING = 0;
    public final static int SUMMER = 1;
    public final static int AUTUMN = 2;
    public final static int WINTER = 3;
    public static  int getComfortableSeason(){
        return SPRING;
    }
}

想想看，我们怎么才能打印出"The most comfortable season is Spring" 这句话呢？除了使用switch和if判断之外没有其它办法了。

虽然枚举在很多方面比接口常量和类常量好用，但是有一点它是比不上接口常量和类常量的，那就是继承，枚举类型是不能继承的，也就是说一个枚举常量定义完毕后，除非修改重构，否则无法做扩展，而接口常量和类常量则可以通过继承进行扩展。但是，一般常量在项目构建时就定义完毕了，很少会出现必须通过扩展才能实现业务逻辑的场景。

注意： 在项目中推荐使用枚举常量代替接口常量或类常量。

建议88：用枚举实现工厂方法模式更简洁

工厂方法模式(Factory Method Pattern)是" 创建对象的接口，让子类决定实例化哪一个类，并使一个类的实例化延迟到其它子类"。工厂方法模式在我们的开发中经常会用到。下面以汽车制造为例，看看一般的工厂方法模式是如何实现的，代码如下：

//抽象产品
interface Car{
    
}
//具体产品类
class FordCar implements Car{
    
}
//具体产品类
class BuickCar implements Car{
    
}
//工厂类
class CarFactory{
    //生产汽车
    public static Car createCar(Class<? extends Car> c){
        try {
            return c.newInstance();
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }
}

这是最原始的工厂方法模式，有两个产品：福特汽车和别克汽车，然后通过工厂方法模式来生产。有了工厂方法模式，我们就不用关心一辆车具体是怎么生成的了，只要告诉工厂" 给我生产一辆福特汽车 "就可以了，下面是产出一辆福特汽车时客户端的代码：

    public static void main(String[] args) {
        //生产车辆
        Car car = CarFactory.createCar(FordCar.class);
    }

这就是我们经常使用的工厂方法模式，但经常使用并不代表就是最优秀、最简洁的。此处再介绍一种通过枚举实现工厂方法模式的方案，谁优谁劣你自行评价。枚举实现工厂方法模式有两种方法：

(1)、枚举非静态方法实现工厂方法模式

我们知道每个枚举项都是该枚举的实例对象，那是不是定义一个方法可以生成每个枚举项对应产品来实现此模式呢？代码如下：

enum CarFactory {
    // 定义生产类能生产汽车的类型
    FordCar, BuickCar;
    // 生产汽车
    public Car create() {
        switch (this) {
        case FordCar:
            return new FordCar();
        case BuickCar:
            return new BuickCar();
        default:
            throw new AssertionError("无效参数");
        }
    }

}

create是一个非静态方法，也就是只有通过FordCar、BuickCar枚举项才能访问。采用这种方式实现工厂方法模式时，客户端要生产一辆汽车就很简单了，代码如下：

public static void main(String[] args) {
        // 生产车辆
        Car car = CarFactory.BuickCar.create();
    }

(2)、通过抽象方法生成产品

枚举类型虽然不能继承，但是可以用abstract修饰其方法，此时就表示该枚举是一个抽象枚举，需要每个枚举项自行实现该方法，也就是说枚举项的类型是该枚举的一个子类，我们俩看代码：

enum CarFactory {
    // 定义生产类能生产汽车的类型
    FordCar{
        public Car create(){
            return new FordCar();
        }
    },
    BuickCar{
        public Car create(){
            return new BuickCar();
        }
    };
    //抽象生产方法
    public abstract Car create();
}

首先定义一个抽象制造方法create，然后每个枚举项自行实现，这种方式编译后会产生CarFactory的匿名子类，因为每个枚举项都要实现create抽象方法。客户端调用与上一个方案相同，不再赘述。

大家可能会问，为什么要使用枚举类型的工厂方法模式呢？那是因为使用枚举类型的工厂方法模式有以下三个优点：

• 避免错误调用的发生：一般工厂方法模式中的生产方法(也就是createCar方法)，可以接收三种类型的参数：类型参数(如我们的例子)、String参数(生产方法中判断String参数是需要生产什么产品)、int参数(根据int值判断需要生产什么类型的的产品)，这三种参数都是宽泛的数据类型，很容易发生错误(比如边界问题、null值问题)，而且出现这类错误编译器还不会报警，例如：

    public static void main(String[] args) {
        // 生产车辆
        Car car = CarFactory.createCar(Car.class);
    }

Car是一个接口，完全合乎createCar的要求，所以它在编译时不会报任何错误，但一运行就会报出InstantiationException异常，而使用枚举类型的工厂方法模式就不存在该问题了，不需要传递任何参数，只需要选择好生产什么类型的产品即可。

• 性能好，使用简洁：枚举类型的计算时以int类型的计算为基础的，这是最基本的操作，性能当然会快，至于使用便捷，注意看客户端的调用，代码的字面意思就是" 汽车工厂，我要一辆别克汽车，赶快生产"。

• 降低类间耦合：不管生产方法接收的是Class、String还是int的参数，都会成为客户端类的负担，这些类并不是客户端需要的，而是因为工厂方法的限制必须输入的，例如Class参数，对客户端main方法来说，他需要传递一个FordCar.class参数才能生产一辆福特汽车，除了在create方法中传递参数外，业务类不需要改Car的实现类。这严重违背了迪米特原则(Law of Demeter 简称LoD),也就是最少知识原则：一个对象应该对其它对象有最少的了解。

而枚举类型的工厂方法就没有这种问题了，它只需要依赖工厂类就可以生产一辆符合接口的汽车，完全可以无视具体汽车类的存在。

建议93：Java的泛型是可以擦除的

Java泛型(Generic) 的引入加强了参数类型的安全性，减少了类型的转换，它与C++中的模板(Temeplates) 比较类似，但是有一点不同的是：Java的泛型在编译器有效，在运行期被删除，也就是说所有的泛型参数类型在编译后会被清除掉，我们来看一个例子，代码如下：

public class Foo {
    //arrayMethod接收数组参数，并进行重载
    public void arrayMethod(String[] intArray) {

    }

    public void arrayMethod(Integer[] intArray) {

    }
    //listMethod接收泛型List参数，并进行重载
    public void listMethod(List<String> stringList) {

    }
    public void listMethod(List<Integer> intList) {
        
    }
}

程序很简单，编写了4个方法，arrayMethod方法接收String数组和Integer数组，这是一个典型的重载，listMethod接收元素类型为String和Integer的list变量。现在的问题是，这段程序是否能编译？如果不能？问题出在什么地方？

事实上，这段程序时无法编译的，编译时报错信息如下：

这段错误的意思：简单的的说就是方法签名重复，其实就是说listMethod(List<Integer> intList)方法在编译时擦除类型后是listMethod(List<E> intList)与另一个方法重复。这就是Java泛型擦除引起的问题：在编译后所有的泛型类型都会做相应的转化。转换规则如下：

• List<String>、List<Integer>、List<T>擦除后的类型为List
• List<String>[] 擦除后的类型为List[].
• List<? extends E> 、List<? super E> 擦除后的类型为List<E>.
• List<T extends Serializable & Cloneable >擦除后的类型为List< Serializable>.

明白了这些规则，再看如下代码：

public static void main(String[] args) {
        List<String> list = new ArrayList<String>();
        list.add("abc");
        String str = list.get(0);
    }

进过编译后的擦除处理，上面的代码和下面的程序时一致的：

public static void main(String[] args) {
        List list = new ArrayList();
        list.add("abc");
        String str = (String) list.get(0);
    }

Java编译后字节码中已经没有泛型的任何信息了，也就是说一个泛型类和一个普通类在经过编译后都指向了同一字节码，比如Foo<T>类，经过编译后将只有一份Foo.class类，不管是Foo<String>还是Foo<Integer>引用的都是同一字节码。Java之所以如此处理，有两个原因：

• 避免JVM的大换血。C++泛型生命期延续到了运行期，而Java是在编译期擦除掉的，我们想想，如果JVM也把泛型类型延续到运行期，那么JVM就需要进行大量的重构工作了。
• 版本兼容：在编译期擦除可以更好的支持原生类型(Raw Type)，在Java1.5或1.6...平台上，即使声明一个List这样的原生类型也是可以正常编译通过的，只是会产生警告信息而已。

明白了Java泛型是类型擦除的，我们就可以解释类似如下的问题了：

1.泛型的class对象是相同的：每个类都有一个class属性，泛型化不会改变class属性的返回值，例如：

public static void main(String[] args) {
        List<String> list = new ArrayList<String>();
        List<Integer> list2 = new ArrayList<Integer>();
        System.out.println(list.getClass()==list2.getClass());
    }

以上代码返回true，原因很简单，List<String>和List<Integer>擦除后的类型都是List，没有任何区别。

2.泛型数组初始化时不能声明泛型，如下代码编译时通不过：　

List<String>[] listArray = new List<String>[];

原因很简单，可以声明一个带有泛型参数的数组，但不能初始化该数组，因为执行了类型擦除操作，List<Object>[]与List<String>[] 就是同一回事了，编译器拒绝如此声明。

3.instanceof不允许存在泛型参数:以下代码不能通过编译，原因一样，泛型类型被擦除了：

List<String> list = new ArrayList<String>();
System.out.println(list instanceof List<String>);

建议98：建议的采用顺序是List中泛型顺序依次为T、?、Object

List<T>、List<?>、List<Object>这三者都可以容纳所有的对象，但使用的顺序应该是首选List<T>，次之List<?>，最后选择List<Object>，原因如下：

(1)、List<T>是确定的某一个类型

List<T>表示的是List集合中的元素都为T类型，具体类型在运行期决定；List<？>表示的是任意类型，与List<T>类似，而List<Object>则表示List集合中的所有元素为Object类型，因为Object是所有类的父类，所以List<Object>也可以容纳所有的类类型，从这一字面意义上分析，List<T>更符合习惯：编码者知道它是某一个类型，只是在运行期才确定而已。

(2)List<T>可以进行读写操作

List<T>可以进行诸如add，remove等操作，因为它的类型是固定的T类型，在编码期不需要进行任何的转型操作。

List<T>是只读类型的，不能进行增加、修改操作，因为编译器不知道List中容纳的是什么类型的元素，也就无法校验类型是否安全了，而且List<?>读取出的元素都是Object类型的，需要主动转型，所以它经常用于泛型方法的返回值。注意List<？>虽然无法增加，修改元素，但是却可以删除元素，比如执行remove、clear等方法，那是因为它的删除动作与泛型类型无关。

List<Object> 也可以读写操作，但是它执行写入操作时需要向上转型(Up cast)，在读取数据的时候需要向下转型，而此时已经失去了泛型存在的意义了。

打个比方，有一个篮子用来容纳物品，比如西瓜，番茄等.List<?>的意思是说，“嘿，我这里有一个篮子，可以容纳固定类别的东西，比如西瓜，番茄等”。List<?>的意思是说：“嘿，我有一个篮子，我可以容纳任何东西，只要是你想得到的”。而List<Object>就更有意思了，它说" 嘿，我也有一个篮子，我可以容纳所有物质，只要你认为是物质的东西都可以容纳进来 "。

推而广之，Dao<T>应该比Dao<？>、Dao<Object>更先采用，Desc<Person>则比Desc<？>、Desc<Object>更优先采用。

建议101：注意Class类的特殊性

Java语言是先把Java源文件编译成后缀为class的字节码文件，然后再通过ClassLoader机制把这些类文件加载到内存中，最后生成实例执行的，这是Java处理的基本机制，但是加载到内存中的数据的如何描述一个类的呢？比如在Dog.class文件中定义一个Dog类，那它在内存中是如何展现的呢？

Java使用一个元类(MetaClass)来描述加载到内存中的类数据，这就是Class类，它是一个描述类的类对象，比如Dog.class文件加载到内存中后就会有一个class的实例对象描述之。因为是Class类是“类中类”，也就有预示着它有很多特殊的地方：

• 1.无构造函数：Java中的类一般都有构造函数，用于创建实例对象，但是Class类却没有构造函数，不能实例化，Class对象是在加载类时由Java虚拟机通过调用类加载器中的difineClass方法自动构造的。
• 2.可以描述基本类型：虽然8个基本类型在JVM中并不是一个对象，它们一般存在于栈内存中，但是Class类仍然可以描述它们，例如可以使用int.class表示int类型的类对象。
• 3.其对象都是单例模式：一个Class的实例对象描述一个类，并且只描述一个类，反过来也成立。一个类只有一个Class实例对象，如下代码返回的结果都为true：

        // 类的属性class所引用的对象与实例对象的getClass返回值相同
        boolean b1=String.class.equals(new String().getClass());
        boolean b2="ABC".getClass().equals(String.class);
        // class实例对象不区分泛型
        boolean b3=ArrayList.class.equals(new ArrayList<String>().getClass());

Class类是Java的反射入口，只有在获得了一个类的描述对象后才能动态的加载、调用，一般获得一个Class对象有三种途径：

• 类属性方式：如String.class
• 对象的getClass方法，如new String().getClass()
• forName方法加载：如Class.forName(" java.lang.String")

获得了Class对象后，就可以通过getAnnotations()获得注解，通过getMethods()获得方法，通过getConstructors()获得构造函数等，这位后续的反射代码铺平了道路。

建议106：动态代理可以使代理模式更加灵活

Java的反射框架提供了动态代理(Dynamic Proxy)机制，允许在运行期对目标类生成代理，避免重复开发。我们知道一个静态代理是通过主题角色(Proxy)和具体主题角色(Real Subject)共同实现主题角色(Subject)的逻辑的，只是代理角色把相关的执行逻辑委托给了具体角色而已，一个简单的静态代理如下所示：

interface Subject {
    // 定义一个方法
    public void request();
}

// 具体主题角色
class RealSubject implements Subject {
    // 实现方法
    @Override
    public void request() {
        // 实现具体业务逻辑
    }

}

class Proxy implements Subject {
    // 要代理那个实现类
    private Subject subject = null;

    // 默认被代理者
    public Proxy() {
        subject = new RealSubject();
    }

    // 通过构造函数传递被代理者
    public Proxy(Subject _subject) {
        subject = _subject;
    }

    @Override
    public void request() {
        before();
        subject.request();
        after();
    }

    // 预处理
    private void after() {
        // doSomething
    }

    // 善后处理
    private void before() {
        // doSomething
    }
}

这是一个简单的静态代理。Java还提供了java.lang.reflect.Proxy用于实现动态代理：只要提供一个抽象主题角色和具体主题角色，就可以动态实现其逻辑的，其实例代码如下：

interface Subject {
    // 定义一个方法
    public void request();
}

// 具体主题角色
class RealSubject implements Subject {
    // 实现方法
    @Override
    public void request() {
        // 实现具体业务逻辑
    }

}

class SubjectHandler implements InvocationHandler {
    // 被代理的对象
    private Subject subject;

    public SubjectHandler(Subject _subject) {
        subject = _subject;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        // 预处理
        System.out.println("预处理...");
        //直接调用被代理的方法
        Object obj = method.invoke(subject, args);
        // 后处理
        System.out.println("后处理...");
        return obj;
    }
}

注意这里没有代理主题角色，取而代之的是SubjectHandler 作为主要的逻辑委托处理，其中invoke方法是接口InvocationHandler定义必须实现的，它完成了对真实方法的调用。

我们来详细解释一下InvocationHandler接口，动态代理是根据被代理的接口生成的所有方法的，也就是说给定一个或多个接口，动态代理会宣称“我已经实现该接口下的所有方法了”，那大家想想看，动态代理是怎么才能实现接口中的方法呢？在默认情况下所有方法的返回值都是空的，是的，虽然代理已经实现了它，但是没有任何的逻辑含义，那怎么办？好办，通过InvocationHandler接口的实现类来实现，所有的方法都是由该Handler进行处理的，即所有被代理的方法都由InvocationHandler接管实际的处理任务。

我们开看看动态代理的场景，代码如下：

public static void main(String[] args) {
        //具体主题角色，也就是被代理类
        Subject subject = new RealSubject();
        //代理实例的处理Handler
        InvocationHandler handler =new SubjectHandler(subject);
        //当前加载器
        ClassLoader cl = subject.getClass().getClassLoader();
        //动态代理
        Subject proxy = (Subject) Proxy.newProxyInstance(cl,subject.getClass().getInterfaces(),handler);
        //执行具体主题角色方法
        proxy.request();
    }

此时就实现了，不用显式创建代理类即实现代理的功能，例如可以在被代理的角色执行前进行权限判断，或者执行后进行数据校验。

动态代理很容易实现通用的代理类，只要在InvocationHandler的invoke方法中读取持久化的数据即可实现，而且还能实现动态切入的效果，这也是AOP(Aspect Oriented Programming)变成理念。

建议110：提倡异常封装

Java语言的异常处理机制可以去确保程序的健壮性，提高系统的可用率，但是Java API提供的异常都是比较低级的(这里的低级是指 " 低级别的 " 异常)，只有开发人员才能看的懂，才明白发生了什么问题。而对于终端用户来说，这些异常基本上就是天书，与业务无关，是纯计算机语言的描述，那该怎么办？这就需要我们对异常进行封装了。异常封装有三方面的优点：

(1)、提高系统的友好性

例如，打开一个文件，如果文件不存在，则回报FileNotFoundException异常，如果该方法的编写者不做任何处理，直接抛到上层，则会降低系统的友好性，代码如下所示：

public static void doStuff() throws FileNotFoundException {
        InputStream is = new FileInputStream("无效文件.txt");
        /* 文件操作 */
    }

此时doStuff的友好性极差，出现异常时(如果文件不存在)，该方法直接把FileNotFoundException异常抛到上层应用中(或者是最终用户)，而上层应用(或用户要么自己处理)，要么接着抛，最终的结果就是让用户面对着" 天书 " 式的文字发呆，用户不知道这是什么问题，只是知道系统告诉他" 哦，我出错了，什么错误？你自己看着办吧 "。

解决办法就是封装异常，可以把异常的阅读者分为两类：开发人员和用户。开发人员查找问题，需要打印出堆栈信息，而用户则需要了解具体的业务原因，比如文件太大、不能同时编写文件等，代码如下：

public static void doStuff2() throws MyBussinessException{
        try {
            InputStream is = new FileInputStream("无效文件.txt");
        } catch (FileNotFoundException e) {
            //方便开发人员和维护人员而设置的异常信息
            e.printStackTrace();
            //抛出业务异常
            throw new MyBussinessException();
        }
        /* 文件操作 */
    }

(2)、提高系统的可维护性

看如下代码：

public  void doStuff3(){
        try{
            //doSomething
        }catch(Exception e){
            e.printStackTrace();
        }
        
    }

这是大家很容易犯的错误，抛出异常是吧?分类处理多麻烦，就写一个catch块来处理所有的异常吧，而且还信誓旦旦的说" JVM会打印出栈中的错误信息 "，虽然这没错，但是该信息只有开发人员自己看的懂，维护人员看到这段异常时基本上无法处理，因为需要到代码逻辑中去分析问题。

正确的做法是对异常进行分类处理，并进行封装输出，代码如下：

public  void doStuff4(){
        try{
            //doSomething
        }catch(FileNotFoundException e){
            log.info("文件未找到，使用默认配置文件....");
            e.printStackTrace();
        }catch(SecurityException e1){
            log.info(" 无权访问，可能原因是......");
            e1.printStackTrace();
        }
    }

如此包装后，维护人员看到这样的异常就有了初步的判断，或者检查配置，或者初始化环境，不需要直接到代码层级去分析了。

(3)、解决Java异常机制自身的缺陷

Java中的异常一次只能抛出一个，比如doStuff方法有两个逻辑代码片段，如果在第一个逻辑片段中抛出异常，则第二个逻辑片段就不再执行了，也就无法抛出第二个异常了，现在的问题是：如何才能一次抛出两个(或多个)异常呢？

其实，使用自行封装的异常可以解决该问题，代码如下：

class MyException extends Exception {
    // 容纳所有的异常
    private List<Throwable> causes = new ArrayList<Throwable>();

    // 构造函数，传递一个异常列表
    public MyException(List<? extends Throwable> _causes) {
        causes.addAll(_causes);
    }

    // 读取所有的异常
    public List<Throwable> getExceptions() {
        return causes;
    }
}

MyException异常只是一个异常容器，可以容纳多个异常，但它本身并不代表任何异常含义，它所解决的是一次抛出多个异常的问题，具体调用如下：

public void doStuff() throws MyException {
        List<Throwable> list = new ArrayList<Throwable>();
        // 第一个逻辑片段
        try {
            // Do Something
        } catch (Exception e) {
            list.add(e);
        }
        // 第二个逻辑片段
        try {
            // Do Something
        } catch (Exception e) {
            list.add(e);
        }
        // 检查是否有必要抛出异常
        if (list.size() > 0) {
            throw new MyException(list);
        }
    }

这样一来，DoStuff方法的调用者就可以一次获得多个异常了，也能够为用户提供完整的例外情况说明。可能有人会问：这种情况会出现吗？怎么回要求一个方法抛出多个异常呢？

绝对有可能出现，例如Web界面注册时，展现层依次把User对象传递到逻辑层，Register方法需要对各个Field进行校验并注册，例如用户名不能重复，密码必须符合密码策略等，不要出现用户第一次提交时系统显示" 用户名重复 "，在用户修改用户名再次提交后，系统又提示" 密码长度小于6位 " 的情况，这种操作模式下的用户体验非常糟糕，最好的解决办法就是异常封装，建立异常容器，一次性地对User对象进行校验，然后返回所有的异常。

建议114：不要在构造函数中抛出异常

Java异常的机制有三种：

• Error类及其子类表示的是错误，它是不需要程序员处理也不能处理的异常，比如VirtualMachineError虚拟机错误，ThreadDeath线程僵死等。
• RunTimeException类及其子类表示的是非受检异常，是系统可能会抛出的异常，程序员可以去处理，也可以不处理，最经典的就是NullPointException空指针异常和IndexOutOfBoundsException越界异常。
• Exception类及其子类(不包含非受检异常)，表示的是受检异常，这是程序员必须处理的异常，不处理则程序不能通过编译，比如IOException表示的是I/O异常，SQLException表示的数据库访问异常。

我们知道，一个对象的创建过程经过内存分配，静态代码初始化、构造函数执行等过程，对象生成的关键步骤是构造函数，那是不是也允许在构造函数中抛出异常呢？从Java语法上来说，完全可以在构造函数中抛出异常，三类异常都可以，但是从系统设计和开发的角度来分析，则尽量不要在构造函数中抛出异常，我们以三种不同类型的异常来说明之。

(1)、构造函数中抛出错误是程序员无法处理的

在构造函数执行时，若发生了VirtualMachineError虚拟机错误，那就没招了，只能抛出，程序员不能预知此类错误的发生，也就不能捕捉处理。

(2)、构造函数不应该抛出非受检异常

我们来看这样一个例子，代码如下：

class Person {
    public Person(int _age) {
        // 不满18岁的用户对象不能建立
        if (_age < 18) {
            throw new RuntimeException("年龄必须大于18岁.");
        }
    }

    public void doSomething() {
        System.out.println("doSomething......");
    }
}

这段代码的意图很明显，年龄不满18岁的用户不会生成一个Person实例对象，没有对象，类行为doSomething方法就不可执行，想法很好，但这会导致不可预测的结果，比如我们这样引用Person类：

public static void main(String[] args) {
        Person p =  new Person(17);
        p.doSomething();
        /*其它的业务逻辑*/
    }

很显然，p对象不能建立，因为是一个RunTimeException异常，开发人员可以捕捉也可以不捕捉，代码看上去逻辑很正确，没有任何瑕疵，但是事实上，这段程序会抛出异常，无法执行。这段代码给了我们两个警示：

• 1.加重了上层代码编写者的负担：捕捉这个RuntimeException异常吧，那谁来告诉我有这个异常呢？只有通过文档约束了，一旦Person类的构造函数经过重构后再抛出其它非受检异常，那main方法不用修改也是可以测试通过的，但是这里就可能会产生隐藏的缺陷，而写还是很难重现的缺陷。不捕捉这个RuntimeException异常，这个是我们通常的想法，既然已经写成了非受检异常，main方法的编码者完全可以不处理这个异常嘛，大不了不执行Person的方法！这是非常危险的，一旦产生异常，整个线程都不再继续执行，或者链接没有关闭，或者数据没有写入数据库，或者产生内存异常，这些都是会对整个系统产生影响。
• 2.后续代码不会执行：main方法的实现者原本是想把p对象的建立作为其代码逻辑的一部分，执行完doSomething方法后还需要完成其它逻辑，但是因为没有对非受检异常进行捕捉，异常最终会抛出到JVM中，这会导致整个线程执行结束后，后面所有的代码都不会继续执行了，这就对业务逻辑产生了致命的影响。

(3)、构造函数尽可能不要抛出受检异常

我们来看下面的例子，代码如下：

//父类
class Base {
    // 父类抛出IOException
    public Base() throws IOException {
        throw new IOException();
    }
}
//子类
class Sub extends Base {
    // 子类抛出Exception异常
    public Sub() throws Exception {

    }
}

就这么一段简单的代码，展示了在构造函数中抛出受检异常的三个不利方面：

• 1.导致子类膨胀：在我们的例子中子类的无参构造函数不能省略，原因是父类的无参构造函数抛出了IOException异常，子类的无参构造函数默认调用的是父类的构造函数，所以子类无参构造函数也必须抛出IOException或其父类。
• 2.违背了里氏替换原则："里氏替换原则" 是说父类能出现的地方子类就可以出现，而且将父类替换为子类也不会产生任何异常。那我们回头看看Sub类是否可以替换Base类，比如我们的上层代码是这样写的：

public static void main(String[] args) {
        try {
            Base base = new Base();
        } catch (Exception e) {    
            e.printStackTrace();
        }
    }

然后，我们期望把new Base()替换成new Sub()，而且代码能够正常编译和运行。非常可惜，编译不通过，原因是Sub的构造函数抛出了Exception异常，它比父类的构造函数抛出更多的异常范围要宽，必须增加新的catch块才能解决。

可能大家要问了，为什么Java的构造函数允许子类的构造函数抛出更广泛的异常类呢？这正好与类方法的异常机制相反，类方法的异常是这样要求的：

// 父类
class Base {
    // 父类方法抛出Exception
    public void testMethod() throws Exception {

    }
}

// 子类
class Sub extends Base {
    // 父类方法抛出Exception
    @Override
    public void testMethod() throws IOException {

    }
}

子类的方法可以抛出多个异常，但都必须是覆写方法的子类型，对我们的例子来说，Sub类的testMethod方法抛出的异常必须是Exception的子类或Exception类，这是Java覆写的要求。构造函数之所以于此相反，是因为构造函数没有覆写的概念，只是构造函数间的引用调用而已，所以在构造函数中抛出受检异常会违背里氏替换原则原则，使我们的程序缺乏灵活性。

• 3.子类构造函数扩展受限：子类存在的原因就是期望实现扩展父类的逻辑，但父类构造函数抛出异常却会让子类构造函数的灵活性大大降低，例如我们期望这样的构造函数。

// 父类
class Base {
    public Base() throws IOException{
        
    }
}
// 子类
class Sub extends Base {
    public Sub() throws Exception{
        try{
            super();
        }catch(IOException e){
            //异常处理后再抛出
            throw e;
        }finally{
            //收尾处理
        }
    }
}

很不幸，这段代码编译不通过，原因是构造函数Sub没有把super()放在第一句话中，想把父类的异常重新包装再抛出是不可行的(当然，这里有很多种 “曲线” 的实现手段，比如重新定义一个方法，然后父子类的构造函数都调用该方法，那么子类构造函数就可以自由处理异常了)，这是Java语法机制。

将以上三种异常类型汇总起来，对于构造函数，错误只能抛出，这是程序人员无能为力的事情；非受检异常不要抛出，抛出了 " 对己对人 " 都是有害的；受检异常尽量不抛出，能用曲线的方式实现就用曲线方式实现，总之一句话：在构造函数中尽可能不出现异常。

注意 ：在构造函数中不要抛出异常，尽量曲线实现。

建议117：多使用异常，把性能问题放一边

我们知道异常是主逻辑的例外逻辑，举个简单的例子来说，比如我在马路上走(这是主逻辑)，突然开过一辆车，我要避让(这是受检异常，必须处理)，继续走着，突然一架飞机从我头顶飞过(非受检异常)，我们可以选在继续行走(不捕捉)，也可以选择指责其噪音污染(捕捉，主逻辑的补充处理)，再继续走着，突然一颗流星砸下来，这没有选择，属于错误，不能做任何处理。这样具备完整例外场景的逻辑就具备了OO的味道，任何一个事务的处理都可能产生非预期的效果，问题是需要以何种手段来处理，如果不使用异常就需要依靠返回值的不同来进行处理了，这严重失去了面向对象的风格。

我们在编写用例文档（User case Specification）时，其中有一项叫做 " 例外事件 "，是用来描述主场景外的例外场景的，例如用户登录的用例，就会在" 例外事件 "中说明" 连续3此登录失败即锁定用户账号 "，这就是登录事件的一个异常处理，具体到我们的程序中就是：

public void login(){
        try{
            //正常登陆
        }catch(InvalidLoginException lie){
            //    用户名无效
        }catch(InvalidPasswordException pe){
            //密码错误的异常
        }catch(TooMuchLoginException){
            //多次登陆失败的异常
        }
    }

如此设计则可以让我们的login方法更符合实际的处理逻辑，同时使主逻辑(正常登录，try代码块)更加清晰。当然了，使用异常还有很多优点，可以让正常代码和异常代码分离、能快速查找问题(栈信息快照)等，但是异常有一个缺点：性能比较慢。

Java的异常机制确实比较慢，这个"比较慢"是相对于诸如String、Integer等对象来说的，单单从对象的创建上来说，new一个IOException会比String慢5倍，这从异常的处理机制上也可以解释：因为它要执行fillInStackTrace方法，要记录当前栈的快照，而String类则是直接申请一个内存创建对象，异常类慢一筹也就在所难免了。

而且，异常类是不能缓存的，期望先建立大量的异常对象以提高异常性能也是不现实的。

难道异常的性能问题就没有任何可以提高的办法了？确实没有，但是我们不能因为性能问题而放弃使用异常，而且经过测试，在JDK1.6下，一个异常对象的创建时间只需1.4毫秒左右(注意是毫秒，通常一个交易是在100毫秒左右)，难道我们的系统连如此微小的性能消耗都不予许吗？

　注意：性能问题不是拒绝异常的借口。

建议121：线程优先级只使用三个等级

线程的优先级(Priority)决定了线程获得CPU运行的机会，优先级越高获得的运行机会越大，优先级越低获得的机会越小。Java的线程有10个级别(准确的说是11个级别，级别为0的线程是JVM的，应用程序不能设置该级别)，那是不是说级别是10的线程肯定比级别是9的线程先运行呢?我们来看如下一个多线程类：

class TestThread implements Runnable {
    public void start(int _priority) {
        Thread t = new Thread(this);
        // 设置优先级别
        t.setPriority(_priority);
        t.start();
    }
    @Override
    public void run() {
        // 消耗CPU的计算
        for (int i = 0; i < 100000; i++) {
            Math.hypot(924526789, Math.cos(i));
        }
        // 输出线程优先级
        System.out.println("Priority：" + Thread.currentThread().getPriority());
    }
}

该多线程实现了Runnable接口，实现了run方法，注意在run方法中有一个比较占用CPU的计算，该计算毫无意义，

public static void main(String[] args) {
        //启动20个不同优先级的线程
        for (int i = 0; i < 20; i++) {
            new TestThread().start(i % 10 + 1);
        }
    }

这里创建了20个线程，每个线程在运行时都耗尽了CPU的资源，因为优先级不同，线程调度应该是先处理优先级高的，然后处理优先级低的，也就是先执行2个优先级为10的线程，然后执行2个优先级为9的线程，2个优先级为8的线程......但是结果却并不是这样的。
　　Priority：5
　　Priority：7
　　Priority：10
　　Priority：6
　　Priority：9
　　Priority：6
　　Priority：5
　　Priority：7
　　Priority：10
　　Priority：3
　　Priority：4
　　Priority：8
　　Priority：8
　　Priority：9
　　Priority：4
　　Priority：1
　　Priority：3
　　Priority：1
　　Priority：2
　　Priority：2

println方法虽然有输出损耗，可能会影响到输出结果，但是不管运行多少次，你都会发现两个不争的事实：
(1)、并不是严格按照线程优先级来执行的
比如线程优先级为5的线程比优先级为7的线程先执行，优先级为1的线程比优先级为2的线程先执行，很少出现优先级为2的线程比优先级为10的线程先执行(注意，这里是" 很少 "，是说确实有可能出现，只是几率低，因为优先级只是表示线程获得CPU运行的机会，并不代表强制的排序号)。
(2)、优先级差别越大，运行机会差别越明显
比如优先级为10的线程通常会比优先级为2的线程先执行，但是优先级为6的线程和优先级为5的线程差别就不太明显了，执行多次，你会发现有不同的顺序。

这两个现象是线程优先级的一个重要表现，之所以会出现这种情况，是因为线程运行是需要获得CPU资源的，那谁能决定哪个线程先获得哪个线程后获得呢？这是依照操作系统设置的线程优先级来分配的，也就是说，每个线程要运行，需要操作系统分配优先级和CPU资源，对于JAVA来说，JVM调用操作系统的接口设置优先级，比如windows操作系统优先级都相同吗？

事实上，不同的操作系统线程优先级是不同的，Windows有7个优先级，Linux有140个优先级，Freebsd则由255个(此处指的优先级个数，不同操作系统有不同的分类，如中断级线程，操作系统级等，各个操作系统具体用户可用的线程数量也不相同)。Java是跨平台的系统，需要把这10个优先级映射成不同的操作系统的优先级，于是界定了Java的优先级只是代表抢占CPU的机会大小，优先级越高，抢占CPU的机会越大，被优先执行的可能性越高，优先级相差不大，则抢占CPU的机会差别也不大，这就是导致了优先级为9的线程可能比优先级为10的线程先运行。

Java的缔造者们也觉察到了线程优先问题，于是Thread类中设置了三个优先级，此意就是告诉开发者，建议使用优先级常量，而不是1到10的随机数字。常量代码如下：

public class Thread implements Runnable {
    /**
     * The minimum priority that a thread can have. 
     */
    public final static int MIN_PRIORITY = 1;
    /**
     * The default priority that is assigned to a thread. 
     */
    public final static int NORM_PRIORITY = 5;
    /**
     * The maximum priority that a thread can have. 
     */
    public final static int MAX_PRIORITY = 10;


}

在编码时直接使用这些优先级常量，可以说在大部分情况下MAX_PRIORITY的线程回比MIN_PRIORITY的线程优先运行，但是不能认为是必然会先运行，不能把这个优先级做为核心业务的必然条件，Java无法保证优先级高肯定会先执行，只能保证高优先级有更多的执行机会。因此，建议在开发时只使用此三类优先级，没有必要使用其他7个数字，这样也可以保证在不同的操作系统上优先级的表现基本相同。

大家也许会问，如果优先级相同呢？这很好办，也是由操作系统决定的。基本上是按照FIFO原则(先入先出，First Input First Output)，但也是不能完全保证。

欢迎转载，转载请注明出处！
简书ID：@我没有三颗心脏
github：wmyskxz
欢迎关注公众微信号：wmyskxz_javaweb
分享自己的Java Web学习之路以及各种Java学习资料