【jdk源码2】Objects源码学习

　　在学习上一个类TreeMap的时候，提到了这个类，这个类是jdk1.7新增的，里面有很多实用的方法。就是一个工具类，熟悉以后，如果里面有已经实现的方法，那么就不要再去实现了，省时省力省测试。

一、简单理解

　　这是一个工具类，介绍相对会简单些，基本都是方法的介绍。

1.1 类名的命名

　　Objects是一个主要针对对象的工具类，所以它的命名只是在后面加上一个s，就像Arrays是操作数组的工具类一样。这就涉及到一种设计理念，那就是工具方法应该放在哪：

• 放在使用的类里
• 按操作属性进行归类，如StringUtils，FileUtils，MapUtils等等
• 全部放到一个类里，Utils

　　第一种不太建议，既然都是一个工具类，那么就应该拿出来给别人用，或者自己以后用。

　　第二种和第三种我比较不出来，我用的是第三种，建立一个大而全的Utils类，当然它们之间还是可以比较的：

• 多个工具类：使用的时候需要想在哪个里面，优点就是可以按照方法所操作进行分组，但是有时候有的工具类就是不知道怎么分组
• 一个工具类：一个缺点就是方法命名一定要好，毕竟方法多了不好找，优点就是工具类好找，而且方法可以重载，比如判断是否为空，就可以重载Map、Collection、String等。

1.2 工具类的特性

　　先看下面一部分代码：

public final class Objects {
    private Objects() {
        throw new AssertionError("No java.util.Objects instances for you!");
    }
}

　　因为是工具类加上final不让别人继承，还有就是构造方法加上私有并抛异常。

　　说实话我觉得没有必要这么做，或许他们考虑的比较多，但是这么做也没什么坏处，以后我写工具类也这样，显得高大上一些。

1.3 对象equals比较

　　Objects里面提供两种比较方式：

public static boolean equals(Object a, Object b) {
    return (a == b) || (a != null && a.equals(b));
}
public static boolean deepEquals(Object a, Object b) {
    if (a == b)
        return true;
    else if (a == null || b == null)
        return false;
    else
        return Arrays.deepEquals0(a, b);
}

　　其中我们普遍使用的就是equals，然后我看deepEquals的源码的时候，发现了一个之前忽略的事然后我做了测试：

int[] a1=new int[]{1};
int[] a2=new int[]{1};
System.out.println(a1.equals(a2));

　　结果是false，也就是说因为数组（以数字为下标，不代表里面的内容是数字）的equals都是false，除非它们是同一个对象。也就是说我们以后如果要做两个对象的相等判断，如果比较的是两个数组那么记得使用Objects的deepEquals方法。

1.4 对null值的简单包装

　　大家都知道在null值对象上调用任何方法都会报空指针异常，在一些需要判断对象是否是null的情况下，抛异常是有必要的，但是当可以允许null值的时候，很多Object常用的方法就需要额外的处理，而Objects就帮我们做了：

public static String toString(Object o) {
    return String.valueOf(o);
}
public static int hash(Object... values) {
    return Arrays.hashCode(values);
}
public static String toString(Object o, String nullDefault) {
    return (o != null) ? o.toString() : nullDefault;
}

　　所以使用起来很方便，但是一定要注意使用场景，保证null值是有效值的时候使用。

1.5 null值检查需要自己做吗

　　很多时候，我们需要保证入参的正确性，最简单的就是传入的不能是null，如果说上层需要将错误原因展示给用户看，我们就需要主动检查是否为null，并且主动返回null值所代表的信息（比如说用户名不能为空啦，邮箱不能为空啦），而不是抛异常。

　　但是当不需要给用户看的时候，那就可以直接将异常抛出来就可以了，这就有两种策略：

• 主动检查是否为null，并抛异常
• 被动检查，等待程序调用null上面的方法时抛异常

　　现在大多数人都很少主动去检查null值，我觉得这是不好的编程习惯，我认为应该在方法入口的时候主动检查null值并抛异常，原因如下：

• 早点抛异常，在查看堆栈信息的时候，能更快速的定位异常原因
• 早点抛异常还能够，不再执行额外的代码，避免执行大部分代码以后才抛出异常

　　所以建议以后写代码的时候多多主动检查，使用

public static <T> T requireNonNull(T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}
public static <T> T requireNonNull(T obj, String message) {
    if (obj == null)
        throw new NullPointerException(message);
    return obj;
}

　　上面说的好处你会慢慢体会到的。

1.6 延迟消息的好处

　　现在先看下面两个方法，同样是判断null值的：

public static <T> T requireNonNull(T obj, String message) {
    if (obj == null)
        throw new NullPointerException(message);
    return obj;
}
public static <T> T requireNonNull(T obj, Supplier<String> messageSupplier) {
    if (obj == null)
        throw new NullPointerException(messageSupplier.get());
    return obj;
}

　　传入的message是在当参数是null值的时候传入给异常使用的，但是为什么会有两个方法呢，而且第二个看起来远远比第一个麻烦，我们先看怎么使用：

public void test1(String param){
  Objects.requireNonNull(param, "param can not be null");
  //do something about param
}

　　上面是方法一调用的方式，很简洁明了，下面是方法二的调用方式：

public void test2(String param){
  Objects.requireNonNull(param, new Supplier<String>() {
    @Override
    public String get() {
      return "param can not be null";
    }
  });
  //do something about param
}
public void test3(String param){
  Objects.requireNonNull(param, ()->"param can not be null");
  //do something about param
}

　　有两种方式，第二种是jdk8的lambada表达式，如果不了解的话，希望抽时间学习一下还是有必要的。

　　可以看到延迟消息的调用要比普通消息复杂，但是为什么还要推荐这种方式呢？再举一个例子，以前我看过如下记录日志的方式：

if(log.isDebugEnabled()){
  log.debug("read file sucess, read info is :"+properties);
}

　　当时我对这种代码嗤之以鼻，我觉得明明log.debug在里面已经判断日志级别了，为什么在外面还要在判断一次，现在想想当时还是太年轻。如果你仔细想想或许能发现，如果我们提前判断日志级别那么，当不符合日志级别的时候我们就不需要拼接字符串，而如果我们直接用：

log.debug("read file sucess, read info is :"+properties);

　　用上面代码的话，我们就需要每次都要拼接完字符串后再进行判断，而debug日志基本上量都特别大，而且基本不会打印，这也就造成了字符串拼接过多，而字符串会放到常量池里。

　　所以简单总结下延迟消息的好处，那就是在需要的时候才进行拼接，这个在log4j2中已经提供相应的支持，但是这个好处到底有多少，我现在还不清楚。

二、问题及总结

　　这个类是一个工具类，很多方法用起来都很方便，如果用的好的话，应该能解决程序中出现的大部分NullPointerException，所以呢以后对常用的方法要做到封装复用。

2.1 遗留问题

　　大致看来遗留一个未深入研究的问题

2.1.1 延迟消息能高效在哪

　　上面1.6讲解了延迟消息，我只知道延迟消息有好处，虽然jdk注释中也明说了：

the costs of creating the message supplier are less than the cost of just creating the string message directly

　　创建延迟消息要比直接创建字符串高效，但是能高效多少呢，这是一个疑问，当然这也牵扯到jvm对字符串的处理。我会抽时间做如下深入测试和研究：

• jvm中的常量池
• jvm对常量池如何回收
• 字符串是否会导致内存泄漏

　　当然研究和测试只是为了验证论点，这不能成为不用这个技术的理由，以后的使用场景我还是会使用延迟消息的。