网站icp备案需要多久,做全景图二维码的网站,建设响应式网站,淘宝流量平台一、前言
《Effective Java》 这本书#xff0c;在刚从事 Java 开发的时候就被老师推荐阅读过#xff0c;当时囫囵吞枣的看了一部分#xff0c;不是特别的理解#xff0c;也就搁置了#xff0c;现在已经更新到第三版了#xff0c;简单翻阅了一下#xff0c;发现有些条例…
一、前言
《Effective Java》 这本书在刚从事 Java 开发的时候就被老师推荐阅读过当时囫囵吞枣的看了一部分不是特别的理解也就搁置了现在已经更新到第三版了简单翻阅了一下发现有些条例和现实开发中的场景呼应上了开始意识到确实应该好好的认真读一遍。应该会对自己有很大的帮助。通过这个专题记录我的一些心得体会。
二、创建和销毁对象 本章围绕以下三个问题展开 何时以及如何创建对象何时以及如何避免创建不必要的对象如何保证对象能够在合适的时间安全的销毁? 第一条用静态工厂方法代替构造器
构造器方式就是我们常用的 new 一个对象注意这里的静态工厂方法不同予设计模式中的静态工厂其实指的是类中提供一个返回当前实例的静态方法。参考 Boolean 包装类的源码
public static Boolean valueOf(boolean b) {return (b ? TRUE : FALSE);
}这么做既有优势也有劣势
优势
静态方法具有名称我们可以通过名称很清楚的知道我们想要返回的实例类型。 书中解释有点啰嗦无非就是通过具体方法名可以提高代码的自释性举得反例我都不是很认同通过构造函数重载本身就是一个被允许的操作如果容易混淆我们应该添加注释谨慎使用。 静态方法可以实现缓存避免每次创建新的对象。 这个比较好理解我们通过构造函数每次都要 new 一下就是创建新的对象如果通过静态方法那这个取对象的操作就被隔离开了不局限于新创建一个可以通过各种手动只要能返回预期的对象实例即可。 可以返回原返回类型的任何子类型的对象。 这样可以时返回类型更加灵活同时可以隐藏具体的实现类。 可以通过传入不同的参数返回不同对象实现类的实例。 其实就是对上一点的补充说明。 静态方法返回的对象所属的类在编写方法的时候可以不存在。 基于上一点通过不同的参数返回不同的类型的实例这个类型甚至可以是一个 **classz**静态方法内通过反射在调用的时候返回指定类型的实例对象这种方式可以极大的提供灵活性。 劣势
类如果不含有公有的或者受保护的构造器就不能被子类化。 这个也不能算是缺点吧构造器私有化本来就不允许被继承。 程序员很难发现一个类是不是有静态方法而忽略使用。 相比于构造方法本能的 new 一个对象我们潜意识会认为这是合理合规的但是不会第一反应去找一个类是不是提供了静态方法因为这不是强制要求的。 总结静态工厂方法和构造器各有用处但是静态工厂方法经常更加合适所以要纠正一下固有想法不要第一反应就是提供或者使用构造器而忽略了静态工厂。
第二条、遇到多个构造器参数时要考虑使用构建器
在平时开发的时候经常会碰到这样的场景当碰到一个大类字段很多的类在创建的时候如果通过构造器去创建我们需要传入一大串的参数 new User(name, age, ....)有些不是必须的也要设置默认值如果不想在创建的时候传入就需要创建一个特定参数列表的构造器最后就导致类构造器混乱失去控制使用起来也非常繁琐。其实就是书中提到的 **重叠构造器 **的方式。
但是往往我们的常规做法是通过无参构造器创建一个对象new User()然后通过 setter 方法来赋值这种方式更容易被接受也很清晰但是缺点就是每个字段都要去设置可能出现缺漏的情况。这其实就是书中说的 JavaBeans 模式这种方式还有两个严重不足
创建实例对象过程被分到了多个 setter 调用中, 这样在整个构造过程中 JavaBean 可能处于不一致的状态试图使用这种不一致状态的对象将会导致异常这种错误不容易排查。通过暴露 setter方法破坏了类的封装性使得想把类做成不可变的可能性不复存在。
推荐做法使用 构建器先看一下示例代码 Demo user Demo.builder().username(zhangsan).age(10).build();相信大家都看过类似的写法本质上是在 User 类中定义了一个静态 Builder 类通过重叠的方式提供设置每一个属性值的方法最后通过 build 完成对象的构建。
public static class DemoBuilder {private String username;private Integer age;DemoBuilder() {}public DemoBuilder username(final String username) {this.username username;return this;}public DemoBuilder age(final Integer age) {this.age age;return this;}public Demo build() {return new Demo(this.username, this.age);}public String toString() {return Demo.DemoBuilder(username this.username , age this.age );}}再结合之前的静态方法方式提供给外部一个 builder 方法, 类似下面示例
public static DemoBuilder builder() {return new DemoBuilder();
}这么做从一定程度上保证了对象的封装性也保留了类似于 JavaBeans 模式 的可读性。
但是有个不足的地方就是我们创建对象的时候必须先创建他的构建器这其实也是一部分开销而且就代码量上来说比重叠构造器模式更加冗长。好在现在基本都有现成的插件可以一键生成或者使用 lombok插件通过 Builder 注解自动为我们生成即可。
当有多个参数超过 4 个的时候使用构建器模式是个不错的选择。
第三条、用私有构造器或者枚举类型强化 Singleton 属性
这里首先理解一下 Singleton , 指本质上唯一的实例对象比如一些配置类。这里可以看一下设计模式里的单例模式。
通常实现有两种方式一种直接通过提供公共的静态成员方式通过 public final 定义一个 final 域我们知道 final修饰后即表示指定的为一个地址初始化后不可变。再将构造器私有化这样从某种程度上来说在初始化后可以保证全局唯一见示例代码
public class Demo {public static final Demo demo new Demo();private Demo () { ... }...
}但是通过反射可以破坏这种方式的唯一性。
第二种方式
public class Demo {private static final Demo demo new Demo();private Demo () { ... }public static Demo getInstance() { return demo; }...
}这种其实同第一种类似只是相比较第一种更加灵活也更容易被理解。
接下来看一下使用 **枚举 **方式
public enum Singleton {INSTANCE;// 可以在这里定义其他方法和字段public void someMethod() {// 方法的实现System.out.println(Executing some method.);}
}
线程安全枚举类型是线程安全的Java 会自动保证只会创建一个实例。防止反序列化枚举类型的反序列化会确保返回唯一的实例从而避免了多次创建实例的问题。简洁性实现简单易于理解符合 Java 的设计理念。
第四条、通过私有构造器强化不可变实例化的能力
书中提到像一些工具类我们不希望被实例化一般工具类中的方法都是静态方法通过类名直接调用即可但是有些错误使用案例因为默认会提供一个无参的构造器所以有人会无意识的 new 这个工具类对象然后通过对象去调用这其实是错误的。但是又无法避免书中还提到有些人会** 通过将类定义成抽象类来强制不可实例化**这种做法也是行不通的而且会误导用户以为故意设计成抽象类让用户去继承然后实例化子类最后反而适得其反。
通常做法提供一个私有的构造器并且抛出异常提醒调用者。为了避免使用者无法理解最好加上注释。
public class PasswordEncoderUtil {// 工具类不允许实例化private PasswordEncoderUtil() {throw new IllegalStateException(Utility class);}...
}第五条、优先考虑依赖注入来引用资源
这个得益于 Spring的生态发展大家基本上也都这干的。
第六条、避免创建不必要的对象
道理大家都知道但是问题是不知道有哪些地方可以避免。这里整理一下书里提到的。
对于一些不可变类一定一定不要通过 **new** 的方式创建 极端反例 String s new String(hahaha); , 构造器参数 “hahaha”本身就是一个 String 实例, 如果这个方法出现在循环里会频繁的创建出成千上万个 String实例正确做法应该是 String s hahaha;这样就只会创建一个实例。 有提供静态工厂方法使用静态工厂方法 这个比较好理解使用构造器必定会创建新的对象但是使用静态工厂方法则不一定。 对于创建成本很高的对象建议先缓存再重用。 书中例子使用 正则匹配的时候将 Pattern 对象通过 final 域缓存下来重用。 优先使用基本类型进行计算当心无意识的自动装箱行为导致对象的创建
作者指出这里并不是要告诉大家创建对象的代价非常大我们应该尽可能的去避免创建对象。适当的选择更为合适的做法小对象的创建和销毁对于虚拟机来说并没有太大压力一味的追求复用反而会使代码更加复杂。
第七条、消除过期的对象引用
我们都知道 Java的特点之一就是垃圾回收机制我们不需要过多的关注对象的回收通常开发中也是这样的。这里作者说清空对象引用应该是一种例外而不是一种规范行为。并给出了几个可能出现内存问题的场景。
自己管理内存的类要警惕内存泄漏的问题。使用本地缓存的场景下但是这取决于缓存项的生命周期是否有意义一些长期不用的缓存应该被定时清除掉。监听器和其他回调。
第八条、避免使用终结方法和清除方法
finalizer和 cleaner 通常不可预测比较危险一般情况下是不必要的。我写业务从来没用过。
第九条、try-with-resources 优先于 try-finally
这个现在基本上也是这么做的只有在一些很久以前的博客中还能看到通过在 finally 里面去关闭资源。
