昨儿早上，我同事端着一杯美式过来问我：你知道 Kotlin 有个 inner class 吗？
我：我还有什么不知道的吗？这个就是内部类啊！
同事：那和 Java 的内部类有什么区别？
我：等等，你听我慢慢讲来，就这一杯咖啡的时间。
什么是 Inner Class
inner class（内部类）是定义在另一个类内部、并且能够访问外部类成员的类，这些成员可以包括私有属性和私有方法。声明时需要显式加上 inner 关键字。
与之对应的 nested class（嵌套类）在 Kotlin 中默认是静态的，它不会自动持有外部类实例。
换句话说：
- 内部类总是“挂”在某个外部类实例之上。
- 内部类可以直接访问外部类的所有成员，包括私有成员。
- 如果需要在内部类中显式引用外部类实例，可以使用
this@OuterClass语法。
这种设计让内部类非常适合表达那种“行为强烈依赖外部对象状态”的场景。
基本示例
下面的示例演示了如何通过 inner 关键字定义内部类，并在内部类中访问外部类的成员：
class OuterClass(val name: String) {
private val secret = "Secret Code"
inner class InnerClass {
fun reveal() = "Outer name: $name, Secret: $secret"
}
}
fun main() {
val outer = OuterClass("OuterName")
val inner = outer.InnerClass()
println(inner.reveal()) // Output: Outer name: OuterName, Secret: Secret Code
}
在这个示例中，InnerClass 既访问了公开的 name 属性，也访问了私有的 secret 属性，这都是通过持有外部类实例引用实现的。
如果内部类需要显式“点名”外部类实例，可以使用 this@OuterClass：
class OuterClass(val name: String) {
inner class InnerClass {
fun showOuterReference() = this@OuterClass.name
}
}
这里 this@OuterClass 明确告诉编译器，我们要的是外部 OuterClass 的那个 this，而不是当前内部类的 this。
Nested vs Inner：语义上的关键差异
在 Kotlin 中，你可以在一个类里面再次定义类，这些内部定义的类统称为“嵌套类”，根据是否使用 inner 关键字，又分为：
- nested class：声明时不带
inner。它在字节码层面对应 Java 的静态内部类，不持有任何外部类实例的引用。因此，它无法直接访问外部类的属性和函数，除非这些内容显式通过构造函数参数或方法参数传入。 - inner class：声明时使用
inner关键字，表示该类会维护一个指向外部类实例的引用。它可以自由访问外部类的所有成员，包括私有成员，非常适合描述高度依赖外部状态的行为。
下面的例子把二者放在同一个外部类中，直观展示它们在访问能力上的差异：
class OuterClass {
val outerValue = "Outer Value"
class NestedClass {
fun show() = "No access to outerValue"
}
inner class InnerClass {
fun show() = "Access to outerValue: $outerValue"
}
}
在这个示例中：
NestedClass无法直接访问outerValue，因为它没有保存OuterClass的实例引用；InnerClass则可以直接使用outerValue，原因正是它作为内部类持有外部类实例。
在设计 Kotlin 应用中的类关系和作用域时，首先要判断某个嵌套类是否真的需要访问外部类实例——如果需要，就用 inner，如果不需要，就保持为默认的 nested class。
常用场景
- 封装相关行为：当一组行为高度依赖外部对象的状态时，可以用内部类把它们紧密绑定在一起，同时又避免把这组行为暴露给外部世界。
- UI 组件与回调：在 Android 中，内部类常被用作监听器或事件处理器，它们需要访问
Activity或Fragment的状态，因此持有外部类引用会非常方便。
潜在问题
当然，inner class 是一把双刃剑。
- 内存泄漏风险：如果内部类的生命周期长于外部类实例（例如被保存到某个长生命周期的单例或后台线程里），就会因为它持有外部类引用而阻止外部类被垃圾回收。在 Android 里，这是一类非常典型的内存泄漏来源（大家应该听说过大名鼎鼎的
Handler泄露问题）。 - 结构复杂度：过度依赖内部类会让类与类之间的关系变得复杂难懂，阅读和维护成本上升。因此通常建议在真正需要访问外部实例时才使用
inner，其余情况优先选择 nested class 或顶层类。
小结
内部类为在类与其组件之间创建紧密耦合的关系提供了便捷手段。它们可以直接访问外部类的成员，在某些场景下非常有用，但也应该谨慎使用，以避免出现诸如内存泄漏之类的问题。
深入到底层
为了更清楚地理解编译器是如何对待 inner class 与 nested class 的，我们来看一个更贴近实战的示例。下面的 Kotlin 代码中，Vehicle 封装了两个概念：
Wheel：通用组件，被定义为嵌套类；Engine：与具体车辆强相关的组件，被定义为内部类。
class Vehicle(val brand: String) {
private val topSpeed = 200
fun identify() {
println("This is a $brand vehicle.")
}
// Default nested class: Does NOT hold a reference to a Vehicle instance.
class Wheel(val rimSize: Int) {
fun checkPressure() {
println("Checking pressure on a $rimSize-inch wheel.")
// A COMPILE ERROR would occur if we tried to access `brand`.
}
}
// Inner class: HOLDS a reference to a Vehicle instance.
inner class Engine(val cylinderCount: Int) {
fun start() {
// Can access outer members because it's an 'inner' class.
println("Starting the $cylinderCount-cylinder engine of the $brand.")
println("Top speed is rated at $topSpeed km/h.")
this@Vehicle.identify()
}
}
}
如果不能一眼看出差异，那么我们创建两个实例就知道了：
fun main() {
val toyota = Vehicle("Toyota")
// Wheel：直接通过 Vehicle.Wheel(...)
val wheel = Vehicle.Wheel(18)
wheel.checkPressure()
// Engine：通过某个 Vehicle 实例来创建
val engine = toyota.Engine(4)
engine.start()
}
从这个例子中，你可以马上看出二者在使用方式上的差异：
Wheel可以通过Vehicle.Wheel(...)直接实例化，它与某个具体的Vehicle实例没有绑定关系；Engine则必须在已有Vehicle实例的前提下才能创建，比如toyota.Engine(...)，因为它需要访问brand、topSpeed等外部成员。
这背后其实是字节码结构上的巨大差异。为了看清这一点，我们把上述 Kotlin 代码编译并反编译为 Java。
反编译 Vehicle
外部类 Vehicle 在 Java 中的结构大致如下：
public final class Vehicle {
private final String brand;
private final int topSpeed = 200;
// ... (Vehicle's constructor and methods) ...
}
这里还看不出什么特别之处，真正的差别体现在嵌套类和内部类的反编译结果上。
反编译 Wheel
Wheel 作为 Kotlin 中的 nested class，在 Java 中会被编译成静态嵌套类：
// --- Decompilation of the NESTED class ---
// It becomes a STATIC nested class.
public static final class Wheel {
private final int rimSize;
// Standard constructor, no reference to Vehicle.
public Wheel(int rimSize) {
this.rimSize = rimSize;
}
public final void checkPressure() {
System.out.println("Checking pressure on a " + this.rimSize + "-inch wheel.");
}
}
从这段代码可以看到几个关键点：
Wheel使用static声明，是一个 静态嵌套类；- 构造函数只接受
rimSize，没有任何关于Vehicle的参数或字段； - 它内部也不会试图访问
Vehicle的成员。
总结起来就是：
- 没有实例引用：
static关键字意味着Wheel是一个与外部类实例完全解耦的实体，它内部不包含对任何Vehicle对象的隐藏引用。 - 构造函数简单：
public Wheel(int rimSize)只关心自身需要的参数。 - 内存含义：正因为没有外部实例引用，
Wheel对象不会意外地让某个Vehicle对象常驻内存。就内存安全性而言，这是一种“更稳妥的默认值”。
反编译 Engine
再来看 Engine，它在 Kotlin 中被声明为 inner class，在 Java 里则会变成一个非静态嵌套类，并包含一个特殊的隐藏字段：
// --- Decompilation of the INNER class ---
// It becomes a NON-STATIC nested class.
public final class Engine {
private final int cylinderCount;
// Hidden field holding the reference to the outer Vehicle instance.
public final Vehicle this$0;
// Constructor receives the outer instance.
public Engine(Vehicle this$0, int cylinderCount) {
this.this$0 = this$0;
this.cylinderCount = cylinderCount;
}
public final void start() {
// Member access is re-routed through the hidden reference.
System.out.println("Starting the...engine of the " + this.this$0.getBrand() + ".");
// ... (access to private fields may use a synthetic method)
this.this$0.identify();
}
}
这里可以提炼出同样三点，但含义恰好相反：
- 隐藏引用（
this$0）：编译器会在Engine中注入一个名为this$0的字段，用来保存创建它的那个Vehicle实例。这就是内部类能够访问外部类成员的根本原因。 - 修改后的构造函数：构造函数签名变为
Engine(Vehicle this$0, int cylinderCount)，第一个参数就是外部类实例。也就是说，Kotlin 中看似简单的myCar.Engine(4)，在字节码里会变成new Vehicle.Engine(myCar, 4)。 - 内存含义：
Engine实例会强引用某个Vehicle实例。如果Engine比Vehicle活得更久（比如被丢进一个长生命周期的单例或线程里），就会阻止Vehicle被垃圾回收，从而埋下内存泄漏的隐患。
字节码的对照
从反编译结果可以看出，Kotlin 对 nested class 和 inner class 的处理并不是一个小小的语法糖差别，而是 两种完全不同的字节码结构：
-
nested class → static 嵌套类
Kotlin 默认的 nested class 会被编译成 Java 的static嵌套类。它不依赖任何外部类实例，也就不会通过隐藏引用制造多余的内存关系。- 没有额外字段保存外部实例；
- 构造函数参数只负责自身需要的依赖；
- 在内存管理上更加安全、可预测。
-
inner class → 非 static 嵌套类
使用inner关键字声明的内部类，会被编译成 Java 中的非static嵌套类：- 包含一个隐藏字段
this$0，专门保存外部类实例； - 构造函数会增加一个外部类实例参数；
- 可以自由访问外部类的属性和方法（包括私有成员），但也因此更容易引发内存泄漏。
- 包含一个隐藏字段
换句话说，Kotlin 通过让 nested class 成为默认选项，把“解耦、内存友好”的结构设定为基线；而 inner 则是开发者显式选择的一种更强大的能力，它带来更紧密的对象关系，同时也带来更大的责任。
选择建议
基于上面的分析，可以给出一个简单的经验法则：
- 优先使用
nested class：当某个类只是逻辑上隶属于外部类，但在运行时并不需要访问外部实例时，让它保持为默认的嵌套类即可。这种设计更加解耦、利于复用，也更安全。 - 只在确实需要外部实例时才使用
inner：当类的行为必须依赖外部对象状态（例如读写外部类的属性、调用其方法），并且你清楚了解其中的生命周期关系和内存风险时，再选择inner class。
将这些差异放到字节码和内存模型的层面来理解，有助于在真实项目中做出更稳健的设计选择。你不仅能解释“为什么内部类可以访问外部类状态”，更能清楚地意识到随之而来的内存管理责任：如果处理不当，一段看似简单的内部类代码，就有可能变成应用里那个难以诊断的泄漏源头。
掌握 inner class 与 nested class 在语义和字节码上的完整差异，是写出既灵活又高效、同时避免泄漏问题的 Kotlin 代码的重要一环。
随着最后一口咖啡喝进嘴里，我的同事意满离！
