记录一个因变量遮蔽引起的“友尽”级bug

之前在翻译学习EOPL过程中回顾以前的代码时发现一个让人后背发凉的隐患，一种极其罕见、但是一旦出现就难以发现并可能造成非常大影响的bug，本文就记录下这个问题。

问题场景

下面来看一段常见的示例程序：

public class DemoActivity extends Activity {public static final String TAG = DemoActivity.class.getSimpleName();@Overrideprotected void onCreate(@Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);findViewById(R.id.btn_test).setOnClickListener(new BaseClickListener() {@Overrideprotected void onClicked(View v) {Log.i(TAG, "onClicked: clicked");}});}
}

这是一个防止快速点击的示例，这个程序中类DemoActivity包含了一个BaseClickListener的匿名内部类，然后这个类中引用了外部类的声明的变量TAG（好像是这样）。但事实上，BaseClickListener的实现是这样的：

public abstract class BaseClickListener implements View.OnClickListener {public static final String TAG = BaseClickListener.class.getSimpleName();private long lastClickTime = 0L;@Overridepublic final void onClick(View v) {long currentTime = System.currentTimeMillis();if (currentTime - lastClickTime >= 500) {onClicked(v);} else {Log.d(TAG, "onClick: click to fast");}lastClickTime = currentTime;}protected abstract void onClicked(View v);
}

因此在DemoActivity中匿名内部类引用的其实是BaseClickListener类中声明的TAG。这里发生了变量遮蔽的现象，而且还是一种不可见的、“隐式”的遮蔽。这种遮蔽的存在使得外部文件的修改可以直接影响当前文件的语义。

试想，这两个类属于不同的模块，甚至不同的项目，使用BaseClickListener的人甚至有可能不会去看源码、甚至拿不到源码，而编写BaseClickListener的人更不会考虑DemoActivity的实现。一开始BaseClickListener类中可能没有TAG变量，DemoActivity中对TAG的引用指向DemoActivity.TAG，后来BaseClickListener引入了这个变量，这时候，不管是DemoActivity的开发者还是BaseClickListener的开发者都不知道这里出了问题，而DemoActivity的程序语义已经发生了改变。

上述示例程序中问题范围仅仅是打印日志，所以影响范围有限。但如果换成其他的变量，比如常见的id、rootView、name、content、currentTime、count等等等等，那么运气好的情况下直接编译不过，运气不好的情况程序崩溃甚至数据污染，而且这个问题需要通过跟踪变量引用才能发现，光肉眼看还可能看不出来。

我还没有在实际项目中遇到过这个问题，但如果真的遇到了，那我可能要跟我的同事“友尽”了，因此将其列为“友尽”级bug。

问题分析

上面问题产生原因如下：

这是“隐式”发生的遮蔽，还是无意识的遮蔽，且遮蔽跨越多文件；
变量/常量/方法声明定义与使用跨多文件，且引用采用简化形式，并非完全形式；

首先简要谈谈遮蔽（shadow）。（之所以简要，是因为这个概念结合作用域、上下文来讲比较容易讲透，这个另外在写文章总结）

遮蔽在现在大部分流行语言里都或多或少出现一点，除了上面展示的，还有例如下面javascript程序中典型的遮蔽：

function outer(x){function inner(x){{let x = 3console.log("x1:" + x)// x = 3}console.log("x2:" + x)// x = 2}console.log("x3:" + x)// x = 1inner(x + 1)
}outer(1)

这种遮蔽还相对安全，因为是可见范围内发生的显式遮蔽。但是Java的类作用域与词法作用域结合使得可以发生隐式的遮蔽，只要出现内部类，不管是成员域还是方法甚至局部变量都有可能发生这类遮蔽。这是语言设计中的意外，对于语言使用者来说难以避免这类问题。

一点点建议

最差的建议：避免使用内部类；
次好的建议：对于类的成员域以及方法的访问采用全限定名，比如：OuterClass.this.name
较好的建议：外部类可使用简写来引用成员域或方法，内部类则采用全名。