這是一本相當不錯的書，理解相當深入。
性能相關的一些使用技巧：
1） 異常
2） 類型轉化
3） 重複取值（同原來用友.net性能分析報告）
集合：
1） set,list,map
2） Vector
3） Hashtable(去掉？？)
A. 本地/遠程問題
ü 本地/遠程透明度的實現途徑（4個階段，基於消息有ESB書中說明）
第3個階段：RPC，
RMI（JAVA）遠程方法調用（RMI傳輸協議（RTP）控制在客戶端和服務器的JVM實例（進程）之間的TCP連接上信息流。RTP建立在HTTP和對象序列化協議之上。
企業級JAVA BEAN擴展了RMI模型，RTP協議不支持健壯的企業服務器要求的事務和安全上下文的傳播。還添加了公共對象請求代理系統結構（CORBA）的互操作性。
ü 如何選擇遠程訪問模型
ü 對象粒度
粗粒度的業務對象比細粒度的業務對象更能承受方法調用的開銷。粗粒度“包裝”對象把大部分工作都委託給中間件（RDB/CICS）和現存的過程（COBOL和C）代碼。
粒度的理解，這是一個相對的術語，取決於上下文。如果訪問對象的開銷比對象工作的開銷大，那麼業務對象的粒度就過小，如果很難擴展或者重用作爲較大應用程序一部分的對象，那麼業務對象的粒度就過大了。根據這個定義，對象的相對粒度取決於本地和遠程調用的頻率，以及設計是否知合於當前和未來的需求。
ü 正確放置數據
對象的親合力（就是域的設計，域的定義等）
B. 粒度
接口粒度
實現粒度
什麼？？（平衡，頻繁交互還是大粒度DTO傳輸，複式接口）
關於性能的例子
C. 瓶頸
ü 同步瓶頸
濫用同步；使用非同步方法以達到需求，自己定義的同步等；
ü 加鎖瓶頸
同步和鎖的關係，事務與鎖的關係；P100，
JAVA同步對於確保單個實例的原子更新是有用的，但是業務應用程序需求執行一系列相關更新的事務行爲。事務行爲通常與業務邏輯和持久性有關。涉及多個對象的複雜更新必須整體完成或者被重新設置到初試狀態上（回滾）。
ü 垃圾回收瓶頸
垃圾回收的時間佔據了工作量的大部分。（總量）
垃圾回收的間歇時間對響應時間有影響。（什麼是間歇時間？？）
垃圾收集器阻止應用程序有效地使用系統資源。（同步）
垃圾收集器在分佈式應用程序中創建串行化點。
分佈式垃圾回收：對象又是如何維護的啊？這裏涉及到服務器端對象的生命週期的管理模式（好像都不適用啊？）
維護會話數據需要HTML文本和客戶端瀏覽器之間有額外的數據流。
技術有：
a) 隱藏html形式的域；
b) Cookies
c) URL重寫
d) Servlet會話