包装类这颗语法糖，其实并不甜
往期热门文章：
1、换掉UUID，NanoID更快更安全！ 2、新来的后端整的接口文档看着真不优雅！ 3、如何优雅的写 Controller 层代码？ 4、SpringBoot+Nacos+Kafka简单实现微服务流编排 5、几行代码，搞定 SpringBoot 接口恶意刷新和暴力请求！
Java 5中和泛型一起引入，引入包装类的原因有两点：
解决无法创建基本类型泛型集合的问题 加入对基本类型为 null这个语义的支持
boxing和unboxing的语法糖，让编译器支持基本类型和包装类的自动转化，减少开发者的工作量。但是经常有同学因为误用包装类导致惨烈的线上问题，在使用包装类的时候务必需要注意以下四点：
与基础类截然不同的 ==和equals语义糟糕的性能 不易察觉的 NPE问题令人疑惑的 API设计
1. 相等还是不相等？这是个问题
class Biziclop {
public static void main(String[] args) {
System.out.println(new Integer(5) == new Integer(5)); // false
System.out.println(new Integer(500) == new Integer(500)); // false
System.out.println(Integer.valueOf(5) == Integer.valueOf(5)); // true
System.out.println(Integer.valueOf(500) == Integer.valueOf(500)); // false
}
}
false是比较容易理解的，因为对于Java中的对象调用=其实是在比较对象在堆上的地址，由于两个对象都是新建的，所以地址肯定不等，返回false。比较令人疑惑的是第三个语句，按照我们前面的分析，应该也返回false才对，但其实Integer.valueOf(5) == Integer.valueOf(5)比较的结果是true，这是因为JVM缓存了-128-127的整数，所以当数值在这个区间的时候，返回的对象都是同一个的。第四个语句因为数值已经不在-128-127的区间范围，所以返回了false。class Biziclop {
public static void main(String[] args) {
List<Long> list = new ArrayList<>();
list.add(Long.valueOf(200));
System.out.println(list.contains(200)); // false
Long temp = 0L;
System.out.println(temp.equals(0)); // false
System.out.orintln(0==0L); // true
}
}
public boolean equals(Object obj) {
if (obj instanceof Long) {
return value == ((Long)obj).longValue();
}
return false;
}
equals方法，导致包装类即便是调用equals方法比较大小，也会和基本类型出现不一致的结果。与基础类截然不同的==和equals语义经常会导致代码走到非期望的分支，再配上JVM对数字独特的缓存策略，极容易出现测试环境和正式环境不一样的运行结果。2. 糟糕的性能
Effective Java》中有如下的例子：public static void main(String[] args) {
Long sum = 0L; // uses Long, not long
for (long i = 0; i <= Integer.MAX_VALUE; i++) {
sum += i;
}
System.out.println(sum);
}
long的版本慢6倍（声明变量sum 类型为 Long 的耗时是43秒， 如果声明变量sum为基本类型long，则耗时6.8秒）。导致这样的原因是包装类要经过在堆上开辟内存空间，初始化，内存寻址以及数据载入寄存器的过程，性能差也就不足为奇了。因此Joshua Bloch对开发者的建议是：Avoid creating unnecessary objects.JMH workbench上跑的包装类和基础类性能对比如下图所示：
图片地址：https://www.baeldung.com/java-primitives-vs-objects
3. 不易察觉的NPE
null的，这就意味着一个指向null的包装类unboxing的时候会抛出NPE异常，比如以下代码：Integer in = null;
...
...
int i = in; // NPE at runtime
NPEclass Biziclop {
public static void main(String[] args) {
Boolean b = true ? returnsNull() : false; // NPE on this line.
System.out.println(b);
}
public static Boolean returnsNull() {
return null;
}
}
如果三元运算符的第二个或者第三个参数是基本类型T，并且另一个是相应的包装类型的话，那么三元运算符的返回类型就是这个基本类型T
unboxing，因此抛出了NPE.4. 令人疑惑的API
Long这个类中，有一个api是getLong，其声明如下：
/**
* Determines the {@code long} value of the system property
* with the specified name.
*/
public static Long getLong(String nm) {
return getLong(nm, null);
}
api的作用是获取JVM中的属性值的，并且转换为Long 类型，比如：class Biziclop {
public static void main(String[] args) {
System.setProperty("22", "22");
System.setProperty("23", "hello world!");
System.out.println(Long.getLong("22")); // 22
System.out.println(Long.getLong("23")); // null
System.out.println(Long.getLong("24")); // null
}
}
api的设计妥妥是一个反例，经常有同学误用，把它当成Long.valueOf或者是Long.parseLong，结果返回不符合期望的值。5. 最佳实践
Java编程手册》对包装类的使用有以下三条建议：所有 POJO类属性使用包装类RPC方法的返回值和参数使用包装类 所有的局部变量使用基本数据类型
说明： POJO类属性没有初值是提醒使用在需要使用时，必须自己显式的进行赋值，任何NPE问题，或者入库检查，都有使用者来保证。
null,因为自动拆箱，用基本数据类型接受有NPE的风险HSF服务，调用不成功时，返回的是默认值，页面展示0%，这是不合理的，应该展示成中划线-，所以包装类的null值，能够表示额外的信息，如：远程调用失败，异常退出。往期热门文章：
1、MySQL 暴跌！ 2、超越 Xshell！号称下一代 Terminal 终端神器，用完爱不释手！ 3、IDEA 官宣全新默认 UI，太震撼了！！ 4、让你直呼「卧槽」的 GitHub 项目！ 5、Kafka又笨又重，为啥不选Redis？ 6、50多个高频免费 API 接口分享 7、IDEA公司再发新神器！超越 VS Code 骚操作! 8、我怀疑这是 IDEA 的 BUG，但是我翻遍全网没找到证据！ 9、Spring MVC 中的 Controller 是线程安全的吗？ 10、Gitee 倒下了？？？
评论