java - 静态 block 中的 getResourceAsStream 有时返回 null

Question

我有一些代码可以在类的顶部执行此操作:

static {
    ...
    mapper.addMappingConfig(ModelRestMapper.class.getResourceAsStream("/com/mycompany/myapp/rest/dozer/mapping/mapping.xml"));
    ...
}

此代码有时会因以下异常而失败:

[#|2014-05-23T12:21:33.111-0700|SEVERE|glassfish3.1.2|org.dozer.loader.xml.MappingStreamReader|_ThreadID=305;_ThreadName=Thread-2;|Error while loading dozer mapping InputStream: [null]
    java.lang.IllegalArgumentException: InputStream cannot be null
    at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:117)
    at org.dozer.loader.xml.MappingStreamReader.read(MappingStreamReader.java:50)
    at org.dozer.DozerBeanMapper.addMapping(DozerBeanMapper.java:247)
    at com.mycompany.commons.objectmapping.Mapper.addMappingConfig(Mapper.java:62)
    at com.mycompany.myapp.rest.dozer.mapping.ModelRestMapper.<clinit>(ModelRestMapper.java:30) //the line I showed you
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:140)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1057)
at java.lang.reflect.Field.getFieldAccessor(Field.java:1038)
at java.lang.reflect.Field.set(Field.java:741)
at org.glassfish.web.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:1836)
at org.glassfish.web.loader.WebappClassLoader.stop(WebappClassLoader.java:1662)
at org.glassfish.web.loader.WebappClassLoader.preDestroy(WebappClassLoader.java:1631)
at org.glassfish.javaee.full.deployment.EarClassLoader.preDestroy(EarClassLoader.java:91)
at org.glassfish.deployment.common.DeploymentContextImpl.preDestroy(DeploymentContextImpl.java:151)
at com.sun.enterprise.v3.server.ApplicationLifecycle$1.actOn(ApplicationLifecycle.java:281)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:465)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:745)
|#]

我想说这种情况大约每 10 次部署就会发生一次，并且在我下次尝试时它似乎总是有效。这是部署在 war 中的类，应用程序服务器是 GlassFish 3.1.2。这个类(class)没什么特别的，只是一个pojo。当错误发生并且我打开 war 时，我看到该 xml 文件恰好在它应该在的位置。这是我的 JRE:

java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

我不应该在 war 中使用这样的代码吗？为什么会发生这种情况以及如何预防？

Answer 1

根据堆栈跟踪，异常是在应用程序上下文被销毁时发生的。这个问题似乎与 Glassfish 的 WebappClassLoader 有关。默认情况下，将所有已加载类的任何静态和最终字段设置为 null 作为避免内存泄漏的解决方法。

这可能会导致类的(重新)初始化，即调用尝试加载资源的静态初始化 block ，但由于某种竞争条件而失败。

有一个系统属性org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES控制清除引用的过程(link)。您可以尝试设置为 false 并查看发生了什么。

另一个(更好的)选项是将资源的加载移到静态初始化 block 之外。