运行时触发MissingResourceException：无法找到FormatData资源包求助

这问题确实挺头疼的，结合你提到的应用场景——大型Java程序、沙箱库、动态编译用户代码，还有同一环境下大量进程启停，我来梳理下可能的原因和具体的排查方向：

1. 类加载器泄漏或资源缓存污染 #

你用到了javax.tools.JavaCompiler动态编译用户代码，再加上沙箱库的类隔离，这类场景很容易出现类加载器泄漏。每次动态编译大概率会创建新的类加载器，如果这些加载器没被正确回收，不仅会占用大量内存，还可能干扰系统类加载器对核心资源包的访问逻辑。

尤其是ResourceBundle本身带有缓存机制，如果某个自定义类加载器错误加载了资源（或者加载失败后留下了异常缓存），后续主线程调用系统API时可能会复用这个错误缓存，导致报错持续到重启——毕竟重启会清空所有缓存，自然能暂时恢复。

2. 沙箱库的类加载隔离干扰 #

沙箱库的核心是做类加载隔离，限制用户代码的访问权限，但如果它的隔离策略没处理好，可能会篡改线程上下文类加载器（Thread Context ClassLoader）。比如用户代码运行时，沙箱把上下文加载器换成了自定义隔离加载器，而主线程后续调用DecimalFormatSymbols.getInstance()时，依然用这个被篡改的加载器去加载系统资源包，自然找不到sun.text.resources.FormatData。

3. 大量进程启停引发的系统资源问题 #

同一Java环境下频繁启停大量进程，可能会导致系统级别的资源泄漏：比如文件句柄耗尽，导致JVM无法读取rt.jar里的资源文件；或者进程启停时的类加载器资源没有完全释放，引发后续进程（或当前进程）的资源访问冲突。这类问题重启应用能暂时缓解，但系统资源没恢复的话，过段时间必然复现。

• 排查类加载器泄漏：

  • 用VisualVM或JProfiler监控应用运行时的类加载器数量，如果数量只增不减，基本实锤泄漏。重点关注动态编译生成的加载器和沙箱库创建的加载器。
  • 检查代码里有没有静态变量缓存了类实例、类加载器引用的情况，这类代码会阻止GC回收加载器。

• 验证线程上下文类加载器：

  • 在调用DecimalFormatSymbols.getInstance(Locale.US)前后，打印当前线程的上下文加载器：

    System.out.println("调用前上下文类加载器: " + Thread.currentThread().getContextClassLoader());
    DecimalFormatSymbols symbols = DecimalFormatSymbols.getInstance(Locale.US);
    System.out.println("调用后上下文类加载器: " + Thread.currentThread().getContextClassLoader());
    

  • 如果发现加载器被篡改（变成了沙箱或动态编译的加载器），可以在调用系统API前临时恢复为系统类加载器：

    ClassLoader originalLoader = Thread.currentThread().getContextClassLoader();
    try {
        // 强制用系统类加载器加载资源
        Thread.currentThread().setContextClassLoader(ClassLoader.getSystemClassLoader());
        DecimalFormatSymbols symbols = DecimalFormatSymbols.getInstance(Locale.US);
    } finally {
        // 用完恢复原加载器，避免影响其他逻辑
        Thread.currentThread().setContextClassLoader(originalLoader);
    }
    

• 排查ResourceBundle缓存污染：

  • 尝试在报错时手动清空ResourceBundle缓存，看是否能恢复：

    // 清空所有类加载器的缓存
    ResourceBundle.clearCache();
    // 或者只清空系统类加载器的缓存
    ResourceBundle.clearCache(ClassLoader.getSystemClassLoader());
    

  • 如果清空后问题解决，说明缓存被异常加载的资源污染了，需要找到沙箱或用户代码中错误加载资源的逻辑。

• 检查系统资源使用情况：

  • 用lsof（Linux）或系统资源监视器（Windows）查看应用进程的文件句柄数量，如果持续增长到系统上限，排查代码中未关闭的文件流（尤其是动态编译生成的临时文件）。
  • 开启JVM类加载日志（添加启动参数-verbose:class），观察sun.text.resources.FormatData加载时用的是哪个类加载器，定位异常加载源。

• 验证沙箱库的类加载策略：

  • 查看沙箱库的配置文档，确认是否允许访问sun.text.resources.FormatData这类系统资源包，如果默认禁止，需要添加对应的权限配置。
  • 检查沙箱运行用户代码时，是否会自动替换线程上下文类加载器，是否提供了恢复上下文的机制。

如果暂时找不到根源，可以绕过系统API的默认加载逻辑，直接用系统类加载器加载资源并构建DecimalFormatSymbols：

// 强制用系统类加载器加载资源包
ResourceBundle formatBundle = ResourceBundle.getBundle(
    "sun.text.resources.FormatData", 
    Locale.US, 
    ClassLoader.getSystemClassLoader()
);
// 手动构建DecimalFormatSymbols
DecimalFormatSymbols symbols = new DecimalFormatSymbols(formatBundle);

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