本文主要讨论方法中变量作用域。不涉及类属性变量、静态变量、线程变量共享等。

虽然知道某类变量的作用域非常重要，但是没有太多需要说的，因为许多东西是显而易见，不言自明。

在大部分情况下，或者在老一点版本中，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那样随意的效果。

就本文所阐述的问题，本质上并不是说内部类可以访问上级的属性，而是一种错觉，在语法上让我们以为可以访问。

就我个人而言，并不喜欢这些隐藏了实现的编码方式，大概因为开始编程的时候，学习的都是古典语法。

现在的一些新的东西，虽然某些情况下会工程上的某些好处，但是反作用也是明显的：复杂化编译器；有可能培养不是很

好的编码习惯。

关于方法变量的作用域问题，目前暂时没有其它可以说的。