考虑使用 Policy.getPolicy() 的原因是什么，因为它将保留对上下文的静态引用并可能导致内存泄漏

Question

我刚刚读了一些来自 org.apache.cxf.common.logging.JDKBugHacks 的源代码，也在 http://svn.apache.org /viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java。为了让我的问题清楚，不要太宽泛。 :) 我只问其中的一段代码。

           // Calling getPolicy retains a static reference to the context 
            // class loader.
            try {
                // Policy.getPolicy();
                Class<?> policyClass = Class
                    .forName("javax.security.auth.Policy");
                Method method = policyClass.getMethod("getPolicy");
                method.invoke(null);
            } catch (Throwable e) {
                // ignore
            }

但我不明白这个评论。 “调用 getPolicy 保留对上下文类加载器的静态引用”。他们尝试使用 JDKBugHacks 来解决这个问题。

更新

我忽略了静态块部分。这里是。这是关键。实际上它已经缓存了策略。那么为什么还要缓存 contextClassLoader 呢？在评论中，它声称从 JDK 版本 1.4 开始@deprecated——被 java.security.Policy 取代。

我已经仔细检查了 java/security/Policy.java 的代码。它确实删除了缓存的类加载器。所以我的怀疑是有道理的！ :)

@Deprecated
public abstract class Policy {

    private static Policy policy;
    private static ClassLoader contextClassLoader;

    static {
        contextClassLoader = java.security.AccessController.doPrivileged
                (new java.security.PrivilegedAction<ClassLoader>() {
                public ClassLoader run() {
                    return Thread.currentThread().getContextClassLoader();
                }
        });
    };

我还添加了 getPolicy 源代码。

public static Policy getPolicy() {
    java.lang.SecurityManager sm = System.getSecurityManager();
    if (sm != null) sm.checkPermission(new AuthPermission("getPolicy"));
    return getPolicyNoCheck();
}
static Policy getPolicyNoCheck() {
    if (policy == null) {

        synchronized(Policy.class) {

            if (policy == null) {
                String policy_class = null;
                policy_class = java.security.AccessController.doPrivileged
                    (new java.security.PrivilegedAction<String>() {
                    public String run() {
                        return java.security.Security.getProperty
                            ("auth.policy.provider");
                    }
                });
                if (policy_class == null) {
                    policy_class = "com.sun.security.auth.PolicyFile";
                }

                try {
                    final String finalClass = policy_class;
                    policy = java.security.AccessController.doPrivileged
                        (new java.security.PrivilegedExceptionAction<Policy>() {
                        public Policy run() throws ClassNotFoundException,
                                            InstantiationException,
                                            IllegalAccessException {
                            return (Policy) Class.forName
                                    (finalClass,
                                    true,
                                    contextClassLoader).newInstance();
                        }
                    });
                } catch (Exception e) {
                    throw new SecurityException
                            (sun.security.util.ResourcesMgr.getString
                            ("unable to instantiate Subject-based policy"));
                }
            }
        }
    }
    return policy;
}

事实上，我深入挖掘，发现了一些有趣的事情。最近有人向 apache CXF 报告了关于这段代码的 org.apache.cxf.common.logging.JDKBugHacks 的错误。

为了禁用 url 缓存，JDKBugHacks 运行：

URL url = new URL("jar:file://dummy.jar!/");
URLConnection uConn = url.openConnection();
uConn.setDefaultUseCaches(false);

当设置了 java.protocol.handler.pkgs 系统属性时，在特定情况下可能会导致系统类加载器和文件协议处理程序之间出现死锁（例如，如果文件协议 URLStreamHandler 为一个signleton）。 除此之外，上面的代码实际上只是为了将 defaultUseCaches 设置为 false，因此可以避免实际打开连接，以加快执行速度。

所以修复是

URL url = new URL("jar:file://dummy.jar!/");
URLConnection uConn = new URLConnection(url) { 
@Override 
public void connect() throws IOException { 
 // NOOP
 } 
}; 
uConn.setDefaultUseCaches(false);

JDK 或 apache cxf 有一些小错误是正常的。通常他们会修复它。 javax.security.auth.login.Configuration 与策略有相同的问题，但并未弃用。

Answer 1

java 6中的Policy类包含对类加载器的静态引用，该类加载器在第一次访问该类时初始化为当前线程上下文类加载器：

private static ClassLoader contextClassLoader;

static {
contextClassLoader =
    (ClassLoader)java.security.AccessController.doPrivileged
            (new java.security.PrivilegedAction() {
            public Object run() {
                return Thread.currentThread().getContextClassLoader();
            }
    });
};

Tomcats生命周期侦听器确保从上下文类加载器所在的已知环境中初始化此类设置为系统类加载器。如果此类首先从 web 应用程序内访问，它将保留对 web 应用程序类加载器的引用。这将阻止 webapps 类被垃圾收集，从而造成永久代空间的泄漏。