考虑以下一组表达式：
class T {{
/*1*/ super.toString(); // direct
/*2*/ T.super.toString(); // synthetic
Supplier<?> s;
/*3*/ s = super::toString; // synthetic
/*4*/ s = T.super::toString; // synthetic
}}
这给出了以下结果：
class T {
T();
0 aload_0 [this]
1 invokespecial java.lang.Object() [8]
4 aload_0 [this]
5 invokespecial java.lang.Object.toString() : java.lang.String [10]
8 pop // ^-- direct
9 aload_0 [this]
10 invokestatic T.access$0(T) : java.lang.String [14]
13 pop // ^-- synthetic
14 aload_0 [this]
15 invokedynamic 0 get(T) : java.util.function.Supplier [21]
20 astore_1 [s] // ^-- methodref to synthetic
21 aload_0 [this]
22 invokedynamic 1 get(T) : java.util.function.Supplier [22]
27 astore_1 // ^-- methodref to synthetic
28 return
static synthetic java.lang.String access$0(T arg0);
0 aload_0 [arg0]
1 invokespecial java.lang.Object.toString() : java.lang.String [10]
4 areturn
Bootstrap methods:
0 : # 40 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:...
#43 invokestatic T.access$0:(LT;)Ljava/lang/String;
1 : # 40 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:...
#46 invokestatic T.access$0:(LT;)Ljava/lang/String;
}
为什么 java代码行/*2*/，/*3*/和/*4*/ 生成并使用合成访问器方法 access$0 ？我希望行/*2*/和/*3*/的行/*4*/和引导方法也使用invokespecial行/*1*/。
特别是当方法Object::toString可直接从相关范围访问时，例如以下方法引用不会包含对合成访问器方法的调用：
class F {{
Function<Object, ?> f = Object::toString; // direct
}}
然而，是的区别：
class O {{
super.toString(); // invokespecial -> "className@hashCode"
O.super.toString(); // invokespecial -> "className@hashCode"
Supplier<?> s;
s = super::toString; // invokespecial -> "className@hashCode"
s = O.super::toString; // invokespecial -> "className@hashCode"
Function<Object, ?> f = Object::toString;
f.apply(O.super); // invokeinterface -> "override"
}
public String toString() {return "override";}
}
这带来了另一个问题：是否有办法绕过((Function<Object, ?> Object::toString)::apply中的覆盖？
答案 0 :(得分：5)
调用super.method()形式允许绕过同一类中的重写method()，调用超类层次结构中最具体的method()。因为，在字节代码级别上，只有声明类本身可以忽略它自己的重写方法（以及子类的潜在重写方法），如果这种调用应该由不同的执行（但在概念上有权），将生成一个合成的访问器方法。 ）class，就像它的一个内部类一样，使用Outer.super.method(...)形式，或者为方法引用生成的合成类。
请注意，即使一个类没有覆盖被调用的方法并且它似乎没有区别，也必须以这种方式编译调用，因为在运行时可能有子类覆盖该方法然后，它会产生影响
有趣的是，当T.super.method()实际上不是外部类而是包含该语句的类时，使用T时会发生同样的事情。在这种情况下，辅助方法并不是必需的，但似乎编译器统一实现了identifier.super.method(...)形式的所有调用。
作为旁注，Oracle的JRE能够在为lambda表达式/方法引用生成类时绕过这个字节代码限制，因此，super::methodName类的方法引用不需要访问器方法，如下所示：
import java.lang.invoke.*;
import java.util.function.Supplier;
public class LambdaSuper {
public static void main(String[] args) throws Throwable {
MethodHandles.Lookup l=MethodHandles.lookup();
MethodType mt=MethodType.methodType(String.class);
MethodHandle target=l.findSpecial(Object.class, "toString", mt, LambdaSuper.class);
Supplier<String> s=(Supplier)LambdaMetafactory.metafactory(l, "get",
MethodType.methodType(Supplier.class, LambdaSuper.class),
mt.generic(), target, mt).getTarget().invokeExact(new LambdaSuper());
System.out.println(s.get());
}
@Override
public String toString() {
return "overridden method";
}
}
生成的Supplier将返回类似LambdaSuper@6b884d57的内容，表明它调用了重写的Object.toString()方法，而不是重写LambdaSuper.toString()。似乎编译器供应商对于JRE功能的期望是谨慎的，不幸的是，这部分似乎有点不明确。
但是，对于真正的内部类场景，他们是必需的。
答案 1 :(得分：0)
Holger已经解释为什么它正在发生 - super引用仅限于直接子类。这里只是一个更详细的版本，真正发生在那里：
class T {
class U {
class V {{
/*2*/ T.super.toString();
}}
}
}
它生成一系列合成访问器方法：
class T {
static synthetic String access$0(T t) { // executing accessor
return t.super.toString(); // only for the refered outer class
}
class U { // new U(T.this)
static synthetic T access$0(U u) { // relaying accessor
return T.this; // for every intermediate outer class
}
class V {{ // new V(U.this)
T.access$0(U.access$0(U.this)); // T.access$0(T.this)
}}
}
}
当T是直接封闭的类时，即没有中间外部类，只在类T中生成“正在执行”的访问器（即本身，这似乎是不必要的）。
N.B。：访问者链由 Eclipse 生成，但不是由 OpenJDK 生成，请参见下文。
class T {
class U {
class V {{
Supplier<?> s;
/*3*/ s = super::toString;
}}
}
}
这将生成一个合成访问器方法和一个委托给它的引导方法：
class T {
class U {
class V {
static synthetic String access$0(V v) {
return v.super.toString();
}
dynamic bootstrap Supplier get(V v) { // methodref
return () -> V.access$0(v); // toString() adapted to get()
}
{
get(V.this);
}
}
}
}
这是一个与前一个类似的单一案例，因为super::toString在这里等同于V.super::toString，因此合成访问器在类V中生成。这里的新元素是用于使Object::toString适应Supplier::get的引导方法。
注意：这里只有 OracleJDK 足够“智能”（如Holger指出的那样）通过将super调用直接放入方法引用适配器来避免合成访问器
class T {
class U {
class V {{
Supplier<?> s;
/*4*/ s = T.super::toString;
}}
}
}
正如您所料，这是前两种情况的组合：
class T {
static synthetic String access$0(T t) { // executing accessor
return t.super.toString(); // only for the refered outer class
}
class U { // new U(T.this)
static synthetic T access$0(U u) { // relaying accessor
return T.this; // for every intermediate outer class
}
class V { // new V(U.this)
dynamic bootstrap Supplier get(T t) { // methodref
return () -> T.access$0(t); // toString() adapted to get()
}
{
get(U.access$0(U.this)); // get(T.this)
}
}
}
}
这里没有什么新东西，只需注意内部类总是只接收外部类的实例，所以在类V中，使用T.this它可能会经历整个中间链合成访问方法，例如U.access$0(V.U_this)（如 Eclipse ），或利用这些合成字段的包可见性（引用outer.this）并将T.this翻译为{{1} （如 OpenJDK ）。
<小时/> N.B。：上述翻译符合 Eclipse 编译器。 OpenJDK 在为方法引用生成实例合成lambda方法方面有所不同，而不像 Eclipse 那样生成静态合成访问方法，并且还避免了访问链，所以在最后一种情况下 OpenJDK 发出：
V.U_this.T_this<小时/> 总而言之，它完全依赖于编译器供应商。