一段时间以来， Apache Xalan中存在一个令人尴尬的错误，该错误是XALANJ-2540 。 此错误的后果是Xalan每次XPath表达式求值将内部SPI配置文件加载数千次 ，可以很容易地进行如下测量：

这个：

Element e = (Element)document.getElementsByTagName("SomeElementName").item(0);
String result = ((Element) e).getTextContent();

似乎比这快100倍：

// Accounts for 30%, can be cached
XPathFactory factory = XPathFactory.newInstance();// Negligible
XPath xpath = factory.newXPath();// Negligible
XPathExpression expression =xpath.compile("//SomeElementName");// Accounts for 70%
String result = (String) expression.evaluate(document, XPathConstants.STRING);

可以看出，每10k测试XPath评估中的每一项都导致类加载器试图以某种默认配置查找DTMManager实例。 此配置不会加载到内存中，但每次都会访问。 此外，此访问似乎受到ObjectFactory.class本身上锁的保护。 当访问失败时（默认情况下），将从xalan.jar文件的配置文件中加载配置：

META-INF/service/org.apache.xml.dtm.DTMManager

每次！ ：

关于Xalan的分析会议

幸运的是，可以通过指定以下JVM参数来覆盖此行为：

-Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault

要么

-Dcom.sun.org.apache.xml.internal.dtm.DTMManager=com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault

上面的方法可以正常工作，因为如果工厂类名称仍然是默认名称，则这将绕过lookUpFactoryClassName（）中的昂贵工作：

// Code from c.s.o.a.xml.internal.dtm.ObjectFactory
static String lookUpFactoryClassName(String factoryId,String propertiesFilename,String fallbackClassName) {SecuritySupport ss = SecuritySupport.getInstance();try {String systemProp = ss.getSystemProperty(factoryId);if (systemProp != null) { // Return early from the methodreturn systemProp;}} catch (SecurityException se) {}// [...] "Heavy" operations later

资源资源

上面的文字摘录自我不久前向公众提供的堆栈溢出问题和答案 。 我将其再次发布在我的博客上，以便可以提高社区对于这个相当严重的错误的认识。 请随意在这张票上投票，因为地球上的每个Sun / Oracle JDK都会受到影响： https : //issues.apache.org/jira/browse/XALANJ-2540

当然，向Apache贡献修复程序会更好。

翻译自: https://www.javacodegeeks.com/2013/09/how-to-speed-up-apache-xalans-xpath-processor-by-factor-10x.html