Path: blob/master/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
41152 views
/*1* Copyright (c) 2001, 2012, Oracle and/or its affiliates. All rights reserved.2* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.3*4* This code is free software; you can redistribute it and/or modify it5* under the terms of the GNU General Public License version 2 only, as6* published by the Free Software Foundation.7*8* This code is distributed in the hope that it will be useful, but WITHOUT9* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or10* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License11* version 2 for more details (a copy is included in the LICENSE file that12* accompanied this code).13*14* You should have received a copy of the GNU General Public License version15* 2 along with this work; if not, write to the Free Software Foundation,16* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.17*18* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA19* or visit www.oracle.com if you need additional information or have any20* questions.21*/2223/* @test24* @bug 4404702 821652825* @summary When the RMI runtime (lazily) spawns system threads that could26* outlive the application context in which they were (happened to be)27* created, such threads should not inherit (thread local) data specific to28* such an application context for various isolation reasons (see 4219095).29* While there is not yet a practical means for a general solution to this30* problem, the particular problem documented in 4404702-- the inheritance31* of the parent thread's context class loader, preventing that loader from32* being garbage collected in the future-- can be easily fixed. This test33* verifies that the context class loader in effect when the first remote34* object is exported (and thus when some long-lived RMI daemon threads are35* created) can be garbage collected after the remote object has been36* unexported. [Note that this test is somewhat at the mercy of other J2SE37* subsystems also not holding on to the loader in their daemon threads.]38* @author Peter Jones39*40* @build RuntimeThreadInheritanceLeak_Stub41* @run main/othervm RuntimeThreadInheritanceLeak42*/4344import java.lang.ref.Reference;45import java.lang.ref.ReferenceQueue;46import java.lang.ref.WeakReference;47import java.net.URL;48import java.net.URLClassLoader;49import java.rmi.Remote;50import java.rmi.RemoteException;51import java.rmi.server.UnicastRemoteObject;52import java.util.Iterator;53import java.util.Map;5455public class RuntimeThreadInheritanceLeak implements Remote {5657private static final int TIMEOUT = 20000;5859public static void main(String[] args) {6061System.err.println("\nRegression test for bug 4404702\n");6263/*64* HACK: Work around the fact that java.util.logging.LogManager's65* (singleton) construction also has this bug-- it will register a66* "shutdown hook", i.e. a thread, which will inherit and pin the67* current thread's context class loader for the lifetime of the VM--68* by causing the LogManager to be initialized now, instead of by69* RMI when our special context class loader is set.70*/71java.util.logging.LogManager.getLogManager();7273/*74* HACK: Work around the fact that the non-native, thread-based75* SecureRandom seed generator (ThreadedSeedGenerator) seems to76* have this bug too (which had been causing this test to fail77* when run with jtreg on Windows XP-- see 4910382).78*/79(new java.security.SecureRandom()).nextInt();8081RuntimeThreadInheritanceLeak obj = new RuntimeThreadInheritanceLeak();8283try {84ClassLoader loader = URLClassLoader.newInstance(new URL[0]);85ReferenceQueue refQueue = new ReferenceQueue();86Reference loaderRef = new WeakReference(loader, refQueue);87System.err.println("created loader: " + loader);8889Thread.currentThread().setContextClassLoader(loader);90UnicastRemoteObject.exportObject(obj);91Thread.currentThread().setContextClassLoader(92ClassLoader.getSystemClassLoader());93System.err.println(94"exported remote object with loader as context class loader");9596loader = null;97System.err.println("nulled strong reference to loader");9899UnicastRemoteObject.unexportObject(obj, true);100System.err.println("unexported remote object");101102/*103* HACK: Work around the fact that the sun.misc.GC daemon thread104* also has this bug-- it will have inherited our loader as its105* context class loader-- by giving it a chance to pass away.106*/107Thread.sleep(2000);108while (loaderRef.get() != null) {109System.gc();110Thread.sleep(100);111}112113System.err.println(114"waiting to be notified of loader being weakly reachable...");115Reference dequeued = refQueue.remove(TIMEOUT);116if (dequeued == null) {117System.err.println(118"TEST FAILED: loader not deteced weakly reachable");119dumpThreads();120throw new RuntimeException(121"TEST FAILED: loader not detected weakly reachable");122}123124System.err.println(125"TEST PASSED: loader detected weakly reachable");126dumpThreads();127128} catch (RuntimeException e) {129throw e;130} catch (Exception e) {131throw new RuntimeException("TEST FAILED: unexpected exception", e);132} finally {133try {134UnicastRemoteObject.unexportObject(obj, true);135} catch (RemoteException e) {136}137}138}139140/**141* Dumps information about all live threads to System.err,142* including their context class loaders.143**/144private static void dumpThreads() {145System.err.println(146"current live threads and their context class loaders:");147Map threads = Thread.getAllStackTraces();148for (Iterator iter = threads.entrySet().iterator(); iter.hasNext();) {149Map.Entry e = (Map.Entry) iter.next();150Thread t = (Thread) e.getKey();151System.err.println(" thread: " + t);152System.err.println(" context class loader: " +153t.getContextClassLoader());154StackTraceElement[] trace = (StackTraceElement[]) e.getValue();155for (int i = 0; i < trace.length; i++) {156System.err.println(" " + trace[i]);157}158}159}160}161162163