避免创建不必要的对象
一般来说，如果对象是不可变的，最好重用一个对象，而不是每次需要的时候，就去重新一个相同功能的对象，重用可以提高性能。
作为一个反面例子，看看下面的语句：
String s = new String("java");//类似于包装类，基础数据装箱
每次执行以上代码的时候，都会重新创建一个新的String实例，但是创建的实例功能和意义完全是不必要的，String构造器的参数（“java”）本身就是一个String实例，功能方面等同于构造器所创建的对象，如果以上代码是在一个循环体内，或者在一个被频繁调用的方法中，就会出现成千上万个不必要的实例。
改进后的代码如下：
String s = "java";//基础数据类型被丢到常量池了
这个版本的代码只用了一个实例，而不是每次调用时就创建一个新的实例，而且，它可以保证，对于所有在同一台虚拟机上运行的代码，只要包含相同的字符串字面常量，该对象就会被重用。
对于同时提供了静态工厂方法和构造器的不可变类，优先使用静态工厂方法，而不是构造器，以避免创建不必要的对象。例如：Boolean b = Boolean.valueOf(true);总是应该优先于Boolean b = new Boolean(true);
有些对象创建的代价比其他对象高得多，如果重复的需要这个’‘昂贵的类’，建议将它缓存起来，但是，在实际情况中，在创建这种类的时候，并非总是那么显而易见，下面介绍一种最容易的方法，使用一个正则表达式来验证是否为一个有效的邮箱：
public static boolean validationEmail(String email){
return email.matches("^([a-z0-9A-Z]+[-|\\.]?)+[a-z0-9A-Z]@([a-z0-9A-Z]+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,}$");
}
这个实现的问题它依赖于String.matches();方法，虽然String.matches()方法最易于查看一个字符串是否与正则表达式相匹配，但并不适合在注重性能的形况下重复使用，它在内部为正则表达式创建了一个Pattern实例：
// String.matches();方法源代码
public static boolean matches(String regex, CharSequence input) {
Pattern p = Pattern.compile(regex);
Matcher m = p.matcher(input);
return m.matches();
}
public static Pattern compile(String regex) {
return new Pattern(regex, 0);
}
但是每次调用，却只使用一次，之后就进行垃圾回收了，创建Pattern实例的代价很高，因为需要将正则表达式编译成一个有限状态机。
为了提升性能，应该显示的将正则表达式编译成一个Pattern不可变的实例，让它成为类初始化的一部分，并将它缓存起来，当每次调用validationEmail方法进行验证的时候，就会重用同一个实例：
private static final Pattern VALIDATION_RMAIL = Pattern.compile("^([a-z0-9A-Z]+[-|\\.]?)+[a-z0-9A-Z]@([a-z0-9A-Z]+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,}$");
public static boolean validationEmail(String email){
return VALIDATION_RMAIL.matcher(email).matches();
}
例如，Map接口的keySet方法返回该Map对象的Set视图，其中包含该Map中所有的键(key)，看是好像每次调用keySet方法都应该生成一个新的set实例，但是，对于一个给定的Map对象，实际上每次调用keySet方法返回的都是相同的set实例，虽然被返回的set实例可以被修改，但是所有返回的对象在功能上是等同，当其中一个对象发生变化，所有其他的返回对象也会发生变化，因为它们是由同一个Map支撑的， 虽然创建keySet视图对象的多个实例并无害处，却是不必要的，也没有好处。
// Map keySet() 方法源代码
public Set<K> keySet() {
Set<K> ks = keySet;
if (ks == null) {
ks = new KeySet();
keySet = ks;
}
return ks;
}
另一种创建多于对象的方法，称为自动装箱，它允许程序员将基本类型和装箱类型混用，按需要自动装箱和拆箱，自动装箱使得基本类型和装箱类型之间的差别变得模糊，但是并没有完全消除，它们在语义上还有微妙的差别，在性能也有着比较明显的差别，下面这个程序计算所有int正整数的总和，为此，必须使用long，因为int不够到，无法容纳所有int正整数值的总和。
private static long sum(){
Long sum = 0L;
for(long x = 0;x <= Integer.MAX_VALUE; x++){
sum += x;
}
return sum;
}
这段程序算出的答案是正确的，但是运行速度要慢些，因为将变量sum声明成了Long而不是long，意味着程序构造了大约2^31个多余的Long实例（大约每次往Long sum中增加long x时就构造一个实例），将sum声明从Long改为long，可以使运行时间从6.3秒减少了0.59秒。结论很明显，要优先使用基本类型而不是装箱类型，也要当心无意间的自动装箱。
当然，也不要错误的认为创建对象的代价非常昂贵，而尽可能的避免创建对象。相反，由于小对象的构造器只做了很少的显示工作，所以小对象的创建和回收是非常廉价的，特别是在现代的JVM实现上更是如此，通过创建附加的对象，提升程序的清晰性，简洁性和功能性，这通常是好事。
反之，通过维护自己的对象池来避免创建对象并不是一种好的做法，除非池中的对象都是非常重量级的，正确使用对象吃的典型示列就是数据量连接池，建立数据库连接的代价非常昂贵，因此重用这些对象非常有意义。而且，数据库的许可限制只能使用一定数量的连接对象。但是，一般而言，维护自己的对象池必定会把代码弄得很乱，
同时增加内存占用，并且还会损害性能，现代JVM实现具有高度优化的垃圾回收器，其性能很容易就超过了轻量级的对象池的性能。
注意：在提倡使用保护性的拷贝的时候，重用对象付出的代价要远远大于创建重复对象所付出的代价，必要时如果没有实施保护性拷贝，将会导致潜在的安全漏洞和Bug，而创建重复对象只会影响程序的风格和性能。
参考文章：https://www.jianshu.com/p/f5e40a401830