前文链接

方法

方法设计

方法是可组合、可重用的代码小单位。
编写高内聚低耦合的整洁方法，同时 把代码有效组织起来。
代码简单直接、不隐藏设计者的意图、用干净利落的抽象和直截了当的控 制语句将方法有机组织起来。
契约式设计、防御式编程有利于编写安全可靠的代码。可以用在要求满足前置/后置条件的场景，例如null判断。 或者使用@NotNull,@Nullable来提升可靠性。 不要使用运行时类型擦除后相同的重载方法。

主要内容

• 规则5.1 避免方法过长，不超过50行（非空非注释）
  -例外：某些实现算法的方法，由于算法的聚合性与功能的全面性，可能会超过50行。

• 规则5.2 避免方法的代码块嵌套过深，不要超过4层
  -说明：
  函数本身算一层，try-catch的不算一层嵌套。
  方法内的lambda表达式、局部类和匿名类嵌 套层次以内层方法来计算，不累积enclosing method的嵌套层次。
  方法的代码块嵌套深度指的是方法中的代码控制块（例如：if、for、while、switch等）之间互相包含的深度。
  卫语句减少嵌套示例：

int foo(Item msg) {     if (isReceived) {         type = getMsgType(msg);         if (type != UNKNOWN) {             return dealMsg(..);         }     }     return -1; 
}int foo(Item msg) {     if (!isReceived) {         return -1;     }          type = getMsgType(msg);     if (type == UNKNOWN) {         return -1;     }          return dealMsg(..); 
} 

• 规则5.3 使用类名调用静态方法，而不要使用实例或表达式来调用

方法参数与返回值

建议

• 不要把方法的入参当做工作变量/临时变量
• 方法的参数个数不应超过5个
• 谨慎使用可变数量参数的方法
• 构造方法如果参数较多，尽量重用
• 对于返回数组或者容器的方法，应返回长度为0的数组或 者容器，代替返回null

类和接口

类

• 规则6.1 避免在无关的变量或无关的概念之间重用名字，避免隐 藏（hide）、遮蔽（shadow）和遮掩（obscure）
  -说明：在声明子类的字段、方法或嵌套类型时，除了覆写（override）、重载（overload）之 外，要尽量避免重名导致的隐藏（hide）、遮蔽（shadow）和遮掩（obscure）。

覆写（override）------子类与父类间

一个实例方法可以覆写（override）在其超类中可访问到（非private）的具有相同签名的实例方 法（非static），从而使能了动态分派（dynamic dispatch）；
换句话说，VM 将基于实例的运行 期类型来选择要调用的覆写方法。

 class Base {         public void fn() {         }     } class Derived extends Base {         @Override         public void fn() {         } // overrides Base.f()     }

• 规则6.2 不要在父类的构造方法中调用可能被子类覆写的方法
  -说明：当在父类构造方法中调用可能被子类覆写的方法时，构造方法的表现是不可预知的，很可 能会导致异常。而问题出现后，又往往难以快速定位。这个问题是由于在Java中，当子类初始化 的时候，会调用父类的构造方法，当构造方法调用了被子类覆写的方法，往往会由于子类的初始化未完成而导致异常。

• 规则6.3 覆写equals方法时，应同时覆写hashCode方法
  -说明：因为Java对象在存放到基于Hash的集合（如HashMap、HashTable等）时，会使用其 Hash码进行索引，如果只覆写了equals方法，而没有正确覆写hashCode方法，则会导致效率低 下甚至出错；
  Java对象的hashCode方法有如下约定：
  1、同一次运行中，同一个对象如果equals方法中用到的信息没有改变，多次调用hashCode方法返 回值必须相同；
  2、如果两个对象调用equals方法时相等，则这两个对象的hashCode方法，也必须返回相同的值；
  3、如果两个对象调用equals方法时不相等，则这两个对象的hashCode方法，不要求其返回值不 同，但是出于性能考虑，但好能不同；

• 规则6.4 子类覆写父类方法时应加上@Override注解

建议

• 应避免public且非final的成员字段定义
• 避免基本类型与其包装类型的同名重载方法

覆写（override）–子类与父类

子类之中有可能定义和父类完全相同的方法或属性的名称
当一个类中的方法被覆写后，如果实例化的是这个子类对象，则调用的方法就是被覆写过的方法。

重载（overload）------类内部

在某个类中的方法可以重载（overload）另一个方法，只要它们具有相同的名字和不同的签名。
由调用所指定的重载方法是在编译期选定的。
重载歧义或混淆的场景：
可变参数
包装类型,例如int 与Integer。这时，应该修改方法名称，如果是构造方法，则委托到不同名的静态方法。

隐藏（hide）------子类与父类间

一个属性、静态方法或内部类可以分别隐藏（hide）在其超类中可访问到的具有相同名字（对方 法而言就是相同的方法签名）的所有属性、方法或内部类。
上述成员被隐藏后，将阻止其被继承：

class Swan {      public static void fly() {          System.out.println("swan can fly ...");      }  }    
class UglyDuck extends Swan {      public static void fly() {  // hide Swan.fly          System.out.println("ugly duck can't fly ...");      }  }    
public class TestFly {      public static void main(String[] args) {          Swan swan = new Swan();          Swan uglyDuck = new UglyDuck();          swan.fly();     // 打印swan can fly ...          uglyDuck.fly(); // 还是打印swan can fly ...，hide让人以为是重载了，其实 不是      }  }

遮蔽（shadow）------类内部

一个变量、方法或类可以分别遮蔽（shadow）在类内部具有相同名字的变量、方法或类。
如果一 个实体被遮蔽了，那么就无法用简单名引用到它：

 class WhoKnows {      static String sentence = "I don't know.";            public static void main(String[] args) {          String sentence = "I know!"; // 遮蔽了类的静态成员sentenceSystem.out.println(sentence); // 打印的是I know！   }  }

遮掩（obscure）------类内部

一个变量可以遮掩具有相同名字的一个类，只要它们都在同一个范围内：如果这个名字被用于变 量与类都被许可的范围，那么它将引用到变量上。相似地，一个变量或一个类型可以遮掩一个 包。
遮掩是唯一一种两个名字位于不同的名字空间的名字重用形式，这些名字空间包括：变量、 包、方法或类型。如果一个类或一个包被遮掩了，那么你不能通过其简单名引用到它，除非是在 这样一个上下文环境中，即语法只允许在其名字空间中出现一种名字。
例如：

 public class Obscure {      static String System; // Obscures type java.lang.System        public static void main(String[] args) {          // Next line won't compile: System refers to static fieldSystem.out.println("hello, obscure world!");      }  }

接口

建议

• 接口定义中去掉多余的修饰词
  -说明：在接口定义中，属性已缺省具有public static final修饰词，方法已缺省具有public abstract修饰词。因此在代码中不要再次提供这些修饰词。
• Java 8中可在接口中加上静态方法表示相关的工厂或助手方法

异常和日志

异常

对可容错处理的情况使用受检异常（checked exception），对编程错误使用运行时异常 （runtime exception）。
只针对真正异常的情况才使用exception机制。 在抛出异常的细节信息 中，应包含详细的诊断信息。
使用异常来做业务逻辑错误处理，而非错误码。

• 规则7.1 不要通过一个空的catch块忽略异常
  -说明:空的catch块会使异常达不到应有的目的;至少，在一个空catch块中也应该添加注 释，解释为什么可以忽略这个异常，对于那些不应该频繁发生的异常，还应该将异常信息记录到日志中
• 规则7.2 方法抛出的异常，应该与本身的抽象层次相对应
  -说明：当方法把一个异常传给调用方时，请确保异常的抽象层次与方法的抽象层次是一致的
• 规则7.3 在finally块中不要使用return、break或continue使finally块非正常结束
  -说明：在finally中使用return、break或continue会使finally块非正常结束，造成的影响是，即使 在try块或catch中抛出了异常，也会因为finally非正常结束而导致无法抛出。finally块非正常结束 会有编译告警。

建议

• 不要直接捕获受检异常的基类Exception
  -说明：捕获受检异常的目的是为了进行恢复，而如果不加区分的捕获所有受检异常，则无法进行 对应异常的恢复处理。
  因此，应该区分并捕获具体的异常。捕获时，列出多种具体异常，如果用同一个处理逻辑，必须用并语法(ExceptionType| …| ExceptionType 变量）来减少重复代码。
  JDK1.7允许将 catch 子句组合成一个代码块，而无需使用危险的 catch-all 子句或复制整个代码 块。
  例外:
  1.编码过程中遇到了第三方api直接抛出Exception异常，代码中需要使用 catch(Exception e)
  2.在框架中属于“公共服务”性质的“兜底”处理，例如事件循环
• 一个方法不应抛出超过5个异常，并在Javadoc的@throws标签中记 录每个抛出的异常及其条件
  -说明：方法抛出过多的异常，会增加客户端异常处理的工作，同时也表明方法承担了过多的职 责。如果没有为抛出的异常建立Javadoc，其他人就很难或者根本不可能有效地使用你的类和接口。

日志

日志信息准确、繁简得当，满足快速定位的需要。

• 规则7.4 日志的记录，不要使用 System.out 与 System.err 进行控制台打印，进行处理应使用Facade模式的日志框架（例如：产品自研的，或第三方 Slf4j等）
  -说明:专用日志工具比控制台打印提供了更丰富的日志记录功能，且使用更加简单
  示例:

start = System.currentTimeMillis();  
// 其他加载数据的代码  
LOGGER.info("items loaded, use {}ms." , (System.currentTimeMillis() - start)); 

• 规则7.5 日志工具Logger类的实例应声明为private static final
  -说明:
  1.声明为private是出于访问封装的考虑，防止Logger类的实例对象被其他类非法使用
  2.声明为static是为了防止重复new出Logger类的实例，造成资源的浪费，同时防止实例被序列 化，造成安全风险（精心设计的library除外）
  3.声明为final是因为在类的生命周期内无需变更Logger类的实例
  例如:

private static final Logger LOGGER = LoggerFacotry.getLogger(com.huawei.product.MyClass.class); 

• 规则7.6 日志应分等级，对info及以下，使用条件形式或者使用占位符的方式
  -说明:日志分等级，在定位问题时，可以快速有效屏蔽大量低级别信息。 日志可分为以下级别：trace(有的也叫verbose)、debug、info、warning、error、 fatal。
  推荐与具体实现有关的日志记录trace或debug级，一般的业务处理日志用info级，不影响业务进行的错误用warning级，例如用户输入参数错误， 而error或fatal级，只记录系统逻辑出 错、异常或者重要的错误信息，常常向运维系统报警。 建议生产环境不输出trace或debug日志； 有选择地输出info日志；输出warning、error、fatal日志
  如果日志级别是warning，下述示例中日志不会打印，但是会执行字符串拼接操作，如果symbol 是对象，会执行toString()方法，浪费系统资源，执行了上述操作，最终日志却没有打印。 推荐例 子：

// (条件)建议采用如下方式 
if (LOGGER.isDebugEnabled()) {     LOGGER.debug("Processing trade with id: " + id + "and symbol: " + symbol);  
} 
// 或者使用占位符 
LOGGER.debug("Processing trade with id: {} and symbol: {}" , id, symbol); 

• 规则7.7 非仅限于中文区销售产品禁止用中文打印日志

编程实践

多线程并发

使用Java标准库提供的高级同步机制在多线程中共享数据。 针对线程安全性，需要进行文档 （javadoc）说明。
Java 8使用CompletableFuture编写异步任务。 Thinking in parallel，Java 8 使用stream做隐式的自动并行化，替代显式的循环。
对多个资源、数据库表、对象同时加锁时， 需要保持一致的加锁顺序，否则可能会造成死锁。
高并发时，同步调用应该去考量锁的性能损 耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体； 能用对象锁，就不要用 类锁。
避免在锁代码块中调用 RPC方法。 应该回收自定义的 ThreadLocal 变量，在try-finally调 用其remove()方法，否则可能会造成内存泄露。
在高并发场景中，避免使用等于判断作为中断或 退出的条件。容易产生等值判断被“击穿” 的情况，使用大于或小于的区间判断条件来代替。
在使用阻塞等待获取锁的lock.lock()方式中，应该在try 代码块之外，并且在加锁方法与try代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在finally 中无法解锁。 在使用尝试机 制来获取锁的lock.tryLock()方式中，进入业务代码块之前，必须先判断当前线程是否持有 锁。
参考范例:

 Lock lock = new XxxLock();    // ...    boolean isLocked = lock.tryLock();    if (isLocked) {        try {            doBiz();        } finally {            lock.unlock();        }    } 

• 规则8.1.1 避免数据竟争data race
  -说明:Java 1.5开始，Java Memory Model采用happens-before关系，来规定并发执行中，读写操作允许读到什么值，不允许读到什么值。
  两个线程分别对一个非volatile的共享变量进行访问 操作，其中至少一个操作是写操作，且这两个操作之间没有happens-before关系，就是data race。正确同步的(correctly synchronized)执行是指没有data race的执行。
  例子(使用volatile变量同步)

private volatile Foo sharedFoo; // volatile共享变量 public void publisher() {     Foo newFoo = new Foo();     newFoo.nr = 42; // (1) 写操作：写入42     sharedFoo = newFoo; // (2) volatile写操作：写入新对象的引用 
} public void consumer() {     Foo myFoo;     do {         myFoo = sharedFoo; // (3) volatile读操作：读sharedFoo里的值     } while (myFoo == null) // 不等于null就证明(3)的volatile读读到了(2)的 volatile写写入的内容，因此(2)happens before(3)     assert myFoo.nr == 42; // (4) 读操作：读x变量的值，只要(2)happens before(3)，(4)就必然读到(1)写的42 
} 

一般来说，如果使用锁，那么读和写都要加锁，而不是写线程需要加锁，而读的线程可以不加锁。

• 规则8.1.2 创建新线程时需指定线程名
  -说明：推荐使用线程池，有些场景不得不独立创建Thread时,遵循本规则,指定线程名方便进行问题定位。日志或者dump中会包含线程的名称，而缺省的线程名Thread-n无法区分出是哪个线程，给问题定位带来不便。 工具检查提示：是否调用了new Thread的带name的构造 方法，并且后面是否调用了thread.setName(name)。线程池是通过线程工厂 ThreadFactory.newThread(Runnable r)方法来设定名字的。
  示例:

public class MyThread extends Thread {     public MyThread() {         super.setName("MyThreadName");        // ...     } 
}

• 规则8.1.3 使用Thread对象的setUncaughtExceptionHandler 方法注册未捕获异常处理者
  -说明：推荐使用线程池，线程池(包括cheduledThreadPoolExecutor)的线程 setUncaughtExceptionHandler是无效的。但如果有些场景不得不独立创建Thread时，遵循 本规则。
  Java多线程程序中，所有线程都不允许抛出未捕获的checked exception，也就是说各个线程需要自己把自己的checked exception处理掉。但是无法避免的是unchecked exception， 也就是RuntimeException，当抛出异常时子线程会结束，但主线程不会知道，因为主线程通过 try catch是无法捕获子线程异常的。Thread对象提供了setUncaughtExceptionHandler方法用 来获取线程中产生的异常。而且还可使用Thread.setDefaultUncaughtExceptionHandler，为所 有线程设置默认异常捕获方法。
  程序员应注意的是，在执行周期性任务例如 ScheduledExecutorService时，为了健壮性，可考虑在提交的Runnable的run方法内捕获高层级 的异常。 ScheduledExecutorService的各种schedule方法，可以通过其返回的ScheduledFuture 对象获取其异常。
  示例：

 public class TestUncaughtException {      public static void main(String[] args) {          TestThread thread = new TestThread("meaningful-name");thread.setUncaughtExceptionHandler(new UncaughtExceptionHandler() {public void uncaughtException(Thread t, Throwable e) {System.out.println(t.getName() + " : " + e.getMessage());              }          });            thread.start();      }        public static class TestThread extends Thread {          public TestThread() {          }            @Override          public void run() {              throw new RuntimeException("just a test");          }      }  }   

• 规则8.1.4 不要依赖线程调度器、线程优先级和yield()方法
  -说明：Java中的线程调度，是基于操作系统以及JVM的实现，在不同的操作系统中，或者不同厂 商的JVM（如Oracle、IBM等），即使是同一套代码，其多线程的调度机制也是不一样的；。同理，程序如果依赖Java的线程优先级来 确保正确性，也是不可移植的； 而Thread.yield()对线程调度器仅仅是个提示，不保证确定的效 果，因此代码也不能依赖Thread.yield()方法
• 规则8.1.5 采用Java1.5提供新并发工具代替wait()和notify()
  -说明：自从Java1.5发行版本开始，Java平台就提供了更高级的并发工具，它们可以完成以前必须在wait()和notify()上手写代码来完成的各项工作。
  java.util.concurrent更高级的并发工具分成三类：Executor Framework、并发集合（Concurrent Collection）以及同步器 （Synchronizer）。
  性能不是特别苛刻时可以采用synchronized简单可读

建议

• 线程中断由业务代码来协作完成，慎用 Thread.interrupt方法
  -说明：优先使用协作式的线程同步机制，如j.u.c包中的各种synchronizer,加锁的共享变量、 volatile共享变量等，来通知一个线程中止作业。 慎用Thread.interrupt方法，它使文件句柄被强 制关闭，注意此时的文件句柄不是被程序代码调close方法关闭的，此时程序代码是不知道文件句 柄被关闭的，如果其他地方继续调用文件的其他方法，就会导致莫名奇妙的IO异常。强制关闭文 件句柄的代码参见：java.nio.channels.spi.AbstractInterruptibleChannel#begin。 当应用 Thread.interrupt方法时,注意如下用法。
  示例（使用interrupt中止线程执行）：

public long runThread1(long max) throws InterruptedException { // 标注throws     long result = 0L;     for (long i = 0L; i < max; i++) {         result += i;         if (Thread.interrupted()) { // 周期性检查自己是否被interrupt             throw new InterruptedException("Interrupted during summing"); // 主动中止，抛出异常         }     }     return result; 
} public static void main(String args) throws Exception {     Thread thread1 = new Thread(() -> {         try {             long result = runThread1(100000000L);             System.out.println(result);         } catch (InterruptedException e) {             // 线程顶层函数，实现Runnable，不处理，正常中止。             logger.log("worker thread stopped"); // 可以记录日志。         }     },"meaningful-name");     thread1.start();     Thread.sleep(1000);     thread1.interrupt(); // 用interrupt()方法请求中止     thread1.join(); 
}

注：在编写需要中止的多线程程序时，必须选用能够响应interrupt的标准库或第三方库。例如Java标准库 中的会阻塞的方法（如Thread.sleep()或者SocketChannel.write()）一般会在interrupt之 后抛出InterruptedException。但有某些方法则不理会interrupt，如Socket.write()，必须回避这些方法。
注：不可以使用非volatile变量作为通知用的变量

建议

• 避免不加控制地创建新线程，而应该使用线程池来管控资源
  -说明：Java虚拟机能够管理的线程数量有限，不加控制的创建新线程可能会导致Java虚拟机崩 溃。建议用Java 1.5之后提供的线程池ThreadPoolExecutor来管理线程资源。
  注：线程池不应该使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式更加明确线程池的运行规则，规避资源耗尽的风险

运算和表达式

建议

• 用括号明确表达式的操作顺序，避免过分依赖默认优 先级
• 在条件表达式?:的第2和第3个操作数使用同样的类型
• 表达式的比较，应当遵循左侧倾向于变化、右侧倾向 于不变的原则

控制语句

• 规则8.3.1 不要在控制性条件表达式中执行赋值
• 规则8.3.2 不要在foreach循环里进行元素的 remove/add 操作, 删除元素请使用removeIf方法或Iterator
  -例如：

// 使用Java 8 Collection中的removeIf方法  
list.removeIf(item -> "1".equals(item));   
// 或者 
Iterator<String> iterator = list.iterator(); 
while (iterator.hasNext()) {     String item = iterator.next();     if (isRemovable()) {         iterator.remove();     } 
}

建议

• 对于if-else if（后续可能有多个else if）类型的条件 判断，后应该包含一个else分支

序列化

• 规则8.4.1 序列化对象中的HashMap、HashSet或HashTable 等集合不能包含对象自身的引用
  -说明：如果一个被序列化的对象中，包含有HashMap、HashSet或HashTable集合，则这些集合 中不允许保存当前被序列化对象的直接或间接引用。因为，这些集合类型在反序列化的时候，会 调用到当前序列化对象的hashCode方法，而此时（序列化对象还未完全加载）计算出的 hashCode有可能不正确，从而导致对象放置位置错误，破坏反序列化的实例。

建议

• 尽量不要实现Serializable接口
  -说明：使用Java内置序列化功能的主要场景是为了在当前程序之外保存对象并在需要的时候重新获得对象。序列化不必要地对外公开了对象的物理实现 . 序列化容易使一个类对其初的内部表示产生依赖 . 编写正确的反序列化代码有很大的挑战 . 序列化增大了安全风险 . 序列化增加了测试的难度。综 上，序列化耦合了对象的逻辑信息和物理实现，使得开发者在面对领域需求之外需要额外关注很多专有的细节知识。在可能的情况下，使用其它替代方案将会减少工作量、减少bug、降低出现 安全漏洞的风险。

• 实现Serializable接口的可序列化类应该显式声明 serialVersionUID
  -说明： 如果可序列化类未显式声明 serialVersionUID，则序列化运行时将基于该类的各个方面计算该类的默认 serialVersionUID 值，如“Java™ 对象序列化规范”中所述。
  不过，强烈建议所有 可序列化类都显式声明 serialVersionUID 值，原因计算默认的 serialVersionUID 对类的详细信息具有较高的敏感性，根据编译器实现的不同可能千差万别，这样在反序列化过程中可能会导致意 外的 InvalidClassException。因此，为保证 serialVersionUID 值跨不同 java 编译器实现的一致 性，序列化类必须声明一个明确的 serialVersionUID 值。还强烈建议使用 private 修改器显式声 明 serialVersionUID（如果可能），原因是这种声明仅应用于立即声明类 – serialVersionUID 字 段作为继承成员没有用处

• 不应序列化直接指向系统资源的句柄
  -说明：序列化对象可以在Java程序以外被修改，除非它们受特殊机制保护（如jar签名）。如果一个指向 系统资源的对象可以被序列化，并且攻击者可以替换掉该对象的序列化形式，那么该对象就具备 修改特定句柄指向的系统资源的能力。例如，攻击者可以修改一个可序列化的文件句柄指向系统 上的任意文件。 以下对象序列化形式暴露了可修改的文件路径。当对象被反序列化时，操作会使 用可修改的路径执行，这会导致读取或者修改错误的文件。 因此，建议实现Serializable的类，其 字段为File或FileDescriptor时，用transient修饰

泛型

建议

• 尽量消除非受检的异常，不应该在整个类上使用 SuppressWarning
• 方法的设计可优先考虑泛型
• 优先使用泛型集合，而不是数组
• 声明一个泛型类通过限定符限制可用的泛型类型

其他语言特性

使用JDK自带的API或广泛使用的开源库，不要自己写类似的功能。
。

Comparator实现类要满足三 个条件（对称的，传递的，恒定的），不然 Arrays.sort， Collections.sort 会抛 IllegalArgumentException 异常。
使用工具类Arrays.asList()把数组转换成集合时，不能使用其 修改集合相关的方法，它的 add/remove/clear 方法会抛出UnsupportedOperationException 异常。
Map的方法 keySet()/values()/entrySet()返回集合对象时，不可以对其进行添加元素操 作，否则会抛出 UnsupportedOperationException 异常。
Collections类返回的对象，如 emptyList()/singletonList()，及collection的 of()方法等，都是 immutable的，不可对其进行添加 或者删除元素的操作。
ArrayList的subList 结果不可强转成 ArrayList，否则会抛出
ClassCastException 异常，高度注意对原集合元素的增删，均会导致subList的遍历、增删产生 ConcurrentModificationException 异常。
在使用Collection 接口任何实现类的 addAll()方法 时，应确保输入的集合参数c非空。因为其代码直接解引用c.toArray()。
在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。
日期格式化时，传入pattern中表示年份统一使 用小写的y。
JDK8中，考虑使用Instant 代替 Date， LocalDateTime 代替 Calendar， DateTimeFormatter 代替 SimpleDateFormat。

• 规则8.6.1 不要使用已标注为@deprecated的方法
  -说明：标注为@deprecated的方法，是由于各种原因被JDK废弃的方法，为了保持兼容性而没有删除，新写的代码应避免使用这些方法，而应该使用JDK推荐的代替方法。

建议

• Java 8使用Optional代替null作为返回值或者可能的缺失值
  -说明：Optional表示两种情形，一种是存在值，一种缺失值。例如Optional email； 可以表示email是有或无值的。
  注意：
  不要对optional对象赋值/返回为null，或与null比较,例如: Optional foo = null; // bad
  不应该返回Optional,Optional,Optional,而用 OptionalInt,OptionalLong,OptionalDouble
  示例：

Optional<Image> filter(Image bitmap) {     return Optional.of(bitmap); } Optional<Image> scale(Image bitmap) {     return Optional.of(bitmap); } public void optionalExample(String path, ImageView view) {     Optional<Image> maybeBitmap = readFromFile(path);maybeBitmap.flatMap(bitmap -> filter(bitmap)).flatMap(bitmap -> scale(bitmap))         .ifPresent(bitmap -> view.setImage(bitmap));
} Optional<Image> readFromFile(String path) {     return Optional.empty(); }

• 避免枚举常量序号的产生依赖于ordinal()方法
  -说明：Java枚举类型通过ordinal()方法返回枚举常量的排列序号。默认情况下，序号是根据声明 顺序从0开始累加，但某些情况下我们希望指定某些枚举常量为某个固定值以代表特殊意义。
  示例：

enum Keyboard {      MOUSE_KEY_LEFT(1),      MOUSE_KEY_RIGHT(2),      MOUSE_KEY_CANCEL(4),      MOUSE_KEY_MIDDLE(8);            private final int mouseKeyValue;            Keyboard(int value) {          this.mouseKeyValue = value;      }            public int getMouseKeyValue() {          return mouseKeyValue;      }  
} 

性能与资源管理

性能

JVM的版本、实现不同，对性能影响很大。当你基于较大的数据集基准测试确实有性能瓶颈的 时，考虑以下规则、建议来优化。

• 将集合转为数组时使用toArray()方法且参数是类型相 同零长度的数组
  -说明：toArray的参数是零长度的数组有更好的性能，代码更加简洁。 使用toArray带参方法， 数组容量大小的length：

建议

• 使用System.arraycopy()进行数组复制
  -说明：在将一个数组对象复制成另外一个数组对象时，不要自己使用循环复制，可以使用Java提 供的System.arraycopy()功能来复制数据对象，这样做可以避免出错，而且效率会更高。
  示例：

int[] src = { 1, 2, 3, 4, 5 };  
int[] dest = new int[5];  
System.arraycopy(src, 0, dest, 0, 5); 

• 初始化集合时，如果已知或可以预测元素数量，则给出初始化大小；不能预测的情况下使用默认大小

资源管理

• 规则8.7.2 避免创建不必要的对象
  -说明：重用一个已经创建的对象比创建一个新的对象要好得多，除非确实需要重新创建。

• 规则8.7.3 将对象存入HashSet，或作为key存入HashMap(或
  HashTable)后，必须确保该对象的hashcode值不变，避免因为 hashcode值变化导致不能从集合内删除该对象
  -说明：对于Hash集合(HashMap，HashSet等)而言，对象的hashcode至关重要，在hash集合内 查找该对象完全依赖此值。如果一个对象存入Hash集合后hashcode随即发生变化，结果就是无 法在集合内找到该对象，进而不能删除该对象，终导致内存泄漏

• 规则8.7.4 进行IO类操作时，应该在try-with-resource或 finally里关闭资源
  -说明：申请的资源不使用时，需要及时释放。而在产生异常时，资源释放常被忽视。因此要求在 IO、数据库操作等需要显示调用关闭方法如close()释放资源时，必须在try -catch-finally的finally 中调用关闭方法。

• 规则8.7.5 禁止使用主动GC（除非在密码、RMI等方面），尤其 是在频繁/周期性的逻辑中
  -说明：虽然主动调用GC方法时JVM规范不承诺立即进行垃圾回收操作，但是Oracle Java SE JVM 在绝大多数情况下响应此方法调用，会触发JVM的全量GC操作，这会增加GC的次数，也就增加了 程序因为GC而停顿的时间；而且在GC过程中的某些阶段程序会完全停顿，这会让程序失去响 应，对系统造成非常大的风险。在频率/周期性的逻辑（for循环、定时器）中更要尽量避免主动 GC的调用。

• 规则8.7.6 禁止使用finalize()方法
  -说明：finalize方法的调用时机是不可预测的，常常也是危险的。使用finalize可能会导致不稳定的 行为，更差的性能，以及带来移植性问题

可移植性

• 规则8.8.1 不要在代码中硬编码"\n"和"\r"作为换行符号
  -说明：回车换行符在不同操作系统下是有区别的，如果需要换行，尽量用PrintStream、 PrintWriter的println来代替在字符串中使用硬编码换行符

国际化

• 规则8.9.1 在所有的输入输出环节，指明正确的编码方式，进行 正确的字符到字节，或字节到字符的转换
  -说明：使用java.nio.charset中的类编码解码字符集
• 规则8.9.2 不要依赖平台默认的字符编码方式，使用UTF-8
  -说明：例如，中文Windows下，默认的编码为GBK，英文linux下，默认编码为ISO-8859-1。依赖 平台默认值意味着同样的程序在不同的平台上可能产生不同的结果。
• 规则8.9.3 字符串大小写转换、数字格式化为西方数字时，必须 加上Locale.ROOT或Locale.ENGLISH
  -说明：String类的toUpperCase()和toLowerCase()方法、format()方法，如果不输入参数，则会 按当前系统默认的编码模式转换，因此转换结果可能并非如你所预期
  示例：

String testString = "i";       System.out.println(testString.toUpperCase(Locale.ROOT));  
String testString2 = String.format(Locale.ROOT, "%d", 2);  System.out.println(testString2);