Java中能否在main方法所在类内部创建该类的对象？

在Ja va的世界里，public static void main(String[] args) 这个签名几乎是每个程序员的起点。它作为JVM启动程序的唯一约定入口，必须满足三个硬性条件：public（供JVM跨包调用）、static（无需实例即可加载执行），以及固定的参数签名。然而，这些约束仅仅作用于方法本身，并没有给方法体内部的代码戴上枷锁。一个常见且合理的疑问随之而来：在这个静态的起点里，能否创建它所在类自身的实例呢？

答案是肯定的，这不仅完全合法，更是一种标准实践。静态的main方法就像一个“启动器”，它的核心任务就是为程序的运行搭建舞台，而创建对象，包括创建它自己所属类的对象，正是搭建舞台的关键步骤。

来看一段典型的代码，它清晰地展示了这一过程：

public class Main {
    void something() {
        System.out.println("Works?");
    }
    public static void main(String[] args) {
        Main m = new Main();  // ✅ 合法：在main中创建本类实例
        m.something();        // ✅ 合法：通过实例调用非静态方法
    }
}

这段代码运行起来毫无问题。那么，随之而来的两个核心疑问就需要厘清了。

为什么不会导致无限递归？

关键在于区分“声明”与“执行”。class Main { ... } 这部分是编译期的类型声明，它只是告诉编译器存在这么一个类模板，本身不会创建任何对象。而 new Main() 是运行时的显式指令，只有当程序执行到main方法中的这一行时，才会在堆内存中实实在在地分配空间、构造出一个Main对象。因此，整个过程是线性的、一次性的，并不会自动陷入循环。当然，如果你在something()方法里又写了new Main()，并且形成了调用闭环，那就会导致逻辑上的递归，但这属于程序员可控的业务逻辑，而非语法机制强制的陷阱。

为什么能访问非静态成员？

这触及了面向对象的核心。静态方法（如main）属于类本身，没有this引用，因此无法直接访问属于对象的非静态字段或方法。但是，一旦通过new Main()获得了这个类的一个具体实例（比如变量m），你就拥有了一个指向对象的引用。通过这个引用，你可以像在任何其他方法中一样，自由地调用该对象的所有实例成员。这正是“通过对象来使用行为”这一基本思想的体现。

需要注意的几个边界

虽然模式简单直接，但在实际运用中，仍有几个细节需要留意：

• 静态初始化陷阱：需要警惕的是，如果在静态上下文（如静态变量初始化、静态代码块）中无条件地创建本类实例，并且该实例化过程又间接触发了对同类静态成员的访问，则可能引发ExceptionInInitializerError，导致静态初始化死锁。幸运的是，main方法本身是在类初始化完成之后才被JVM调用的，因此不存在这个风险。
• 非静态内部类：如果你的main方法位于一个外部类中，而你需要创建其非静态内部类的对象，则不能直接new InnerClass()。必须先拥有一个外部类的实例，语法是：new Main().new InnerClass()。
• 对象生命周期：在main方法中创建的对象，其引用通常作为局部变量存在，生命周期仅限于main方法的执行期间。如果程序的其他部分需要共享这个对象，就需要考虑将其提升为类成员（并注意线程安全问题），或者通过方法参数进行传递。

话说回来，这种“静态入口创建自身实例”的模式，其应用场景非常广泛。它不仅是快速验证代码、教学演示的利器，也常见于许多轻量级工具类的设计。更进一步，观察一些主流框架，比如Spring Boot的启动类，其本质也是遵循这一模式：在main方法中构建ApplicationContext（核心容器对象），然后委托给这个对象来驱动整个应用的生命周期。

总而言之，在main方法中创建其宿主类的对象，绝非语法上的巧合或奇技淫巧。它是Ja va语言设计中，静态启动机制与动态面向对象世界之间一个自然而优雅的衔接点。它既恪守了JVM的启动约定，又为我们打开了通往完整对象王国的大门。