Fork me on GitHub

【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对常量池如何回收
  • 字符串是否会导致内存泄漏

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

posted @ 2017-07-14 15:55  已往之不谏  阅读(658)  评论(0编辑  收藏  举报