假设并发环境下，业务代码中存在一些统计操作，为了保证线程安全，开发人员往往会对计数值进行加锁（synchronized），值得注意的是，直接对Integer类型进行加锁，似乎并不会达到预期效果，比如下面这段代码：
| Integer num = new Integer(0); public void test() throws InterruptedException { final int THREAD_SIZE = 10; final int TASK_SIZE = 100000; final CountDownLatch latch = new CountDownLatch(THREAD_SIZE); for (int i = 0; i < THREAD_SIZE; i++) { new Thread() { public void run() { for (int j = 0; j < TASK_SIZE / THREAD_SIZE; j++) { synchronized (num) { num++; } } latch.countDown(); } }.start(); } latch.await(); System.out.println("num-->" + num); } |
上述代码示例中，总共有10个线程运行，每个线程执行次数为10000(taskSize/threadSize)，但是实际程序输出结果却并非是10W次，或许有些同学会觉得诧异，在对计数值num（Integer）进行递增操作前，已经执行了加锁操作，为啥还是非线程安全。我们首先来看一下上述程序的线程堆栈信息：
上图中，每一个线程锁住的资源其实都并非是同一个，这就可以解释为什么对Integer类型进行加锁仍然是非线程安全的。
或许有同学会说，JavaAPI提供有线程安全的AtomicInteger为啥不用，尽管AtomicInteger是线程安全的，但是接下来我们还是要聊一聊为啥锁不住Integer等原始数据类型的封装类型。
JAVA5为原始数据类型提供了自动装/拆箱功能，假设对Integer进行递增/递减操作后，其实HashCode已经发生了变化，synchronized自然也不是同一个对象实例，Integer的源码，如下所示：
从源码中可以看出，当为Integer赋值数值在-128~127区间时，会从Integer中的一个Integer[]中获取一个缓存的Integer对象，而超出区间值得时候，每次都会new一个新的Integer对象，假设下述这段代码：
| Integer num = new Integer(300); System.out.println("identityHashCode-->" + System.identityHashCode(num)); System.out.println("hashCode-->" + num.hashCode()); num = 300; System.out.println("identityHashCode-->" + System.identityHashCode(num)); System.out.println("hashCode-->" + num.hashCode()); |
实际程序输出为：
| identityHashCode-->627248822 hashCode-->300 identityHashCode-->523481450 hashCode-->300 |
内存改变了！即Integer类型超出[-128~127]区间时值的变动都会带来内存的变动
Synchronized锁的是对象，也就是identityHashCode所指向的内存地址中的对象实例（根据对象内存地址生成散列值），而hashcode输出的是值得散列值。所以为啥上述程序示例中，identityHashCode每次不同，而hashCode输出的值却相同。
最后总结下，synchronized(Integer)时，当值发生改变时，基本上每次锁住的都是不同的对象实例，想要保证线程安全，推荐使用AtomicInteger之类会更靠谱。
