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那样随意的效果。
就本文所阐述的问题,本质上并不是说内部类可以访问上级的属性,而是一种错觉,在语法上让我们以为可以访问。
就我个人而言,并不喜欢这些隐藏了实现的编码方式,大概因为开始编程的时候,学习的都是古典语法。
现在的一些新的东西,虽然某些情况下会工程上的某些好处,但是反作用也是明显的:复杂化编译器;有可能培养不是很
好的编码习惯。
关于方法变量的作用域问题,目前暂时没有其它可以说的。