《Effective.Enterprise.Java中文版》知识点摘要
《Effective.Enterprise.Java中文版》本書最重要的部分是：理解企業級計算技術中的常規問題和使用企業級JAVA平臺技術來處理這些問題。.
?
語言和API也許會發生變化，但是你將會理解：構建良好架構所要考慮的問題；有那些通信方式可供選擇；如何選擇狀態存儲的位置；各式各樣的安全問題等等這些思想性的東西不會變。
?
資源管理：線程、數據庫連接、套接字、文件，所有這些資源比堆內存來說要更難于管理。他們的是生命周期存活于JAVA虛擬機之外，并且需要以一種對并發使用來說友好的方式來被獲取和被釋放。
?
企業計算的十大謬誤
參考P23
?
Web應用是一系列資源，比如servlet、jsp、模型類、工具類、以及靜態資源（HTML、圖像、聲音文件等），它們共同地相互協作以提供所需功能。Web應用采用單一的.war文件部署，所以不可能出現：只部署了部分應用或應用的各個部件之間的版本不匹配。
?
當你為企業級應用和系統規劃基本流程和設計的時候，牢記以下項中包含的建議，你就能向優雅的目標邁進：建立一個能夠對高性能、高擴展性的企業級系統提供支撐的架構。
第1項：優先采用構件作為開發、部署和重用的核心元素。
第2項：跨越構件邊界優先采用松耦合。
第3項：區分邏輯層和物理層。
第4項：數據和處理程序要盡可能靠近。
第5項：牢記標識引起的競爭。
第6項：使用“掛鉤點”來注入優化、定制或新功能。
第7項：面對故障時要健壯。
第8項：定義性能和可擴展性目標。
第9項：只在事務性處理中使用EJB。
第10項：先測量性能，再進行優化。
80/20規則，它是計算機科學領域里最知名的規律之一，其最常見的形式有：20%的代碼使用了80%的系統資源，20%的代碼占用了80%的運行時間，20%的代碼占用了80%的內存，80%的需求文檔只覆蓋了20%的必要工作等等。
第11項：認清“提供商中立”的成本。
第12項：內置監控功能。
“心跳”進程監控錯誤與保存日志信息。
在不運行調試器的情況下，要調試serlet或EJB時，日志信息越多越好。
第13項：內置管理支持。
第14項：部署要盡可能簡單。
第15項：理解你所做的通信選擇。
進程通信方式：RPC和消息傳送；遠程方法調用（RMI）；公用對象請求代理程序架構（CORBA）；Servlet(servlet與xml有效負載結合直接進入Web Sservice領域);Java消息服務（JMS）(JMS與xml有效負載結合將你帶入Web Sservice領域)；Jini（最顯著的思想是自我修復網絡和服務發現）；JXTA；用于XML的Java API（JAX—RPC）；用于XML消息傳遞的Java API（JAXM）。
上面中任何一個都能最終完成這項工作——將數據從機器A轉移到機器B。很明顯決策必須根植于某種事物，如果你的系統通信要發生在特定環境之上，請考慮下面的問題：
1）、你需要跨越防火墻的通信嗎？防火墻他們不允許在任意TCP/IP端口上有進入的流量，而這正是RMI和CORBA都要使用的。
2）、你需要同步通信嗎？如果你的通信模式大多是請求——響應模式，RPC肯定上首選的通信模式。
3）、你需要能夠和任何平臺進行通信嗎？包括那些你并不很了解的平臺？Web服務可以在所有平臺之間創建一個“中間地帶”，因為XML的無處不在。
第16項：仔細考慮你的查找。
在分布式系統中有多種形式的透明：訪問（隱藏數據表示的不同，以及一個資源如何被訪問）、位置（隱藏一個資源被定位在哪里）、遷移（隱藏一個資源可以被移動到另一位置）、重定位（隱藏一個資源可以在運行時移動到另一位置）、復制（隱藏一個資源的復制）、并發（隱藏一個資源可以被多個競爭用戶分享）、失敗（隱藏一個資源的失敗和恢復）、持久性（隱藏一個軟件資源是在內存中還是在硬盤上）。
第17項：識別網絡訪問的代價。
第18項：優選上下文完整的通信風格。
第19項：優選數據驅動的通信而不是行為驅動的通信。
第20項：避免為遠程服務請求去等待響應。
第21項：考慮構件的劃分以避免任何一臺機器負載過重。
分布式系統、DNS
第22項：為了開放集成而考慮使用Web服務。
XML+HTTP
第23項：大批量地傳送數據。
傳送的塊狀數據要足夠大以適應遠程調用的開銷。不要一次傳送一個，而是大批量傳送：以完整的對象塊，或者對象集的形式。這正是IBM/BEA的服務數據對象（Service Data Object）解決方案的基本思想，并且可以論證這只比過程優先的持久層差一點。
批量地傳送數據也有一些局限性——不斷地在網絡上傳送大量數據并不多次往返好多少，因為你現在正在吸干網絡帶寬，并強制通信層花費相當大的力氣來編組、發送、接收、以及反編組數據。你還要基于客戶端將怎樣使用（或不使用）某一個特大的數據項，來判斷它是按引用傳送還是按值傳送更好；尤其要注意集合和可序列化對象。
第24項：考慮定制你自己的通信代理。
第25項：保持簡潔。
代碼保持簡潔
第26項：優先采用規則引擎去處理復雜狀態的評估和執行。
規則引擎通常服務于兩個目的：（1）以最好的方式捕獲業務規則（2）允許修改這些規則而不需要重新編碼Java代碼本身。
任何書寫規則引擎能夠理解的“規則語言”，有幾種不同的實現：一種是開源的實現，叫做drools，可以從http;//www.codehaus.org上獲得；BEA也包含了一種實現，并將其作為WebLogic平臺的一部分，ILOG也在銷售一種用來整合其它服務器的第三方的引擎。JSR94定義了標準的API用于連接規則引擎；它的參考實現叫做Java專家系統外殼，可以免費用于非贏利目的。
第27項：優先為隱含的非原子性錯誤場景采用事務性處理。
第28項：區分用戶事務和系統事務。
第29項：最小化鎖窗口
作為一條規則，在被同步的區域內，你應該盡可能少的操作。
第30項：當持有鎖時不要讓步給在構件之外的控制。
為了你自己，在執行任何構件外的通信之前，請確保所有的鎖是釋放的。
第31項：理解EJB的事務關聯。
第32項：優先使用本地事務而不是分布式事務。
第33項：為了更好的可擴展性而考慮使用樂觀的并發機制。
第34項：為了顯式的并發控制而考慮使用悲觀的并發機制。
第35項：考慮使用較低的隔離級別以獲得更大的事務吞吐量。
第36項：面臨回滾時使用保存點來保留部分工作。
第37項：當有可能避免鎖定區域時就復制數據源。
第38項：偏愛不可變的，因為它不需要任何鎖。
第39項：節省地使用HttpSession
第40項：使用對象優先的持久化來保存你的領域模型。
第41項：使用關系優先的持久化來顯示關系模型的威力。
第42項：使用過程優先的持久化來創建一個封裝層。
第43項：識別對象—層次結構的阻抗失配。
第44項：使用進程內或本地存儲以避開網絡。
第45項：不要假設擁有數據或數據庫。
第46項：惰性加載不頻繁使用的數據。
第47項：積極載入頻繁使用的數據。
第48項：批處理SQL的工作以避免往返訪問。
第49項：了解你的JDBC供應商。
第50項：調整你的SQL語句。
第51項：考慮富客戶端UI技術。
HTML/DHTML、Flash/Flex、Applets、URLClassLoader類、JNLP和Java Web Start
第52項：使HTML短小精悍。
第53項：表示與處理分離。
第54項：內容與樣式相分離。
第55項：預生成內容以最小化處理過程。
第56項：盡早驗證、盡量驗證。
第57項：安全是一個過程，而不是產品。
第58項：記住安全不僅僅是預防
第59項: 建立威脅模型
第60項：作不安全假設
第61項:總是驗證用戶的輸入
第62項：打開平臺安全機制
第63項：使用基于角色的授權
第64項：使用SignedObject以保證序列化對象的完整性
第65項：使用SealedObject以保證可序列化對象的機密性
第66項：使用GuardedObject以保證對象的存取控制
第67項：主動釋放資源
第68項：調整JVM
第69項：為版本并存使用獨立的JRE
第70項：識別類加載器的邊界
隔離、版本控制
第71項：理解Java的對象序列化
SerialVerUID域、自定義（writeObject和readObject）、 替換（writeReplace和readResolve）
第72項：不要對抗垃圾收集器
第73項：優選容器管理的資源管理
第74項：使用Reference對象來擴展垃圾收集行為
?SoftReference 對象 、WeakReference對象 、PhantomReference對象
第75項：不要擔心在服務器上的JNI代碼
?
轉載于:https://www.cnblogs.com/ajian005/archive/2012/10/28/2753653.html
總結
以上是生活随笔為你收集整理的《Effective.Enterprise.Java中文版》知识点摘要的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 服务器教程笔记
- 下一篇： Java 关于中文乱码处理的经验总结