Java 中int和Integer有什么区别

最新推荐文章于 2024-08-22 22:01:15 发布

weixin_34266504

最新推荐文章于 2024-08-22 22:01:15 发布

阅读量75

点赞数

文章标签： python java 运维

原文链接：https://my.oschina.net/u/3687664/blog/2876002

版权

2019独角兽企业重金招聘Python工程师标准>>>

面对上面的问题，你该怎么回答？

典型回答

int 是我们常说的整形数字，是 Java 的 8 个原始数据类型（Primitive Types，boolean、byte、short、char、int、float、double、long）之一。Java 语言虽然号称一切都是对象，但原始数据类型是例外。

Integer 是 int 对应的包装类，它有一个 int 类型的字段存储数据，并且提供了基本操作，比如数学运算、int 和字符串之间转换等。在 Java 5 中，引入了自动装箱和自动拆箱功能（boxing/unboxing），Java 可以根据上下文，自动进行转换，极大地简化了相关编程。

关于 Integer 的值缓存，这涉及 Java 5 中另一个改进。构建 Integer 对象的传统方式是直接调用构造器，直接 new 一个对象。但是根据实践，我们发现大部分数据操作都是集中在有限的、较小的数值范围，因而，在 Java 5 中新增了静态工厂方法 valueOf，在调用它的时候会利用一个缓存机制，带来了明显的性能改进。按照 Javadoc，这个值默认缓存是 -128 到 127 之间。

这个问题涵盖了 Java 里的两个基础要素：原始数据类型、包装类。谈到这里，就可以非常自然地扩展到自动装箱、自动拆箱机制，进而考察封装类的一些设计和实践。坦白说，理解基本原理和用法已经足够日常工作需求了，但是要落实到具体场景，还是有很多问题需要仔细思考才能确定。

我们可以结合其他方面，来考察面试者的知识掌握程度和思考逻辑，比如：

自动装箱 / 自动拆箱是发生在什么阶段？编译阶段、运行时？
使用静态工厂方法 valueOf 会使用到缓存机制，那么自动装箱的时候，缓存机制起作用吗？
为什么我们需要原始数据类型，Java 的对象似乎也很高效，应用中具体会产生哪些差异？
阅读过 Integer 源码吗？分析下类或某些方法的设计要点。

似乎有太多内容可以探讨，我们一起来分析一下。

知识扩展

1. 理解自动装箱、拆箱自动装箱实际上算是一种语法糖。

什么是语法糖？可以简单理解为 Java 平台为我们自动进行了一些转换，保证不同的写法在运行时等价，它们发生在编译阶段，也就是生成的字节码是一致的。
像前面提到的整数，javac 替我们自动把装箱转换为 Integer.valueOf()，把拆箱替换为Integer.intValue()，这似乎这也顺道回答了另一个问题，既然调用的是 Integer.valueOf，自然能够得到缓存的好处啊。

如何程序化的验证上面的结论呢？

你可以写一段简单的程序包含下面两句代码，然后反编译一下。当然，这是一种从表现倒推的方法，大多数情况下，我们还是直接参考规范文档会更加可靠，毕竟软件承诺的是遵循规范，而不是保持当前行为。

Integer integer = 1;
int unboxing = integer ++;

反编译输出：

1: invokestatic #2 // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
8: invokevirtual #3 // Method
java/lang/Integer.intValue:()I

这种缓存机制并不是只有 Integer 才有，同样存在于其他的一些包装类，比如：

Boolean，缓存了 true/false 对应实例，确切说，只会返回两个常量实例Boolean.TRUE/FALSE。
Short，同样是缓存了 -128 到 127 之间的数值。
Byte，数值有限，所以全部都被缓存（-128 到 127 ）。
Character，缓存范围 '\u0000' 到 '\u007F'。
Long只缓存了 -128 到 127 之间的数值。

自动装箱 / 自动拆箱似乎很酷，在编程实践中，有什么需要注意的吗？

原则上，建议避免无意中的装箱、拆箱行为，尤其是在性能敏感的场合，创建 10 万个 Java 对象和 10 万个整数的开销可不是一个数量级的，不管是内存使用还是处理速度，光是对象头的空间占用就已经是数量级的差距了。

我们其实可以把这个观点扩展开，使用原始数据类型、数组甚至本地代码实现等，在性能极度敏感的场景往往具有比较大的优势，用其替换掉包装类、动态数组（如 ArrayList）等可以作为性能优化的备选项。一些追求极致性能的产品或者类库，会极力避免创建过多对象。当然，在大多数产品代码里，并没有必要这么做，还是以开发效率优先。以我们经常会使用到的计数器实现为例，下面是一个常见的线程安全计数器实现。

class Counter {
	private final AtomicLong counter = new AtomicLong();
		
	public void increase() {
		counter.incrementAndGet();
	}
}

如果利用原始数据类型，可以将其修改为

class CompactCounter {
	private volatile long counter;
	
	private static final AtomicLongFieldUpdater<CompactCounter> updater = AtomicLongFieldUpdater.newUpdater(CompactCounter.class,"counter");
	
	public void increase() {
		updater.incrementAndGet(this);
	}
}

2. 源码分析

考察是否阅读过、是否理解 JDK 源代码可能是部分面试官的关注点，这并不完全是一种苛刻要求，阅读并实践高质量代码也是程序员成长的必经之路，下面我来分析下 Integer 的源码。整体看一下 Integer 的职责，它主要包括各种基础的常量，比如最大值、最小值、位数等；前面提到的各种静态工厂方法 valueOf()；获取环境变量数值的方法；各种转换方法，比如转换为不同进制的字符串，如 8 进制，或者反过来的解析方法等。我们进一步来看一些有意思的地方。首先，继续深挖缓存，Integer 的缓存范围虽然默认是 -128 到 127，但是在特别的应用场景，比如我们明确知道应用会频繁使用更大的数值，这时候应该怎么办呢？

缓存上限值实际是可以根据需要调整的，JVM 提供了参数设置：

- XX:AutoBoxCacheMax=N

这些实现，都体现在java.lang.Integer源码之中，并实现在 IntegerCache 的静态初始化块里。

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");
            if (integerCacheHighPropValue != null) {
                try {
                    int i = parseInt(integerCacheHighPropValue);
                    i = Math.max(i, 127);
                    // Maximum array size is Integer.MAX_VALUE
                    h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
                } catch( NumberFormatException nfe) {
                    // If the property cannot be parsed into an int, ignore it.
                }
            }
            high = h;

            cache = new Integer[(high - low) + 1];
            int j = low;
            for(int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);

            // range [-128, 127] must be interned (JLS7 5.1.7)
            assert IntegerCache.high >= 127;
        }

        private IntegerCache() {}
    }
    ....
}

第二，我们在分析字符串的设计实现时，提到过字符串是不可变的，保证了基本的信息安全和并发编程中的线程安全。如果你去看包装类里存储数值的成员变量“value”，你会发现，不管是Integer 还是Boolean 等其他基本类型封装类，其value都被声明为“private final”，所以，它们同样是不可变类型！

3. 原始类型线程安全

前面提到了线程安全设计，你有没有想过，原始数据类型操作是不是线程安全的呢？

这里可能存在着不同层面的问题：

原始数据类型的变量，显然要使用并发相关手段，才能保证线程安全，这些我会在专栏后面的并发主题详细介绍。如果有线程安全的计算需要，建议考虑使用类似 AtomicInteger、AtomicLong 这样的线程安全类。
特别的是，部分64位的数据类型，long、double，甚至不能保证写操作的原子性，可能出现程序读取到只更新了一半数据位的数值！

“深入java虚拟机”中提到，int等不大于32位的基本类型的操作都是原子操作，但是某些jvm对long和double类型的操作并不是原子操作，这样就会造成错误数据的出现。

错误数据出现的原因是：
在32位的虚拟机中，对于long和double变量，把它们作为2个原子性的32位值来对待，而不是一个原子性的64位值，
这样将一个long型的值保存到内存的时候，可能是2次32位的写操作，
2个竞争线程想写不同的值到内存的时候，可能导致内存中的值是不正确的结果。

1、写入高位32位值(线程2)
2、写入高位32位值(线程1)
3、写入低位32位值(线程1)
4、写入低位32位值(线程2)

这样内存中的值变成线程1的高32位值和线程2的低32位值的组合，是个错误的值。
书中还提到，上面出现问题的long和double变量是没有声明为volatile的变量。
volatile本身不保证获取和设置操作的原子性，仅仅保持修改的可见性。

但是java内存模型保证声明为volatile的long和double变量的get和set操作是原子的。

jvm spec引用中的最后一段说到，jvm可以很轻易的将变量操作变成原子性的，但是却受到了当前硬件的约束，因为流行的微处理器还是32bit居多，因此64bit的变量需要拆分成两次，但如果是64bit处理器就能满足64bit变量的原子性操作了。

针对这个问题，找到了网上的一个总结：

对于64位的long和double，如果没有被volatile修饰，那么对其操作可以不是原子的。在操作的时候，可以分成两步，每次对32位操作；
如果使用volatile修饰long和double，那么其读写都是原子操作；
在实现JVM时，可以自由选择是否把读写long和double作为原子操作；
java中对于long和double类型的写操作不是原子操作，而是分成了两个32位的写操作。读操作是否也分成了两个32位的读呢？在JSR-133之前的规范中，读也是分成了两个32位的读，但是从JSR-133规范开始，即JDK5开始，读操作也都具有原子性；
java中对于其他类型的读写操作都是原子操作(除long和double类型以外)；
对于引用类型的读写操作都是原子操作，无论引用类型的实际类型是32位的值还是64位的值；
对于long类型的不恰当操作可能读取到从未出现过的值。而对于int的不恰当操作则可能读取到旧的值；

转载于:https://my.oschina.net/u/3687664/blog/2876002