在调用getDeclaredConstructors方法时，线程出现阻塞的可能原因有哪些？

Question

在调用getDeclaredConstructors方法时，线程出现阻塞的可能原因有哪些？

8

针对我们应用程序的某个安装，我们在生产环境中发现了一些问题，用户报告说“系统变慢”或“请求无法返回”。最终，服务器不得不重新启动。我们遇到了几次这样的事故，并且每晚重启服务器似乎是一个可行的解决方法。

我们的应用程序广泛使用动态类加载（在数据库中存储为blob的.jar文件）和反射。

环境详细信息：

- Java 1.7.021 - 操作系统：Linux（2.6.32-504.16.2.el6.x86_64） - JBoss EAP 6.2 - 正在使用 Appdynamics - 内存和GC设置：-XX:PermSize=256m -XX:MaxPermSize=2560m -Xms2048m -Xmx10240m -server -XX:+UseParallelGC -XX:+UseParallelOldGC

我们已经切换到:

- Java 1.7.080 - -XX:+UseG1GC

但看起来我们仍然面临同样的问题。

目前在日志文件、堆转储文件、线程转储文件和GC日志中看到的情况如下：

- 我们没有看到任何OutOfMemory错误 - 堆和PermGend的内存消耗似乎还可以（堆和Perm gen未被充分使用） - 在Java 1.7.021和parallelGC下，我们看到了一些长时间运行（5分钟）的Full GC，但在切换到G1GC后不再发生（这是我们预期的） - 我们没有看到与CodeCache满相关的警告日志

我们看到的情况是：

- 对于某些事件，堆转储文件中DelegatingClassLoaders的数量约为5000，对于其他事件，则约为100,000。 - 用户最初报告系统变慢后，处于RUNNABLE状态并且正在处理“getDeclaredConstructors0”的线程数量正在增加（从一开始的两个增至大约50）。该线程似乎在同一个位置“挂起”（处于RUNNABLE状态）多个小时。

以下是线程转储文件的摘要：

"http-xxx:8443-141" daemon prio=10 tid=0x00007efe9412f000 nid=0x64fb runnable [0x00007efe1ba8a000]
   java.lang.Thread.State: RUNNABLE
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
    at java.lang.Class.getConstructor0(Class.java:2723)
    at java.lang.Class.newInstance0(Class.java:345)
    at java.lang.Class.newInstance(Class.java:327)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
    at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:77)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:46)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    [application code]

"http-xxx:8443-138" daemon prio=10 tid=0x00007efe9412a000 nid=0x64ed runnable [0x00007efe1c397000]
   java.lang.Thread.State: RUNNABLE
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
    at java.lang.Class.getConstructor0(Class.java:2723)
    at java.lang.Class.newInstance0(Class.java:345)
    at java.lang.Class.newInstance(Class.java:327)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
    at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:77)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:46)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.mvel2.PropertyAccessor.set(PropertyAccessor.java:350)
    at org.mvel2.PropertyAccessor.set(PropertyAccessor.java:134)
    at org.mvel2.MVEL.setProperty(MVEL.java:1088)   
    [application code]

更新到Java 1.7.80 / G1Gc后的情况似乎是类似的。不幸的是，没有线程转储可用，日志中只有Wicket警告。

2016-03-10 15:00:39,009 WARN  [http-xxx:7443-23] org.apache.wicket.page.PageAccessSynchronizer: Thread 'http-xxx:7443-23' failed to acquire lock to page with id '28', attempted for 3 minutes out of allowed 3 minutes. The thread that holds the lock has name 'http-xxx:7443-18'.
2016-03-10 15:00:39,017 WARN  [http-xxx:7443-23] org.apache.wicket.page.PageAccessSynchronizer: "http-xxx:7443-18" daemon prio=5 tid=8950 state=RUNNABLE 
org.apache.wicket.util.lang.Threads$ThreadDump
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2595)
    at java.lang.Class.getConstructor0(Class.java:2895)
    at java.lang.Class.newInstance(Class.java:354)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
    at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:113)
    at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:331)
    at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1376)
    at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:72)
    at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:493)
    at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:468)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:468)
    at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1133)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
    [application code]

2016-03-10 15:04:14,640 WARN  [http-xxx:7443-16] org.apache.wicket.page.PageAccessSynchronizer: Thread 'http-xxx:7443-16' failed to acquire lock to page with id '11', attempted for 3 minutes out of allowed 3 minutes. The thread that holds the lock has name 'http-xxx:7443-38'.
2016-03-10 15:04:14,642 WARN  [http-xxx:7443-16] org.apache.wicket.page.PageAccessSynchronizer: "http-xxx:7443-38" daemon prio=5 tid=9088 state=RUNNABLE 
org.apache.wicket.util.lang.Threads$ThreadDump
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2595)
    at java.lang.Class.getConstructor0(Class.java:2895)
    at java.lang.Class.newInstance(Class.java:354)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
    at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:77)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:46)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606) 
    [application code]

我们目前无法重现这个问题（仍在努力解决）。但也许社区中的某些人已经看到了类似的情况，并且有想法可以帮助我们重现或解决这些问题。我们目前猜测这可能与本地内存消耗有关（因为像http://www.ibm.com/developerworks/java/library/j-nativememory-linux/这样的信息），但是我们在日志中没有看到任何相关的提示（没有OutOfMemory错误，也没有来自Linux管理员的报告说系统内存不足）。

- Kai

Java序列化并不是非常高效，而且它经常使用反射。如果你频繁调用它，它会成为一个瓶颈。可能这个方法是单线程的，所以当一个线程在使用它时，所有其他线程都必须等待。 - Peter Lawrey

这真是太神奇了，即使只是在每个ObjectOutputStream上写入类，它也会为每个类构建一个构造函数。如果你有很多类，在每个流中都会花费更长的时间。 - Peter Lawrey

我肯定会先从方程中移除Appdynamics；对字节码进行仪器化可能会引起问题。 - user2023577

你说得对。我猜这就是客户最终所做的。我已经添加了一个答案并标记为已解决。 - Kai

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Kai · Accepted Answer

我们从未能够妥善解决这个问题，但在某个时候它消失了。如果我没有记错，其中一个客户端更改了appdynamics配置/删除了它，似乎解决了这个问题。