在重现这个问题的时候,我构建了下面这个小的测试用例来让大家更好地理解下这个锁的问题。这个示例启动了100个线程来加载javax.xml.parsers.DocumentBuilder这个类:
package eu.plumbr.demo;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
public class ClassloadingLock {
static class Worker extends Thread {
@Override
public void run() {
while (true) {
try {
DocumentBuilder b = DocumentBuilderFactory.newInstance()
.newDocumentBuilder();
} catch (Exception e) {// Do not do this at home, log all
// exceptions
}
}
}
}
public static void main(String[] args) throws Exception {
for (int i = 0; i < 100; i++) {
new Worker().start();
}
}
}
  在运行上述这段代码的时候做一下thread dump,或者用jvisualvm进行下可视化,你会发现这些线程会不停地等待这个监视器:
  这个故事告诉了我们什么呢?查找这个性能问题的其实不应该这么麻烦。我们开发的这些工具提供了许多更便利的手段来对你的JVM进行监视及检测,因此定位这类问题不再需要掌握这么多技术才能完成了。