這里將要講述的是一系列的類似案例，都是在各個產品進行performance tuning時被發現的，非常具有普適性。可以說在日常開發中，有非常大的概率遇到相同或者類似的情形，因此需要對其保持警惕以便避免陷入類似的性能問題。
我們從JAXBContext這個對象開始，JAXBContext 是JAXB API的入口，典型的代碼實現如下：
private void unmarshal() {
JAXBContext context = JAXBContext.newInstance(DirectoryConstants.JAXB_CONTEXT_CLASS);
Unmarshaller u = context.createUnmarshaller();
Object obj = u.unmarshall(...);
}
這個是標準使用流程了，首先初始化JAXBContext對象，通過JAXBContext對象創建Unmarshaller對象，然后使用Unmarshaller對象來進行unmarshal操作。
這個寫法在功能實現上沒有任何問題，但是如果一旦進行壓力測試，就會暴露性能問題。JAXBContext對象的初始化是個資源消耗非常大的操作，我們可以通過threaddump進行分析，會發現很多工作線程都在執行JAXBContext.newInstance()這個方法，而不是我們期待的u.unmarshal(）。而事實上JAXBContext對象的Sun實現是線程安全的，即容許多線程同時調用一個JAXBContext對象的createUnmarshaller()，因此完全沒有必要為每個xml的 marshaling 和 unmarshalling 操作去初始化一次JAXBContext對象。可以參考這里的說明：https://jaxb.dev.java.net/faq/index.html#threadSafety
簡單點說，這個一個初始化代價昂貴，卻又可重復使用的對象。
因此，我們只需要初始化JAXBContext對象一次并保存起來，然后重復使用這個JAXBContext對象即可。保存JAXBContext對象的方式可以有很多種，比如cache / threadlocal，或者使用一個單例來維持這個對象。比如下面的代碼示例：
private void unmarshal() {
JAXBContext context = JAXBContextHolder.get();
...
}
public class JAXBContextHolder {
private static final JAXBContext instance = JAXBContext.newInstance(DirectoryConstants.JAXB_CONTEXT_CLASS);
public static JAXBContext get() {
return instance;
}
}
在實際項目中， 通過上面的簡單改進之后，我們當時得到了一個非常巨大的回報：TPS (transactions per second 每秒事務處理量)直接*3 ！！
這個案例從技術上講非常的簡單，道理很淺顯，相信每個人都能輕松理解。或者說，這是一個“知道了就簡單，不知道就容易犯錯而不自知”的地方，因此依然有些東西需要注意：
(1) 有哪些對象有類似的特性
目前發現的類似對象有
1. 剛剛上面講到的JAXB API中的 JAXBContext 對象
2. SOAP API中的javax.xml.soap.SOAPFactory
3. CFX client
通常情況下，在使用各種api或者工具類庫時，如果發現調用代碼中有類似的初始化語句，都應該稍加注意(除非明確當前代碼對性能完全沒有要求)，可以去查一下這個類對象的javdoc或者直接看源碼，如果發現滿足上面所說的特性，則應該考慮進行上述的性能優化。
根據經驗，類似的初始化對象通常的命名規則都是***Context/***Factory之類，或者***client，遇到類似名字時需要提高警惕。
（2）假設問題已經存在，如果才能在performance tuning中迅速發現問題的代碼?
通常的辦法就是用thread dump，一般連續dump個3-5次，然后通過分析thread dump信息 （推薦使用eclipse插件 lockness），看當前請求的線程（通常是一個線程池)都在干什么。一般初始化昂貴都昂貴在類似文件IO操作或者加鎖之類的地方，很容易在thread dump中被發現。