文章目录
写在前面
最近的生活十分单调,基本上是早上一杯咖啡写写代码,下午睡一觉去健身房健个身,晚上再摸摸鱼(看视频、打游戏、看课外书),一天就过去了。几星期下来,可达鸭眉头一皱,发现事情并不简单
这样下去没成长呀!日复一日地写之前的东西,面向CV编程,整日的CURD,业务还是那类业务,技术栈还是老一套,除了提高IDEA快捷键的熟悉程度以及减少机械键盘的寿命,实在想不到还有什么进步了。噢!这不行。
哇,那么我也学学人家吧。把开发推一推,早上学基础知识。其他时间再做开发。嗯,就这么说定了。因此也就有了这第一篇搬运文章——不知不觉攒下了很多专栏、图文课以及专业书籍都没来得及看,现在开始一天一篇吧(▽)
该文章搬运自:解锁大厂思维:剖析《阿里巴巴Java开发手册》,链接地址:https://www.imooc.com/read/55。
其中前半部分是直接摘抄作者专栏,后半部分是个人总结+实践。在此写成文章权当学习笔记及知识分享。勤奋的搬运工一枚!
我要扼住命运的咽喉,它妄想使我屈服,这绝对办不到。生活是这样美好,活他一千辈子吧!——贝多芬
1. 前言
《手册》第 7 页有一段关于包装对象之间值的比较问题的规约 1:
【强制】所有整型包装类对象之间值的比较,全部使用 equals 方法比较。
说明:对于 Integer var = ? 在 - 128 至 127 范围内的赋值,Integer 对象是在 IntegerCache.cache 产 生,会复用已有对象,这个区间内的 Integer 值可以直接使用 == 进行判断,但是这个区间之外的所有数据,都会在堆上产生,并不会复用已有对象,这是一个大坑,推荐使用 equals 方法进行判断。
这条建议非常值得大家关注, 而且该问题在 Java 面试中十分常见。
我们还需要思考以下几个问题:
- 如果不看《手册》,我们如何知道
Integer var = ?
会缓存 -128 到 127 之间的赋值? - 为什么会缓存这个范围的赋值?
- 我们如何学习和分析类似的问题?
2. Integer缓存问题分析
我们先看下面的示例代码,并思考该段代码的输出结果:
public class IntTest {
public static void main(String[] args) {
Integer a = 100, b = 100, c = 150, d = 150;
System.out.println(a == b);
System.out.println(c == d);
}
}
通过运行代码可以得到答案,程序输出的结果分别为: true
, false
。
那么为什么答案是这样?
结合《手册》的描述很多人可能会颇有自信地回答:因为缓存了 -128 到 127 之间的数值,就没有然后了。
那么为什么会缓存这一段区间的数值?缓存的区间可以修改吗?其它的包装类型有没有类似缓存?
what? 咋还有这么多问题?这谁知道啊!
莫急,且看下面的分析。
2.1 源码分析
首先我们可以通过源码对该问题进行分析。
我们知道,Integer var = ?
形式声明变量,会通过 java.lang.Integer#valueOf(int)
来构造 Integer
对象。
我们先看该函数源码:
/**
* Returns an {@code Integer} instance representing the specified
* {@code int} value. If a new {@code Integer} instance is not
* required, this method should generally be used in preference to
* the constructor {@link #Integer(int)}, as this method is likely
* to yield significantly better space and time performance by
* caching frequently requested values.
*
* This method will always cache values in the range -128 to 127,
* inclusive, and may cache other values outside of this range.
*
* @param i an {@code int} value.
* @return an {@code Integer} instance representing {@code i}.
* @since 1.5
*/
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
通过源码可以看出,如果用 Ineger.valueOf(int)
来创建整数对象,参数大于等于整数缓存的最小值( IntegerCache.low
)并小于等于整数缓存的最大值( IntegerCache.high
), 会直接从缓存数组 (java.lang.Integer.IntegerCache#cache
) 中提取整数对象;否则会 new
一个整数对象。
那么这里的缓存最大和最小值分别是多少呢?
从上述注释中我们可以看出,最小值是 -128, 最大值是 127。
那么为什么会缓存这一段区间的整数对象呢?
通过注释我们可以得知:如果不要求必须新建一个整型对象,缓存最常用的值(提前构造缓存范围内的整型对象),会更省空间,速度也更快。
这给我们一个非常重要的启发:
如果想减少内存占用,提高程序运行的效率,可以将常用的对象提前缓存起来,需要时直接从缓存中提取。
那么我们再思考下一个问题: Integer
缓存的区间可以修改吗?
通过上述源码和注释我们还无法回答这个问题,接下来,我们继续看java.lang.Integer.IntegerCache
的源码:
/**
* Cache to support the object identity semantics of autoboxing for values between
* -128 and 127 (inclusive) as required by JLS.
*
* The cache is initialized on first usage. The size of the cache
* may be controlled by the {@code -XX:AutoBoxCacheMax=<size>} option.
* During VM initialization, java.lang.Integer.IntegerCache.high property
* may be set and saved in the private system properties in the
* sun.misc.VM class.
*/
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer cache[];
static {
// high value may be configured by property
int h = 127;
String integerCacheHighPropValue =
sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
// 省略其它代码
}
// 省略其它代码
}
因此可以通过修改这两个参数其中之一,让缓存的最大值大于等于 150。
如果作出这种修改,示例的输出结果便会是: true
,true
。
学到这里是不是发现,对此问题的理解和最初的想法有些不同呢?
这段注释也解答了为什么要缓存这个范围的数据:
是为了自动装箱时可以复用这些对象 ,这也是 JLS2 的要求。
我们可以参考 JLS 的 Boxing Conversion 部分的相关描述。
If the value
p
being boxed is an integer literal of typeint
between-128
and127
inclusive (§3.10.1), or the boolean literaltrue
orfalse
(§3.10.3), or a character literal between'\u0000'
and'\u007f'
inclusive (§3.10.4), then leta
andb
be the results of any two boxing conversions ofp
. It is always the case thata
==b
.在 -128 到 127 (含)之间的 int 类型的值,或者 boolean 类型的 true 或 false, 以及范围在’\u0000’和’\u007f’ (含)之间的 char 类型的数值 p, 自动包装成 a 和 b 两个对象时, 可以使用 a == b 判断 a 和 b 的值是否相等。
2.2 反汇编法
那么究竟 Integer var = ?
形式声明变量,是不是通过 java.lang.Integer#valueOf(int)
来构造 Integer
对象呢? 总不能都是猜测 N 个可能的函数,然后断点调试吧?
如果遇到其它类似的问题,没人告诉我底层调用了哪个方法,该怎么办? 囧…
这类问题有个杀手锏,可以通过对编译后的 class 文件进行反汇编来查看。
首先编译源代码:javac IntTest.java
然后需要对代码进行反汇编,执行:javap -c IntTest
如果想了解
javap
的用法,直接输入javap -help
查看用法提示(很多命令行工具都支持-help
或--help
给出用法提示)。
反编译后,我们得到以下代码:
Compiled from "IntTest.java"
public class com.chujianyun.common.int_test.IntTest {
public com.chujianyun.common.int_test.IntTest();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: bipush 100
2: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
5: astore_1
6: bipush 100
8: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
11: astore_2
12: sipush 150
15: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
18: astore_3
19: sipush 150
22: invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
25: astore 4
27: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
30: aload_1
31: aload_2
32: if_acmpne 39
35: iconst_1
36: goto 40
39: iconst_0
40: invokevirtual #4 // Method java/io/PrintStream.println:(Z)V
43: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
46: aload_3
47: aload 4
49: if_acmpne 56
52: iconst_1
53: goto 57
56: iconst_0
57: invokevirtual #4 // Method java/io/PrintStream.println:(Z)V
60: return
}
可以明确得 “看到” 这四个 ``Integer var = ? 形式声明的变量的确是通过
java.lang.Integer#valueOf(int) 来构造
Integer` 对象的。
至于对汇编后的代码详细分析请参阅网上资料。这里小白就先略过了。
3.Long 的缓存问题分析
我们学习的目的之一就是要学会举一反三。因此我们对 Long
也进行类似的研究,探究两者之间有何异同。
3.1 源码分析
类似的,我们接下来分析 java.lang.Long#valueOf(long)
的源码:
/**
* Returns a {@code Long} instance representing the specified
* {@code long} value.
* If a new {@code Long} instance is not required, this method
* should generally be used in preference to the constructor
* {@link #Long(long)}, as this method is likely to yield
* significantly better space and time performance by caching
* frequently requested values.
*
* Note that unlike the {@linkplain Integer#valueOf(int)
* corresponding method} in the {@code Integer} class, this method
* is <em>not</em> required to cache values within a particular
* range.
*
* @param l a long value.
* @return a {@code Long} instance representing {@code l}.
* @since 1.5
*/
public static Long valueOf(long l) {
final int offset = 128;
if (l >= -128 && l <= 127) { // will cache
return LongCache.cache[(int)l + offset];
}
return new Long(l);
}
发现该函数的写法和 Ineger.valueOf(int)
非常相似。
我们同样也看到, Long
也用到了缓存。 使用 java.lang.Long#valueOf(long)
构造 Long
对象时,值在 [-128, 127] 之间的 Long
对象直接从缓存对象数组中提取。
而且注释同样也提到了:缓存的目的是为了提高性能。
但是通过注释我们发现这么一段提示:
Note that unlike the {@linkplain Integer#valueOf(int) corresponding method} in the {@code Integer} class, this method is not required to cache values within a particular range.
注意:和
Ineger.valueOf(int)
不同的是,此方法并没有被要求缓存特定范围的值。
这也正是上面源码中缓存范围判断的注释为何用 // will cache
的原因(可以对比一下上面 Integer
的缓存的注释)。
因此我们可知,虽然此处采用了缓存,但应该不是 JLS 的要求。
那么 Long
类型的缓存是如何构造的呢?
我们查看缓存数组的构造:
private static class LongCache {
private LongCache(){}
static final Long cache[] = new Long[-(-128) + 127 + 1];
static {
for(int i = 0; i < cache.length; i++)
cache[i] = new Long(i - 128);
}
}
可以看到,它是在静态代码块中填充缓存数组的。
3.2 反编译
同样地我们也编写一个示例片段:
public class LongTest {
public static void main(String[] args) {
Long a = -128L, b = -128L, c = 150L, d = 150L;
System.out.println(a == b);
System.out.println(c == d);
}
}
编译源代码: javac LongTest.java
对编译后的类文件进行反汇编: javap -c LongTest
得到下面反编译的代码:
public class com.imooc.basic.learn_int.LongTest {
public com.imooc.basic.learn_int.LongTest();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: ldc2_w #2 // long -128l
3: invokestatic #4 // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
6: astore_1
7: ldc2_w #2 // long -128l
10: invokestatic #4 // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
13: astore_2
14: ldc2_w #5 // long 150l
17: invokestatic #4 // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
20: astore_3
21: ldc2_w #5 // long 150l
24: invokestatic #4 // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
27: astore 4
29: getstatic #7 // Field java/lang/System.out:Ljava/io/PrintStream;
32: aload_1
33: aload_2
34: if_acmpne 41
37: iconst_1
38: goto 42
41: iconst_0
42: invokevirtual #8 // Method java/io/PrintStream.println:(Z)V
45: getstatic #7 // Field java/lang/System.out:Ljava/io/PrintStream;
48: aload_3
49: aload 4
51: if_acmpne 58
54: iconst_1
55: goto 59
58: iconst_0
59: invokevirtual #8 // Method java/io/PrintStream.println:(Z)V
62: return
}
我们从上述代码中发现 Long var = ?
的确是通过 java.lang.Long#valueOf(long)
来构造对象的。
4. 总结
本文通过源码分析法、阅读 JLS 和 JVMS、使用反汇编法,对 Integer
和 Long
缓存的目的和实现方式问题进行了深入分析。
让大家能够通过更丰富的手段来学习知识和分析问题,通过对缓存目的的思考来学到更通用和本质的东西。
本文使用的几种手段将是我们未来常用的方法,也是工作进阶的必备技能和一个程序员专业程度的体现,希望大家未来能够多动手实践。
5. 个人感悟
- 整数缓存的范围是JLS 的要求,也体现了提高性能的常见思想:空间换时间。参考 java.lang.Integer.IntegerCache 的注释。 Java开发涉及自动拆箱和装箱,而比较常用的数字范围是 -128 到 127。 如果这段整数自动装箱不复用已经缓存的对象,会造成没必要的资源消耗,但是自动装箱所有整数范围的对象又没有必要。另外体现了对象池设计模式。
- 要养成直接去 JDK对应源码看注释的习惯,养成看Java语言规范和JVM规范的习惯。 网上百度到的质量参差不齐,甚至可能是错误的。
- Byte,Short,Long、Integer的缓存有固定范围: -128 到 127,对于 Character缓存范围是 0 到 127。除了 Integer 可以通过参数改变范围外,其它的都不行。
6. 个人实践
通过上述学习我们知道了——
- 装箱都是执行valueOf方法:如果有缓存将判定是否在缓存范围内,否则new。
- 拆箱则是执行xxxValue方法!<floatValue、longValue、intValue。。。>
6.1 Boolean的缓存问题分析
对于Boolean类型: 提供静态的2种枚举值,通过这种方式实现缓存?…
/**
* The {@code Boolean} object corresponding to the primitive
* value {@code true}.
*/
public static final Boolean TRUE = new Boolean(true);
/**
* The {@code Boolean} object corresponding to the primitive
* value {@code false}.
*/
public static final Boolean FALSE = new Boolean(false);
Boolean类型的valueOf
方法
public static Boolean valueOf(boolean b) {
return (b ? TRUE : FALSE);
}
同时还有另外一个方法重载的valueOf
方法
public static Boolean valueOf(String s) {
return parseBoolean(s) ? TRUE : FALSE;
}
parseBoolean(String s)
方法源码如下,能够将String类型的true
、false
字符串转换为boolean类型。
public static boolean parseBoolean(String s) {
return ((s != null) && s.equalsIgnoreCase("true"));
}
6.2 Character的缓存问题分析
CharacterCache 缓存 Character
private static class CharacterCache {
private CharacterCache(){}
static final Character cache[] = new Character[127 + 1];
static {
for (int i = 0; i < cache.length; i++)
cache[i] = new Character((char)i);
}
}
6.3 测试
public static void main(String[] args) {
Long a = 3L;
Integer b = 4;
Character c = 5;
Byte d = 7;
Short e = 1;
System.out.println(a == Long.valueOf(a));
System.out.println(b == Integer.valueOf(b));
System.out.println(c == Character.valueOf(c));
System.out.println(d == Byte.valueOf(d));
System.out.println(e == Short.valueOf(e));
}
运行的结果都为true!
在断点单测时发现:都跳入了valueOf方法!