JAVA基础之八-方法变量作用域和编译器
本文主要讨论方法中变量作用域。不涉及类属性变量、静态变量、线程变量共享等。
虽然知道某类变量的作用域非常重要，但是没有太多需要说的，因为许多东西是显而易见，不言自明。
在大部分情况下，或者在老一点版本中，java语法看起来都比较正常，或者说相对古典。
但是随着JAVA版本的迭代，已经愈发向JAVASCRIPT靠近了-随意。 也许JCP想把JAVA变成后端的JS。
但我们需要知道，用为JS过于随意邋遢，才会有TypeScript。
一、前言
闲话少说。
在经典场景中，每个变量/属性的作用域都是相对稳定/固定的，例如：
1.方法可以引用实例变量，类静态变量
2.方法内部定义的变量，其它方法，外部类无法看到
这些规则都很容易理解和遵守。
但是随着JAVA的语法变迁，其中一个方面，函数/方法中变量作用域也变得更加灵活（随意）。
大部分程序员，其实很少在一个方法内部定义类，反而是一些开源的组件用得多，不太明白这些意图。
如果还要让方法和方法内部类共享变量，那么就会让代码看起来古怪，且非常类似于JS的经典问题：闭包。
来看一下以下一段代码：
@Override @Nullable public <T> T query(final String sql, final ResultSetExtractor<T> rse) throws DataAccessException { Assert.notNull(sql, "SQL must not be null"); Assert.notNull(rse, "ResultSetExtractor must not be null"); if (logger.isDebugEnabled()) { logger.debug("Executing SQL query [" + sql + "]"); } // Callback to execute the query. class QueryStatementCallback implements StatementCallback<T>, SqlProvider { @Override @Nullable public T doInStatement(Statement stmt) throws SQLException { ResultSet rs = null; try { rs = stmt.executeQuery(sql); return rse.extractData(rs); } finally { JdbcUtils.closeResultSet(rs); } } @Override public String getSql() { return sql; } } return execute(new QueryStatementCallback(), true); }
这是Spring 6.2.0-SNAPSHOT 中 spring-jdbc的 org.springframework.jdbc.core.JdbcTemplate#query(String, ResultSetExtractor<T>) 方法的代码。
在这段代码中，spring直接定义一个内部类 QueryStatementCallback 。
妙的是QueryStatementCallback 直接利用了query中定义的参数rse。
这种使用方式和js的对方法变量的使用（闭包）如出一辙。至少外表上是一样的。
到现在为止，我们知道这样一个事实：至少J17中可以这么写（其它没有研究)。
接下来，纯粹是出于技术人好奇，有几点：
1.这个对性能有什么影响
2.如何实现的？
3.如果性能没有好处，为什么要那么搞？
二、模仿例子
为了便于了解这个问题，创建了一个类似的例子，方便一些。
package study.base.varscope; @FunctionalInterface public interface ISum { long sum(); } /** * 测试方法内的变量作用域，类似于js的闭包 */ public class TestVarScope { public void test() { //创建一个有1000个元素的数组，每个元素都是介于1~999之间的随机数 int[] arr = new int[1000]; Random random = new Random(); for (int i = 0; i < 1000; i++) { arr[i] = random.nextInt(1,1000); } class SumClass implements ISum { @Override public long sum() { //累加 arr long total = 0; for (int i : arr) { total += i; } return total; } } SumClass sc=new SumClass(); long total=sc.sum(); System.out.println(total); } public static void main(String[] args) { TestVarScope testVarScope = new TestVarScope(); testVarScope.test(); } }
没有编译错误，可以执行。
所以奥妙一定在于编译器上，只要看看编译后的东西就明白了。
class文件
可以看到含$是方法内部类.
再看看 TestVarScope$1SumClass.class的内容
先看反编译内容
再看私有成员
结合以上两张图，可以比较肯定地推测出如下：
内部类SumClass被改写了：
a.SumClass新增了一个私有final的数组 val$arr,用于存储上级对象的属性（数组）
b.SumClass有一个带两个参数的构造函数，前后分别是上级类的实例，需要接受的数组
c.sum（）方法，访问val$arr，以便进行汇总
再用三方工具(jadx)可以查看出:
和预想的一致。
注：如果用idea（2024.2.1）的默认反编译工具，会得到错误的结果，所以用那个来看源码有点危险，倒是eclipse的做得不错。
以下是eclipse的class File viewer：
针对前一章节的问题，可以如下作答：
1.这个对性能有什么影响
基本没有什么影响。
2.如何实现的？
如上，通过编译器改写内部类和上级类方法来完成，一切功劳在于编译器.
3.如果性能没有好处，为什么要那么搞？
方便，或者偷懒而已。
三、小结
java的语言越来越随意，通过编译器的功能（或者所谓的语法糖），可以实现类似js那样随意的效果。
就本文所阐述的问题，本质上并不是说内部类可以访问上级的属性，而是一种错觉，在语法上让我们以为可以访问。
就我个人而言，并不喜欢这些隐藏了实现的编码方式，大概因为开始编程的时候，学习的都是古典语法。
现在的一些新的东西，虽然某些情况下会工程上的某些好处，但是反作用也是明显的：复杂化编译器；有可能培养不是很
好的编码习惯。
关于方法变量的作用域问题，目前暂时没有其它可以说的。
