Tip-1 考虑用静态工厂方法代替构造器
-
静态工厂方法优势
- 静态工厂方法有名称，更直观和易于理解
- 不必每次都创建新的对象 可以使用 初始化时创建的静态对象
- 可以返回该类的子类对象
- 在创建需要参数来构建的对象时，可以简化代码
-
劣势
- 无法创建私有类对象
- 与普通的静态方法没有任何区别，很难发现这是一个可以创建对象的工厂方法，而不像构造器是在API中明确标识区别的
Tip-2 构造器有多个参数时考虑构建器(Builder模式)
//构建器
public class NutrilonFacts {
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{
//请求参数
private final int servingSize;
private final int servings;
//
private final int calories = 0;
private final int fat = 0;
private final int sodium = 0;
private final 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 carbohydrate(int val){
carbohydrate = val;
return this;
}
public Builder sodium(int val){
sodium = val;
return this;
}
public NutrilonFacts build(){
return new NuuritionFacts(this);
}
}
private NutritionFacts(Builder builder){
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate = builder.carbohydrate;
}
}
//调用代码
NutritionFacts cocaCola = new NutritionFacts.Builder(240,8).calories(100).sodium(35).carbohydrate(27).build();
-
优势
- builder模式实现了具名的可选参数,简化了构造器多参数的实现和易读性
- 比JavaBean的setting 方法模式 更加安全
-
劣势
- Builder模式可能比重叠构造器模式更加冗长，只有4个或更多参数才有明确的需求使用Builder模式
若将来类可能有多个可添加参数，最好一开始就使用Builder模式
Tip-3 用私有构造器或枚举强化单例模式
实现单例模式有两种方法
- 私有构造器+共有静态成员对象
public class Elvis{
public static final Elvis INSTANCE = new Elvis();
private Elvis(){....}
public void leaveTheBuilding(){.....}
}
- 静态工厂方法+私有静态成员对象
public class Elvis{
private static final Elvis INSTANCE = new Elvis();
private Elvis(){....}
public static Elvis getInstance(){ return INSTANCE;}
public void leaveTheBuilding(){.....}
}
基本的单例模式在反序列化的时候，就会创建一个新的对象，导致出现多个单例对象，为了防止这种情况，有两种解决方案.
- 在类中加入readResolve()方法
private Object readResolve(){
return INSTANCE;
}
- 编写一个包含单个元素的枚举类型
//使用枚举来控制对象唯一,并无偿的提供了序列化机制，绝对防止多次实例化
// 单元素的枚举类型已经成为实现单例模式最佳的方法
public enum Elvis{
INSTANCE;
public void leaveTheBuilding(){
.....
}
}
Tip-4 通过私有化构造器实现单例模式（so easy 不做记录）
Tip-5 避免创建不必要的对象
//基础知识
//这种方式创建 会导致存在不必要的String 实例
String s = new String("stringette");
// 改进后 保证只有一个
String s = "stringette";
要优先使用基本数据类型 而不是Integer 这种装箱类型 性能差距明显
数据库连接池 线程池 便是一种对象的重用 ，因为二者对象的创建代价是非常昂贵的
Tip-6 消除过期的对象引用
// 只需要简单的赋值为null
String s = new String("ddd");
s = null;
-
好处
- 防止内存溢出，程序运行失败
- 如果这些对象被再次被错误引用，会立即抛出NPE空指针异常，而不是悄悄地错误运行下去。
-
内存溢出常见来源
- 类自己管理内存就可能出现内存溢出
- 缓存导致的内存溢出，一旦对象放到缓存中，就很容易被遗忘，从而导致内存溢出，weakHashMap可以在特殊场合解决这类问题
- 程序的监听器和其他回调，如果在api中注册回调，去没有显示地取消注册，就会形成积聚，最后导致内存溢出
- heap分析工具，可以分析程序内存溢出的可能性
Tip-7 避免使用终结方法（finally）
try{
}finally{
}
// JVM会延迟执行终结方案，终结方法的线程优先级比应用程序的其他线程优先级要低的多
- 结论:不应该依赖终结方法来更新重要的持久状态。例如，依赖finally来释放共享资源（比如数据库）上的永久锁，很容易让整个分布式系统垮掉。
- System.gc和System.runFinalization增加了finally被执行的机会，但是不保证一定会被执行，唯一声称保证finally被执行的方法是System.runFinalizersOnExit以及Runtime.runFinalizersOnExit。但是这两个方法斗志致命的缺陷，已经被废弃。
- 使用finally有非常严重的性能损失
