为何Java中sun.misc.Launcher设为公共构造方法？类加载相关疑问

Great question! Your intuition is heading in the right direction, but let's unpack the details fully.

首先：为什么两次获取的类加载器实例不同？ #

Let's start with what's actually happening in your code:

• Launcher.getLauncher() returns the system singleton Launcher instance created when the JVM starts up. This instance's class loader is the default AppClassLoader used to load your application's classes during normal execution.
• When you call new Launcher(), you're creating a completely fresh Launcher instance from scratch. This new instance initializes its own full class loader hierarchy—including a brand-new AppClassLoader—that's totally independent of the system singleton.

That's why your output shows two distinct AppClassLoader objects (different hash codes always mean different instances in Java).

你的猜想是否正确？ #

Your core idea is on the mark, but let's refine it a bit:
The public constructor for sun.misc.Launcher exists not just to spawn different AppClassLoader instances, but to let developers create entirely isolated class loading environments that don't share state with the JVM's default class loader system.

背后的深层原因 #

If you peek at the internal implementation of Launcher (it's a JDK internal class, not part of the official Java standard API):

• The system singleton is initialized in a static block using a private constructor, ensuring only one default instance exists for the JVM's lifetime.
• The public constructor runs through the full setup process for Bootstrap ClassLoader, Extension ClassLoader, and Application ClassLoader from scratch. This builds a parallel class loading hierarchy that operates separately from the default system one.

Java's class loading follows the delegation model, but there are valid scenarios where you need to break out of this default hierarchy to isolate classes—this is exactly what the public constructor enables.

实际应用场景 #

Here are real-world use cases where creating a separate Launcher (or similar isolated class loader) makes sense:

• Application Server Class Isolation: Servers like Tomcat use custom class loaders (similar in concept to a new Launcher's hierarchy) to isolate individual web applications. Each app gets its own class loader, so different apps can use conflicting library versions (e.g., Spring 5 vs. Spring 6) without crashing each other.
• Plugin-Based Systems: IDEs (like IntelliJ) or desktop apps with plugins often load each plugin in an isolated class loader. Using a new Launcher instance is one way to create this isolation, ensuring plugin classes don't interfere with the main app or other plugins.
• Compatibility Testing: When testing how your code works with different library versions, you can create separate Launcher instances to load each version's classes in the same JVM, avoiding class version conflicts that would otherwise break your test environment.
• Dynamic Code Execution: If you're compiling code on the fly and need to load it in a clean, untainted environment, a new Launcher's class loader provides a fresh space that won't mix with already loaded system classes.

重要提醒 #

Keep in mind that sun.misc.Launcher is an internal JDK API, not part of the official Java standard. It's not guaranteed to exist in non-Oracle/OpenJDK implementations, and it may be removed or modified in future Java versions (especially with modularization introduced in Java 9). For production code, it's always better to implement custom class loaders instead of relying on this internal class.

内容的提问来源于stack exchange，提问作者spongecaptain