摘要： 1. 传递性要求 equals约定的第三个要求是，如果 x eq y，y eq z，则 x eq z。 我们很容易在无意识的情况下违反这条约定。特别是 “值” 类组件的超类中，子类对超类 equals 行为的扩展导致 equals 函数的传递性问题。 public class Point { pri 阅读全文

摘要： 任何两个对象对于 “它们是否相等” 问题必须保持一致。与第一个要求不同，若无意中违反这一条，这种情形倒是不难想象。例如，下面的类，它实现了一个不区分大小写的字符串。字符串由 toString 保存，但在 equals 操作中被忽略。 /** * 覆写 Object 的 equals 方法时, 必须满 阅读全文

摘要： 1. 不需要覆盖 equals 方法的情况 覆盖 equals 方法看起来很简单，但是有许多覆盖方式会导致错误，并且后果非常严重。最容易避免这类问题的办法就是不覆盖 equals 方法，在这种情况下，类的每个实例都只与其自身相等。以下情况不需要覆盖 equals 方法： 类的每个实例本质上都是唯一的 阅读全文

摘要： 1. 使用 try-finally 关闭资源的缺点 Java 类库中包括许多必须通过调用 close 方法来手工关闭的资源。例如，InputStream、OutputStream 和 java.sql.Connection。客户端经常会忽略资源的关闭，造成严重的性能浪费。虽然这其中的许多资源都有终结 阅读全文

摘要： 在 Java 程序中，应尽量避免使用终结方法（finalizer），因为它通常是不可预测的，也是很危险的，一般情况下是不必要的。清除方法没有终结方法那么危险，但仍然是不可预测、运行缓慢、一般情况也是不必要的。注意清除方法需要实现AutoCloseable接口 1. 终结方法和清除方法的缺点 终结方法 阅读全文

摘要： 1. 消除因对象自己管理内存导致的内存泄漏 在支持垃圾回收的语言中，内存泄漏是非常隐蔽的（“无意识的对象保持”）。如果一个对象引用被无意识地保留起来了，那么垃圾回收机制不会处理这个对象，而且也不会处理被这个对象引用的所有其他对象。即使只有少量的几个对象引用被无意识地保留下来，也会有许许多多地对象被排 阅读全文

摘要： 一般来说，最好能重用单个对象，而不是在每次需要的时候就创建一个相同功能的新对象。 如果对象始终是不可变的，则它始终可以被重用。 1. 对于某些不可变对象 如 String 类型的变量 String s = new String("Hello"); // DON'T DO THIS 上面的语句每次执行 阅读全文

摘要： 有些类会依赖一个或多个底层资源。 虽然依赖注入极大地提升了灵活性和可测试性，但会导致大型项目凌乱不堪，因为这些项目通常包含上千个依赖。 最好使用一些依赖注入框架如Dagger、Guice、Spring 来解决该问题 阅读全文

摘要： 有时我们会编写一些只含静态方法的一些工具类，我们不希望使用这些类的人创建该类的实例对象。例如, java.lang.Math、java.util.Arryas。此时, 我们可以将该类的构造器私有化。 此外, 有时我们希望用户只能从工厂方法得到实例对象，也可以将该类的构造器私有化。 public cl 阅读全文

摘要： 1. 构造单例的第一种方法：公有域方法 优点： 直接获取静态变量，简单 缺点： 享有特权的客户端可以借助 AccessibleObject.setAccessible方法，通过反射机制调用私有构造器。如果需要抵御这种攻击，可以修改构造器，让它在被要求创建第二个实例的时候抛出异常 public cla 阅读全文