xalan

一段時間以來， 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貢獻修復程序會更好。

參考： 如何通過我們的JCG合作伙伴 Lukas Eder在JAVA，SQL和JOOQ博客上通過因子10x加速Apache Xalan的XPath處理器 。

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

xalan

總結

以上是生活随笔為你收集整理的xalan_如何以10倍速加速Apache Xalan的XPath处理器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。