WebSphere设为Parent_Last模式后Servlet应用静态变量取值为null

你遇到的静态变量读取为null的现象，和调整WebSphere为Parent_Last类加载模式的操作高度相关，本质是同一个类被不同类加载器重复加载，导致静态变量存储空间完全隔离。

机制说明：Parent_Last模式下，应用类加载器会优先从自身的WEB-INF路径加载类，而非先委托WebSphere的父类加载器。如果系统内存在多份可加载到ConfigUtils类的路径，就会生成两份完全独立的Class对象——每一份Class都有自己独立的静态变量内存空间，互相读写完全隔离。
对应你的场景的具体流程：你调试时断点命中的ConfigUtils实例，来自第一份被某个类加载器加载的Class，构造方法执行完成后，该类对应的静态变量确实被成功赋值；但后续业务代码读取的是另一个类加载器加载的同名ConfigUtils类，这份Class从未被实例化过，静态变量保持JVM默认的null初始值，调用get方法时就会直接触发空指针。

• 第一优先级：验证是否存在重复类加载
  • 全量排查所有可能加载ConfigUtils类的路径：包括WEB-INF/classes目录、WEB-INF/lib下的所有依赖jar、WebSphere配置的服务器级共享库、其他同部署应用的公共类路径，确认是否存在多份同名的ConfigUtils.class
  • 快速验证方法：分别在ConfigUtils的构造方法内、和触发空指针的静态变量读取位置，加日志输出ConfigUtils.class.getClassLoader()的对象全路径，如果两处输出的类加载器不一致，即可实锤是类加载隔离导致的问题
• 修正现有静态变量的初始化反模式
  • 当前依赖实例构造方法给静态变量赋值的写法本身存在设计缺陷：静态变量是类维度的全局状态，靠实例构造方法赋值意味着只要类被加载后没有实例被创建，静态变量就会保持null；如果存在多份Class对象，还会出现“实例给A份静态变量赋值，业务代码读B份静态变量”的错位问题
  • 调整方案：把静态变量的初始化逻辑挪到类静态代码块中，或在变量声明时直接完成初始化，让类被加载的过程就自动完成静态变量赋值，完全不依赖任何实例化动作
• 类加载模式的适配调整
  • 临时回退WebSphere的类加载模式为Parent_First，重新部署验证：如果回退后空指针问题消失，即可100%确认是Parent_Last模式触发的类隔离问题
  • 如果业务必须保留Parent_Last模式，需要梳理所有ConfigUtils类的加载路径，确保所有引用该类的代码都从同一份Class路径加载，避免重复加载带来的静态变量隔离
• 规避其他同类风险
  • 即使没有类加载的问题，在构造方法中操作静态字段也存在并发时序隐患：多线程并发实例化ConfigUtils时，可能出现静态变量被多次覆盖、初始化流程未完成就被其他线程读取的问题；静态代码块的初始化过程由JVM保证线程安全，可靠性远高于实例构造方法赋值。

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