【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对常量池如何回收
- 字符串是否会导致内存泄漏
当然研究和测试只是为了验证论点,这不能成为不用这个技术的理由,以后的使用场景我还是会使用延迟消息的。