一个BUG的思考：Java中使用final修饰变量真的不能修改它的“值”吗？

本文主要是介绍一个BUG的思考：Java中使用final修饰变量真的不能修改它的“值”吗？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言
在Java中，当我们希望告知编译器某个变量在初始化之后它的值不再需要改变时，我们常用final修饰该变量。而什么情况下我们会有这种需求呢？例如，当我们在B线程使用到在A线程定义的变量时，我们就必须要使用final来修饰该变量，原理是在并发情况下禁止CPU的指令重排，防止对象引用被其他线程在对象被完全构造完成前拿来使用。所以在Java中，final用来修饰变量时，我们常常人为该变量的值是不能被修改的。那么真的是这样吗？下面以一个开发中遇到的case作为一个思考切入点来对该问题进行分析。
case
先来看下面一段代码，就是使用摄像头进行预览画面，在每一帧被渲染出来的时候就会走onPreviewFrame这个回调，bytes数组里面保存了这一帧画面的信息，我们可以截取进行人脸检测、截屏等，都是可以的。但是为了避免垃圾回收器重复回收，这里定义了同步的byte数组的缓存池，每次从缓存池里面拿一个byte数组，回调结束的时候又把它返回到缓存池里面，保证重复使用到的都是同一个byte数组，减少内存的消耗。
mCamera.startPreview();
mCamera.setPreviewCallbackWithBuffer(new Camera.PreviewCallback() {

Pools.SynchronizedPool<byte[]> mByteArrayPool = new Pools.SynchronizedPool<byte[]>(1) {
      private final byte[][] mPool = new byte[1][mPreviewSize.getWidth() * mPreviewSize.getHeight() * 3 / 2];
      private int mPoolSize = mPool.length;

      @Override
      public byte[] acquire() {
         if (mPoolSize > 0) {
            final int lastPooledIndex = mPoolSize - 1;
            byte[] instance = mPool[lastPooledIndex];
            mPool[lastPooledIndex] = null;
            mPoolSize--;
            return instance;
         }
         return new byte[mPreviewSize.getWidth() * mPreviewSize.getHeight() * 3 / 2];
      }

      @Override
      public boolean release(@NonNull byte[] element) {
         if (mPoolSize < mPool.length) {
            mPool[mPoolSize] = element;
            mPoolSize++;
            return true;
         }
         return false;
      }
};

@Override
public void onPreviewFrame(byte[] bytes, Camera camera) {
      final byte[] dst = mByteArrayPool.acquire();

      // 截屏（另外一个线程操作）
      sreenShot(dst);

      if (dst != null) {
         mByteArrayPool.release(dst);
      }

      camera.addCallbackBuffer(bytes);
}
});
mCamera.addCallbackBuffer(new byte[mPreviewSize.getWidth() * mPreviewSize.getHeight() * 3 / 2]);
mCamera.addCallbackBuffer(new byte[mPreviewSize.getWidth() * mPreviewSize.getHeight() * 3 / 2]);
复制代码细心的朋友可以看到，这里的dst是定义成final类型的，按道理来说它的值应该是不会被改变的，但是，最近测试在给我反馈下面图片这个问题的时候，对代码思前想后之后我确认了这个BUG发生的原因，就是因为上面的final数组值的变化引起了截图内容的错误。

在上面的代码中可以看到，在使用dst进行截屏（byte数组转换成RGB）时，这个dst也被回收到缓存池里面，当还没有截屏完成时，下一帧已经被存到dst数组里面，最后导致截屏的时候使用的数组既包含了上一帧的画面，也包含了下一帧的画面。由此可见这个dst数组即便是被定义成final类型，但是它的“值”还是会被改变的。
那么到底为什么会是这样的呢？通过翻阅《Java编程思想》，里面是这么描述的：

对于基本类型，final使数值恒定不变；而对于对象引用，final使引用恒定不变。一旦引用被初始化指向一个对象，就无法再把它改为指向另一个对象。然而，对象其自身确实可以被修改的，Java并未提供使任何对象恒定不变的途径。这一限制同样适用数组，它也是对象。

总结
由此在Java中，对于基本类型的变量使用final修饰，它的值是恒定不变的；而对于对象（包括数组）引用的变量使用final来修饰，它引用的对象是恒定不变的，而对象的值是可以变的。
这个知识点可能不会很多人知道，但是了解之后对于我们日常开发遇到极端的Bug时可以少走弯路，减少很多Bug Fix的时间。

作者：特雷西多士
链接：https://juejin.im/post/5d831d7d6fb9a06ade1148b0
来源：掘金