引用API文档：
一些实现可能使用NULL来表示引导类加载器。如果此类类是由引导类加载器加载的，则此方法在此类实现中将返回NULL。

这就是它的工作原理。每当JVM尝试加载任何类时，它都会在以下条件下进行检查。
如果Class是从Bootstrap ClassPath加载的，即：jdk\jre\lib\rt.jar，则将调用Bootstrap ClassLoader。
如果类是从扩展类路径加载的，即：jdk\jre\lib\ext*.jar，则将调用扩展ClassLoader。
如果Class是从应用程序ClassPath加载的，即在环境变量中指定，则调用应用程序ClassLoader。
因为Bootstrap ClassLoader不是用Java实现的，所以它是用c或c++实现的，所以没有对它的引用，这就是它返回NULL的原因。但是扩展和应用程序类Loader是用Java编写的，所以您将获得如下引用：sun.misc.Launcher$ExtClassLoader@omeHexValue和sun.misc.Launcher$AppClassLoader@omeHexValue。
因此，如果您执行类似System.out.println(String.class.getClassLoader())的操作，您将得到NULL，因为此类是由Bootstrap ClassLoader调用的，而另一方面，如果您对Ext或App Class Path中的类执行相同的操作，您将分别获得$ExtClassLoader@omeHexValue和sun.misc.Launcher$AppClassLoader@omeHexValue。

如果此类类是由引导类加载器加载的，则此方法在此类实现中将返回NULL。
Https://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getClassLoader()

也有类似的问题。通过不使用getClass方法解决。以下内容对我很管用。

<ClassName>.class.getClassLoader();

有一件事是肯定的，与从命令行运行时相比，Eclipse具有更深更复杂的类加载器设置。如果您看到一个类的类加载器在一个和另一个中的显示方式不同，那么这很可能是一个原因。
我不太了解Eclipse到底在做什么，但我认为很可能您的类在从Eclipse运行时并不是由引导类加载器加载的，而是Eclipse试图让它看起来是这样的。
一旦应用程序启动，Bootstrap ClassLoader就是静态的，您以后不能向其中添加JAR或类，除非Eclipse已经覆盖了实现……在这种情况下，还有另一种可能的解释。

@Dilou的答案指向了正确的方向。检查您在Eclipse中的运行配置的设置：转到Classpath选项卡并检查您添加依赖项的位置。有两个类别：

• 引导条目
• 用户条目

如果将依赖项添加到第一个类别，则使用引导classloader，并且会出现大多数其他答案中提到的问题：它返回为空。
因此，要解决这个问题，请将您的依赖项移动到“用户条目”部分。

我也有同样的问题。但解决它的方法是：-

<ClassName>.class.getClass().getResource(urlString);

希望这能帮助其他人。

“如果此类类是由引导类加载器加载的，则此方法在此类实现中将返回NULL。”-JavaDoc at getClassLoader()
出于安全目的，空类加载器是为系统类保留的，只有在Class.forName(字符串名，布尔初始化，ClassLoader加载器)的情况下才能使用。如果类的ClassLoader为空，则不会进行大多数安全检查。

在启动应用程序时，单击应用程序类路径设置下的“Show Command Line”按钮可能会有所帮助，以便了解在类路径设置方面的确切内容。(我使用的是Eclipse 2020-06)。对于我来说，它显示了包含调用<ClassName>.class.getClassLoader();的类的JAR文件，该类返回空值，实际上前面有
-Xbootclasspath/a：