Java

多線程環境下的程式調試是讓開發人員頭痛的問題。在 IDE 中通過添加斷點的 方式偵錯工具，往往會因為停在某一條線程的某個斷點上而錯失了其他線程的執 行，線程之間的調度往往無法預期，並且會因為斷點影響了實際的線程執行順序 。因此，在調試多線程程式時，開發人員往往會選擇列印 Trace Log 的方式來幫 助調試。使用 Log 來協助調試的問題在於，開發人員往往無法預期哪些關鍵點需要記錄 ，於是在整個程式的調試過程中，需要不斷的加入 Log 調用，編譯產生可執行

關於在 Java 語言中使用異常的大多數建議都認為，在確信異常可以被捕獲 的任何情況下，應該優先使用檢查型異常。語言設計（編譯器強制您在方法簽名 中列出可能被拋出的所有檢查型異常）以及早期關於樣式和用法的著作都支援該 建議。最近，幾位著名的作者已經開始認為非檢查型異常在優秀的 Java 類設計 中有著比以前所認為的更為重要的地位。在本文中，Brian Goetz 考察了關於使 用非檢查型異常的優缺點。與 C++ 類似，Java 語言也提供異常的拋出和捕獲。但是，與 C++ 不一樣的

ConcurrentHashMap 是 Doug Lea的 util.concurrent 包的一部分，它提供 比Hashtable 或者 synchronizedMap 更高程度的並發性。而且，對於大多數成 功的 get() 操作它會設法避免完全鎖定，其結果就是使得並發應用程式有著非 常好的輸送量。這個月，BrianGoetz 仔細分析了 ConcurrentHashMap的代碼， 並探討 Doug Lea 是如何在不損失安全執行緒的情況下取得這麼驕人成績的。在7月份的那期

這個月，我著手撰寫一篇文章，分析一個寫得很糟糕的微評測。畢竟，我們 的程式員一直受效能困擾，我們也都想瞭解我們編寫、使用或批評的代碼的效能 特徵。當我偶然間寫到效能這個主題時，我經常得到這樣的電子郵件：“我寫的 這個程式顯示，動態 frosternation 要比靜態 blestification 快，與您上一 篇的觀點相反!”許多隨這類電子郵件而來的所謂“評測“程式，或者它們運行 的方式，明顯表現出他們對於 JVM

當項目中需要 XML 解析器、文本索引程式和搜尋引擎、Regex編譯器、 XSL 處理器或 PDF 產生器時，我們中大多數人從不會考慮自己去編寫這些實用 程式。每當需要這些設施時，我們會使用商業實現或開放源碼實現來執行這些任 務原因很簡單 ― 現有實現工作得很好，而且便於使用，自己編寫這些公用程式 會事倍功半，或者甚至得不到結果。作為軟體工程師，我們更願意遵循艾薩克 ・牛頓的信念 ― 站在巨人的肩膀之上，有時這是可取的，但並不總是這 樣。（在 Richard Hamming 的

在Java類庫中出現的第一個關聯的集合類是 Hashtable ，它是JDK 1.0的一 部分。 Hashtable 提供了一種便於使用的、安全執行緒的、關聯的map功能，這當 然也是方便的。然而，執行緒安全性是憑代價換來的―― Hashtable 的所有方法 都是同步的。此時，無競爭的同步會導致可觀的效能代價。 Hashtable 的後繼 者 HashMap 是作為JDK1.2中的集合架構的一部分出現的，它通過提供一個不同 步的基類和一個同步的封裝器

不變對象是指在執行個體化後其外部可見狀態無法更改的對象。Java 類庫中的 String 、 Integer 和 BigDecimal 類就是不變對象的樣本 ― 它們表示在對象 的生命期內無法更改的單個值。不變性的長處如果正確使用不變類，它們會極大地簡化編程。因為它們只能處於一種狀態 ，所以只要正確構造了它們，就決不會陷入不一致的狀態。您不必複製或複製不 變對象，就能自由地共用和快取對它們的引用；您可以快取它們的欄位 或其方法的結果，而不用擔心值會不會變成失效的或與對象的其它狀態不一致。

不管正在構建的是 J2EE 還是 J2SE 伺服器應用程式，都有可能以某種方式 使用 Java Servlet —— 可能是直接地通過像 JSP 技術、Velocity 或者 WebMacro 這樣的展示層，也可能通過一個基於 servlet 的 Web 服務實現，如 Axis 或者 Glue。Servlet API 提供的一個最重要的功能是會話管理 —— 通過 HttpSession 介面進行使用者狀態的認證、失效和維護。工作階段狀態幾乎每一個

上個月，我們分析了引用計數、複製、標記-清除和標記-整理這些經典的垃 圾收集技術。其中每一種方法在特定條件下都有其優點和缺點。例如，當有很多 對象成為垃圾時，複製可以做得很好，但是有許多長壽對象時它就變得很糟（要 反覆複製它們）。相反，標記-整理對於長壽對象可以做得很好（只複製一次） ，但是當有許多短壽對象時就沒有那麼好了。JVM 1.2 及以後版本使用的技術稱 為 分代垃圾收集（generational garbage collection）,它結合了這兩種技術

Java之Vector的用法（一）：一般在需要將多個元素存在一個集合裡的時候用，幫住文檔裡的,看的懂的話就拿去吧,應該能滿足你了。java.util 類 Vector<E>boolean add(E o)將指定元素追加到此向量的末尾。void add(int index, E element)在此向量的指定位置插入指定的元素。boolean addAll(Collection<? extends E> c)將指定 Collection

摘要：與欄位和方法類似，Java允許類是其它類的成員。在這裡，我們將嵌套類分為4種--嵌套頂級類（nested top-level classes），成員內部類（instance inner classes），本地內部類（local inner classes）和匿名內部類（anonymous inner

使用者存取控制(Access control

在大多數情況下，Java 應用程式要麼是 J2EE 應用程式、要麼是 J2SE 應用 程式，並且在這一點上是涇渭分明的。J2EE 應用程式需要 J2EE 容器的服務， 容器要實現一長串的 J2EE API，包括 Enterprise JavaBean (EJB)、JTA、JNDI 、JMS、JCA 和 JMX。J2EE API 設計為協同工作；畢竟，J2EE 設計是從多年來 數百人開發公司專屬應用程式程式的經驗中提取出的公用需求。像所有架構一樣，J2EE API

自從泛型被添加到 JDK 5 語言以來，它一直都是一個頗具爭議的話題。一部 分人認為泛型簡化了編程，擴充了類型系統從而使編譯器能夠檢驗型別安全；另 外一些人認為泛型添加了很多不必要的複雜性。對於泛型我們都經曆過一些痛苦 的回憶，但毫無疑問萬用字元是最棘手的部分。萬用字元基本介紹泛型是一種表示類或方法行為對於未知類型的類型約束的方法，比如 “不管 這個方法的參數 x 和 y 是哪種類型，它們必須是相同的類型”，“必須為這些 方法提供同一類型的參數”

為什麼要用線程池？諸如 Web 服務器、資料庫伺服器、檔案伺服器或郵件伺服器之類的許多服務 器應用程式都面向處理來自某些遠程來源的大量短小的任務。請求以某種方式到 達伺服器，這種方式可能是通過網路通訊協定（例如 HTTP、FTP 或 POP）、通過 JMS 隊列或者可能通過輪詢資料庫。不管請求如何到達，伺服器應用程式中經常 出現的情況是：單個任務處理的時間很短而請求的數目卻是巨大的。構建伺服器應用程式的一個過於簡單的模型應該是：每當一個請求到達就創

很多有關編程風格的建議都是為了建立高品質、可維護的代碼，這很合理， 因為最容易修複 bug 的時間就是在產生 bug 之前（少量的預防措施……）。遺 憾的是，只預防往往是不夠的，雖然有一些精巧的工具可以協助您建立好的代碼 ，但是很少有工具可以協助您分析、維護或提高現有代碼的品質。寫安全執行緒的類很難，而分析現有類的執行緒安全性更難，增強類使其仍然保 持安全執行緒也很難。以隱含假定、不變式以及預期用例（雖然在開發人員的頭腦

效能管理通常被視為一種巫術，因為效能問題通常在應用程式開發完成之後 才會出現。到那時，就難以確定它們的根源。然而，一旦十分準確地確定了效能 問題的起因，那麼修正它常常是比較簡單的事情。工程師在尋找更有效方法來 執行特殊任務方面通常具有相當的創造性（有時他們的創造性過了頭）。對於任 何給定的效能問題，通過使用快取來減少冗餘計算或者只是添加更多的硬體 ，解決方案可能會與用更有效演算法進行替換一樣簡單。但是，要清楚地確定性 能問題的根源會很困難，而設計複雜程式甚至 更加困難，所以首先要使它們沒

活躍了將近三年的 JSR 133，近期發布了關於如何修複 Java 記憶體模型 （Java Memory Model, JMM）的公開建議。在本系列文章的 第 1 部分，專欄作 者 Brian Goetz 主要介紹最初的 JMM 中的幾個嚴重缺陷，這些缺陷導致了一些 難度高得驚人的概念語義，這些概念原來被認為很簡單。這個月，他介紹在新 JMM 中 volatile 和 final 的語義是如何變化的，這些改變使它們的語義符合 大多數開發人員的直覺。其中一些改變已經在 JDK 1.4

活躍了將近三年的 JSR 133，近期發布了關於如何修複 Java 記憶體模型 （Java Memory Model, JMM）的公開建議。原始 JMM 中有幾個嚴重缺陷，這導 致了一些難度高得驚人的概念語義，這些概念原來被認為很簡單，如 volatile 、final 以及 synchronized。在這一期的 Java 理論與實踐 中，Brian Goetz 展示了如何加強 volatile 和 final 的語義，以修複 JMM。這些更改有些已經 整合在 JDK 1.4

最近幾年，開發人員可以更廣泛地得到企業訊息排隊（MQ）產品。適當地使 用 MQ 技術經常可以改善應用程式的組織、效能和延展性。Java Message Service （Java Message Service (JMS)）是整合到 J2EE 中的一部分，它使得 MQ 服務 可以為任何 J2EE 應用程式所用。在本文（也是本專欄系列的第一部分）中， Brian 概述了在 Java 應用程式中使用訊息排隊的一些好處，並探討了能夠從 MQ 技術中獲益最大的問題類型。請在