Java

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

當項目中需要 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

百萬分之一作為一個勤奮的開發人員，您已經為幾個需要更好地訪問複雜的大量資料存放區的客戶安裝了一個應用程式，它編寫良好，而且經過了充分測試。對每個客戶，現場測試階段都暢通無阻地通過了。您在去銀行的路上，心裡極少考慮這六個月來的軟體審查，這時您的傳呼機響了起來。您的一個客戶在使用您的軟體運行一個報表時，系統崩潰了。您趕到出事地點，運行了一個隨機測試。工作良好。您運行另一個。沒出現問題。您又運行了數百個測試。還是沒有問題。您又檢查了持續六個月運行這個應用程式的其它客戶。沒有投訴。您重複運行那個引起問題

每個Java對象都有hashCode()和 equals()方法。許多類忽略（Override)這 些方法的預設實施,以在對象執行個體之間提供更深層次的語義可比性。在Java理念 和實踐這一部分，Java開發人員Brian Goetz向您介紹在建立Java類以有效和准 確定義hashCode()和equals()時應遵循的規則和指南。您可以在討論論壇與作者 和其它讀者一同探討您對本文的看法。(您還可以點擊本文頂部或底部的討論進 入論壇。)雖然Java語言不直接支援關聯陣列 --

摘要如今，UML用於對軟體系統進行建模已有多年時間。然而，我極少看到有關對現代軟體系統建模和技術的詳細討論或執行個體。例如，對應用程式及其部署建模需要開發各類原型系統，並需要使用有組織的方法來設計圖的作用範圍和布局，使其真正發揮作用。在複雜的環境中，建模顯得尤為重要，它不僅能為編寫代碼的軟體工程師帶來好處，而且負責正確配置和部署軟體系統的軟體組態管理團隊和生產服務團隊也能從中獲益良多。本文示範了對現代軟體建模的幾種方法，這些方法可用於精確而簡明地交流架構方面的細節。簡介不久以前，有用的公司專屬應

按照《Unix網路編程》的劃分，IO模型可以分為：阻塞IO、非阻塞IO、IO複用、訊號驅動IO和非同步IO，按照POSIX標準來劃分只分為兩類：同步IO和非同步IO。如何區分呢？首先一個IO操作其實分成了兩個步驟：發起IO請求和實際的IO操作，同步IO和非同步IO的區別就在於第二個步驟是否阻塞，如果實際的IO讀寫阻塞請求進程，那麼就是同步IO，因此阻塞IO、非阻塞IO、IO服用、訊號驅動IO都是同步IO，如果不阻塞，而是作業系統幫你做完IO操作再將結果返回給你，那麼就是非同步IO。阻塞IO和非阻

我朋友經常引用我的一句話就是：你的Java對我的Javascript是侵入的....，彷彿她比我還OO來著。我自己就提出了一個解決的方法：就是把Java對象寫成JS對象，這樣Web設計人員只要關注JS對象，用JS對象來渲染整個Web頁面，這樣我就不會和他的領域衝突了。簡單來說，我們平常的WEB架構都是號稱MVC的，這樣它們就把V這個事情壓在了JAVA程式員的身上，可憐我的審美觀啊～所以我們應該把V繼續往下推，推給對JAVA什麼都不懂，但是卻有非常豐富的WEB設計人員的身上。總不能讓別人去學JAV