21 世紀初，Spring 框架的誕生和崛起讓沉重而腐朽的 J2EE 遭到了當頭棒喝，隨后大批開發(fā)人員轉投 Spring 陣營，呼吸間就讓 J2EE 陣營大傷元氣。然而這種命懸一線的危機并沒有造成毀滅性的打擊，尤其是對于 Java 這種提倡開放的平臺而言，取長補短，互相促進才是正道。于是，JCP 委員會痛定思痛，在 2006 年推出 Java EE 5 規(guī)范，主要是對 EJB 的開發(fā)進行了極大幅度的簡化。2008 年發(fā)布的 Java EE 6 引入了 CDI、BV、JAX-RS 等一系列新功能，并且以配置文件（profile）的方式讓 Java EE 向輕量級邁進了一步。特別有趣的是，Spring 框架也開始提供對某些 Java EE 注解的支持，是否標志著兩大陣營開始合流？Java EE 7 預定于今年下半年發(fā)布，目標是支持云計算。最近幾年來，云計算一直被炒作，卻從來沒有一個準確的定義和規(guī)范，希望 Java EE 7 能夠在 Java 界扭轉這種尷尬的局面。

下面開始詳細列舉 Java EE 7 的新功能前瞻，數(shù)據(jù)來源于《Java Magazine 2012-01/02》中的《Cloud/Java EE: Looking Ahead to Java EE 7》一文。Java EE 7 是以“日期驅動”的方式開發(fā)的，也就是說，在計劃日期到達前沒有完成的功能都將被推遲到 Java EE 8。

Java EE 7（JSR-342）

• 主題：讓應用程序能夠在私有或公共云上容易地運行。
• 該平臺將定義一個應用程序元數(shù)據(jù)描述符，以描述 PaaS 執(zhí)行環(huán)境（例如多租戶、資源共享、服務質量，以及應用程序間的依賴）。
• 支持 HTML5、WebSocket、JSON 等新標準，并為它們一一提供 API。
• 消除受管 Bean、EJB、Servlet、JSF、CDI 和 JAX-RS 之間不一致的地方。
• 可能在 Web 配置文件中包含 JAX-RS 2.0 和 JMS 2.0 API 修訂版。
• 更新一些現(xiàn)有的技術，可能引入用于 Java EE 的并發(fā)工具（JSR-236）和 JCache（JSR-107）。

Java Persistence 2.1（JSR-338）

• 支持多租戶。
• 支持存儲過程和廠商函數(shù)。
• 用規(guī)則（Criteria）進行更新和刪除。
• 支持數(shù)據(jù)庫大綱（Scheme）的生成。
• 持久化上下文的同步。
• 偵聽器中的 CDI 注入。

JAX-RS 2.0: The Java API for RESTful Web Services（JSR-339）

• 客戶端 API——底層使用構建者模式，可能提供上層封裝。
• 超媒體——輕松創(chuàng)建和處理關聯(lián)了資源的鏈接。
• 使用 Bean 驗證框架來驗證表單或查詢參數(shù)。
• 與 @Inject 更緊密集成。
• 服務端的異步請求處理。
• 使用“qs”進行服務端的內容協(xié)商。

Java Servlet 3.1（JSR-340）

• 為 Web 應用程序優(yōu)化 PaaS 模型。
• 用于安全、會話和資源的多租戶。
• 基于 NIO2 的異步 I/O。
• 簡化的異步 Servlet。
• 利用 Java EE 并發(fā)工具。
• 支持 WebSocket。

Expression Language 3.0（JSR-341）

• 將 ELContext 分離為解析和求值上下文。
• 可定制的 EL 強迫規(guī)則。
• 在 EL 表達式中直接引用靜態(tài)方法和成員。
• 添加運算符，例如等于、字符串連接和取大小。
• 與 CDI 集成，例如在表達式求值前/中/后生成事件。

Java Message Service 2.0（JSR-343）

• 簡化開發(fā)——改變 JMS 編程模型，讓應用程序開發(fā)變得更加簡單容易。
• 清除/澄清現(xiàn)有規(guī)范中的模糊之處。
• 與 CDI 集成。
• 澄清 JMS 和其他 Java EE 規(guī)范之間的關系。
• 新的強制性 API允許任何 JMS 提供者能與任何 Java EE 容器集成。
• 來自平臺的多租戶和其他云相關的功能。

JavaServer Faces 2.2（JSR-344）

• 簡化開發(fā)——使配置選項動態(tài)化，使復合組件中的 cc:interface 可選，F(xiàn)acelet 標記庫的速記 URL，與 CDI 集成，JSF 組件的 OSGi 支持。
• 支持 Portlet 2.0 橋（JSR-329）的實現(xiàn)。
• 支持 HTML5 的功能，例如 HTML5 表單、元數(shù)據(jù)、頭部和區(qū)段內容模型。
• 流管理，頁面導航事件的偵聽器，以及 fileUpload 和 BackButton 等新組件。

Enterprise JavaBeans 3.2（JSR-345）

• 增強 EJB 架構以支持 PaaS，例如多租戶。
• 對在 EJB 外使用容器管理的事務進行工廠化。
• 更進一步使用注解。
• 與平臺中的其他規(guī)范對齊和集成。

Contexts and Dependency Injection 1.1（JSR-346）

• 攔截器的全局排序和管理內建上下文的裝飾器 API。
• 可在 Java EE 容器外啟動的嵌入式模式。
• 聲明式地控制歸檔中的哪些包和 Bean 將被掃描。
• 注入日志之類的靜態(tài)成員。
• 將 Servlet 事件作為 CDI 事件發(fā)送。

Bean Validation 1.1（JSR-349）

• 與其他 Java EE 規(guī)范集成。
• JAX-RS：在 HTTP 調用中驗證參數(shù)和返回值。
• JAXB：將約束條件轉換到 XML 模式描述符中。
• 方法級別的驗證。
• 在組集合上應用約束條件。
• 擴展模型以支持“與”和“或”風格的組合。

JCache: Java Temporary Caching API（JSR-107）

• 在內存中暫存 Java 對象的 API 和語義，包括對象的創(chuàng)建、共享訪問、緩存池、失效，以及跨 JVM 的一致性。

Java State Management（JSR-350）

• 應用程序和 Java EE 容器可使用該 API 將狀態(tài)管理的任務交給具有不同 QoS 特征的第三方提供者。
• 基于 Java SE 的調用者可通過查詢狀態(tài)提供者來訪問狀態(tài)數(shù)據(jù)。
• 可添加具有不同 QoS 的提供者，API 調用者能夠按自己的規(guī)則進行查詢。

Batch Applications for the Java Platform（JSR-352）

• 用于批處理應用程序的編程模型，以及用于調度和執(zhí)行工作的運行時。
• 為標準編程模型定義批處理工作、批處理工作步驟、批處理應用程序、批處理執(zhí)行器和批處理工作管理器。

Concurrency Utilities for Java EE（JSR-236）

• 提供一個整潔、簡單且獨立的 API，使其能用于任何 Java EE 容器中。

Java API for JSON Processing（JSR-353）

• 處理 JSON 的 Java API。

ForkJoinPool 是 Java SE 7 新功能“分叉/結合框架”的核心類，現(xiàn)在可能乏人問津，但我覺得它遲早會成為主流。分叉/結合框架是一個比較特殊的線程池框架，專用于需要將一個任務不斷分解成子任務（分叉），再不斷進行匯總得到最終結果（結合）的計算過程。比起傳統(tǒng)的線程池類 ThreadPoolExecutor，ForkJoinPool 實現(xiàn)了工作竊取算法，使得空閑線程能夠主動分擔從別的線程分解出來的子任務，從而讓所有的線程都盡可能處于飽滿的工作狀態(tài)，提高執(zhí)行效率。

ForkJoinPool 提供了三類方法來調度子任務：

execute 系列

異步執(zhí)行指定的任務。

invoke 和 invokeAll

執(zhí)行指定的任務，等待完成，返回結果。

submit 系列

異步執(zhí)行指定的任務并立即返回一個 Future 對象。

子任務由 ForkJoinTask 的實例來代表。它是一個抽象類，JDK 為我們提供了兩個實現(xiàn)：RecursiveTask 和 RecursiveAction，分別用于需要和不需要返回計算結果的子任務。ForkJoinTask 提供了三個靜態(tài)的 invokeAll 方法來調度子任務，注意只能在 ForkJoinPool 執(zhí)行計算的過程中調用它們。

ForkJoinPool 和 ForkJoinTask 還提供了很多讓人眼花繚亂的公共方法，其實它們大多數(shù)都是其內部實現(xiàn)去調用的，對于應用開發(fā)人員來說意義不大。

下面以統(tǒng)計 D 盤文件個數(shù)為例。這實際上是對一個文件樹的遍歷，我們需要遞歸地統(tǒng)計每個目錄下的文件數(shù)量，最后匯總，非常適合用分叉/結合框架來處理：

// 處理單個目錄的任務
public class CountingTask extends RecursiveTask<Integer> {
    private Path dir;

    public CountingTask(Path dir) {
        this.dir = dir;
    }

    @Override
    protected Integer compute() {
        int count = 0;
        List<CountingTask> subTasks = new ArrayList<>();

        // 讀取目錄 dir 的子路徑。
        try (DirectoryStream<Path> ds = Files.newDirectoryStream(dir)) {
            for (Path subPath : ds) {
                if (Files.isDirectory(subPath, LinkOption.NOFOLLOW_LINKS)) {
                    // 對每個子目錄都新建一個子任務。
                    subTasks.add(new CountingTask(subPath));
                } else {
                    // 遇到文件，則計數(shù)器增加 1。
                    count++;
                }
            }

            if (!subTasks.isEmpty()) {
                // 在當前的 ForkJoinPool 上調度所有的子任務。
                for (CountingTask subTask : invokeAll(subTasks)) {
                    count += subTask.join();
                }
            }
        } catch (IOException ex) {
            return 0;
        }
        return count;
    }
}

// 用一個 ForkJoinPool 實例調度“總任務”，然后敬請期待結果……
Integer count = new ForkJoinPool().invoke(new CountingTask(Paths.get("D:/")));
    

在我的筆記本上，經多次運行這段代碼，耗費的時間穩(wěn)定在 600 豪秒左右。普通線程池（Executors.newCachedThreadPool()）耗時 1100 毫秒左右，足見工作竊取的優(yōu)勢。

結束本文前，我們來圍觀一個最神奇的結果：單線程算法（使用 Files.walkFileTree(...)）比這兩個都快，平均耗時 550 毫秒！這警告我們并非引入多線程就能優(yōu)化性能，并須要先經過多次測試才能下結論。

前面已經看到，Socket 類的 getInputStream() 和 getOutStream() 方法分別獲取套接字的輸入流和輸出流。輸入流用來讀取遠端發(fā)送過來的數(shù)據(jù)，輸出流則用來向遠端發(fā)送數(shù)據(jù)。

輸入流

使用套接字的輸入流讀取數(shù)據(jù)時，當前線程會進入阻塞狀態(tài)，直到套接字收到一些數(shù)據(jù)為止（亦即套接字的接收緩沖區(qū)有可用數(shù)據(jù)）。該輸入流的 available() 方法只是返回接收緩沖區(qū)的可用字節(jié)數(shù)量，不可能知道遠端還要發(fā)送多少字節(jié)。使用輸入流的時候，最好先將它包裝為一個 BufferedInputStream，因為讀取接收緩沖區(qū)將導致 JVM 和底層系統(tǒng)之間的切換，應當盡量減少切換次數(shù)以提高性能。BufferedInputStream 的緩沖區(qū)大小最好設為套接字接收緩沖區(qū)的大小。

如果直接調用輸入流的 close() 方法來關閉它，則將導致套接字被關閉。對此，Socket 類提供了一個 shutdownInput() 方法來禁用輸入流。調用該方法后，每次讀操作都將返回 EOF，無法再讀取遠端發(fā)送的數(shù)據(jù)。對這個 EOF 的檢測，不同的輸入流包裝體現(xiàn)出不同的結果，可能讀到 -1 個字節(jié)，可能讀到的字符串為 null，還可能收到一個 EOFException 等等。禁用輸入流后，遠端輸出流的行為是平臺相關的：

• 在 BSD 平臺上，遠端的發(fā)送的數(shù)據(jù)能正常接收，然后直接丟棄。遠端無法知道本端的輸入流已禁用。這和 JDK 文檔描述的行為一致。
• 在 WINSOCK 平臺上，遠端發(fā)送數(shù)據(jù)將會導致“連接被重置”的錯誤。
• 在 Linux 平臺上，遠端發(fā)送的數(shù)據(jù)能繼續(xù)接收，直到套接字輸入緩沖區(qū)填滿，之后遠端再也無法發(fā)送數(shù)據(jù)（若使用阻塞模式則進入死鎖）。

禁用輸入流這種技術并不常用。

輸出流

套接字的輸出操作實際上僅僅將數(shù)據(jù)寫到發(fā)送緩沖區(qū)內，當發(fā)送緩沖區(qū)填滿且上次的發(fā)送成功后，由底層系統(tǒng)負責發(fā)送。如果發(fā)送緩沖區(qū)的剩余空間不夠，當前線程就會阻塞。和輸入流類似，最好將輸出流包裝為 BufferedOutputStream。

如果套接字的雙發(fā)都使用 ObjectInputStream 和 ObjectOutputStream 來讀寫 Java 對象，則必須先創(chuàng)建 ObjectOutputStream，因為 ObjectInputStream 在構造的時候會試圖讀取對象頭部，如果雙發(fā)都先創(chuàng)建 ObjectInputStream，則會互相等待對方的輸出，造成死鎖：

// 創(chuàng)建的順序不能顛倒！
ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());
ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
    

類似于輸入流，關閉輸出流也導致關閉套接字，所以 Socket 類同樣提供了一個 shutdownOutput() 來禁用輸出流。禁用輸出流后，已寫入發(fā)送緩沖區(qū)的數(shù)據(jù)會正常發(fā)送，之后的任何寫操作都會導致 IOException，且遠端的輸入流始終會讀到 EOF。禁用輸出流非常有用，例如套接字的雙發(fā)都在發(fā)送完畢數(shù)據(jù)后禁用輸入流，然后雙方都會收到 EOF，從而知道數(shù)據(jù)已經全部交換完畢，可以安全關閉套接字。直接關閉套接字會同時關閉輸入流和輸出流，且斷開連接，達不到這種效果。

使用流的阻塞套接字的優(yōu)缺點

如果要使用流進行輸入和輸出，就只能用阻塞模式的套接字。這里總結一下阻塞套接字的優(yōu)缺點。先看看優(yōu)點：

1. 編程模型簡單，非常適合初學者上手。
2. 以裝飾器模式設計的 Java I/O 使得開發(fā)人員可以輕松地從 I/O 流讀寫任何類型的數(shù)據(jù)。

但在性能方面有致命的缺點：

1. 由于服務器套接字接受連接，以及套接字的讀寫都會阻塞，性能低下。
2. 如果不對 I/O 流手動進行緩沖，則可能造成一次只處理一個字節(jié)，性能低下。
3. 服務器套接字每次只能接受一個連接，導致 JVM 和底層系統(tǒng)之間頻繁的調用切換，性能低下。

下一篇文章開始探討使用基于 NIO 的套接字通道和緩沖區(qū)實現(xiàn)伸縮性更強的 TCP 套接字。

ServerSocket 類和 Socket 類都提供了多個公共構造方法。不同的構造方法不僅帶的參數(shù)不同，所具有的意義也不一樣。下面分別解析這兩個類的實例初始化過程。

ServerSocket 實例的初始化

ServerSocket 類提供了四個構造器：

public ServerSocket(int port) throws IOException

public ServerSocket(int port, int backlog) throws IOException

public ServerSocket(int port, int backlog, InetAddress bindAddr) throws IOException

public ServerSocket() throws IOException

帶參構造器用來創(chuàng)建已綁定的服務器套接字，也就是說構造成功后它就已經開始偵聽指定的端口，且能夠調用 accept() 方法來接受客戶端連接。默認構造器則會創(chuàng)建未綁定的服務器套接字，構造成功后必須手動將其綁定到一個本地地址才能用，在綁定之前可以進行一些選項配置。

帶參構造器

總的來說，帶參構造器提供了三個參數(shù)：

port

指定該服務器套接字所要偵聽的本地端口。如果為 0，則由系統(tǒng)自動分配一個端口號，這必須以另外的方式讓客戶端獲取端口號。

backlog

這個名詞目前還沒有合適的譯名。底層系統(tǒng)的 TCP 實現(xiàn)會維護一個連接隊列，該隊列緩存了已被 TCP 處理完畢，但還沒有被服務器套接字接受的客戶端連接。一旦某個連接被接受（通過調用 accept() 方法），它就會被從隊列中移除。backlog 參數(shù)就用于指定隊列的最大長度，默認值為 50，但這個值只是一個建議，底層系統(tǒng)可能根據(jù)需要自動調整。如果隊列滿了，則其行為是平臺相關的：微軟的 WINSOCK 會拒絕新的連接，其他實現(xiàn)則什么都不做。嚴格地說，微軟沒有遵守規(guī)范，破壞了游戲規(guī)則……

bindAddr

一臺機器可能會有多個本地 IP 地址，例如同時使用多塊網(wǎng)卡。使用其他兩個帶參構造器時，該參數(shù)為 null，服務器套接字會在所有的本地 IP 地址（0.0.0.0 或 ::0）上偵聽。如果希望只偵聽一個地址，則可使用該參數(shù)。

默認構造器

如果使用默認構造器，在綁定地址前，還可以做些配置。綁定操作由兩個 bind 方法定義，參數(shù)類似于帶參構造器。配置項包括以下方面（都必須在綁定前配置）：

設置是否重用本地地址

該選項由 setReuseAddress(boolean on) 方法配置，對應底層系統(tǒng)的 SO_REUSEADDR 套接字選項。JDK 沒有定義該選項的默認值。如果該選項為 false，則在關閉 TCP 連接時，為了保證可靠性，該連接可能在關閉后的一段時間（大約兩分鐘）內保持超時狀態(tài)（通常稱為 TIME_WAIT 狀態(tài)或 2MSL 等待狀態(tài)），這段時間里無法將新建的服務器套接字綁定到同一個地址。在開發(fā)階段，服務器可能不斷重啟，打開改選項會非常有用。

設置接收緩沖區(qū)大小

該選項由 setReceiveBufferSize(int size) 方法配置，對應底層系統(tǒng)的 SO_RCVBUF 套接字選項，單位是字節(jié)。《RFC 1323 - TCP Extensions for High Performance》將緩沖區(qū)大小定義為 64KB。該選項只是一個建議值，底層系統(tǒng)可能根據(jù)需要自行調整。

設置超時值

該選項由 setSoTimeout(int timeout) 方法配置，對應底層系統(tǒng)的 SO_TIMEOUT 套接字選項，單位是毫秒。默認值為 0。該選項影響 accept 方法的阻塞時間長度，如果超時將引發(fā) SocketTimeoutException。如果設為 0，則表示永不超時。

設置性能首選項

性能首選項包括連接時間、延遲和帶寬三個選項，由 setPerformancePreferences(int connectionTime, int latency, int bandwidth) 方法配置。這三個數(shù)值分別表示短連接時間、低延遲和高帶寬的相對重要性，數(shù)值越大則越重要；其各自的絕對值沒有意義。該方法的初衷是為了讓 Java 能在用非 TCP/IP 實現(xiàn)的套接字環(huán)境下工作得更好，某些需要對網(wǎng)絡進行調優(yōu)的程序也可以將這三個首選項作為配置參數(shù)提供給用戶。

Socket 實例的初始化

Socket 類提供了六個公共構造器（已過時的除外）：

public Socket(String host, int port) throws UnknownHostException, IOException

public Socket(InetAddress address, int port) throws IOException

public Socket(String host, int port, InetAddress localAddr, int localPort) throws IOException

public Socket(InetAddress address, int port, InetAddress localAddr, int localPort) throws IOException

public Socket()

public Socket(Proxy proxy)

前四個構造器創(chuàng)建已連接的客戶端套接字，也就是說構造的時候就會去連接服務器。前兩個構造器需要提供服務器的地址和端口作為參數(shù)，本地地址和端口由系統(tǒng)自動分配；后兩個允許手動指定本地地址和端口，但極少使用。后兩個構造器創(chuàng)建未連接的套接字，創(chuàng)建后需要調用 connect 方法手動連接，連接之前可以做一些配置。最后一個構造器接受一個代表代理服務其的 Proxy 對象，JDK 支持 HTTP 和 SOCKS（V4 或 V5）兩種代理類型。

連接前的配置

在連接前，客戶端套接字不僅像服務器套接字那樣可以設置是否重用本地地址、緩沖區(qū)大小、超時值和性能首選項，還能夠配置以下各項（都必須在連接前配置）：

設置是否保持活躍

該選項由 setKeepAlive(boolean on) 方法配置，對應底層系統(tǒng)的 SO_KEEPALIVE 套接字選項。默認值為 false。如果打開該選項，則套接字會定期自動發(fā)送保持活躍的探測性消息，類似于心跳檢測。根據(jù)《RFC 1122 - Requirements for Internet Hosts》的規(guī)定，保持活躍機制只是 TCP 的一個可選功能，如果支持的話，默認必須為 false，而且這種機制默認在成功建立連接后，且連續(xù)兩小時沒有數(shù)據(jù)傳輸?shù)那闆r下才會被激活。從另一方面來看，通過套接字的 I/O 操作完全可以知道連接是否還有效，所以該選項的實用價值不大。

設置是否收發(fā)帶外數(shù)據(jù)

該選項由 setOOBInline(boolean on) 方法配置，對應底層系統(tǒng)的 SO_OOBINLINE 套接字選項。默認值為 off。帶外數(shù)據(jù)（Out-of-band Data）也叫做緊急數(shù)據(jù)，表示數(shù)據(jù)很重要，需要使用不同于發(fā)送普通數(shù)據(jù)的一個專用通道來發(fā)送。打開該選項后，就可以調用 sendUrgentData(int data) 方法發(fā)送一個字節(jié)的緊急數(shù)據(jù)。JDK 對帶外數(shù)據(jù)只提供了有限支持，緊急數(shù)據(jù)將會和普通數(shù)據(jù)一起被收到，并且無法自動區(qū)分。該選項對應用開發(fā)人員意義不大。

設置是否從容關閉連接

該選項由 setSoLinger(boolean on, int linger) 方法配置，對應底層系統(tǒng)的 SO_LINGER 套接字選項。默認為 false。該選項只會影響套接字的關閉，其中的 linger 參數(shù)表示超時時間，單位為秒。如果打開改選項：如果將 linger 設為 0，則關閉套接字的時候，未發(fā)送的數(shù)據(jù)會被丟棄，且另一端會出現(xiàn)連接被同位體重置的異常；如果 linger 非 0，則關閉套接字的線程將被阻塞，直到數(shù)據(jù)全部發(fā)送或超時，超時后的行為與底層系統(tǒng)相關，JDK 無法控制。如果關閉該選項，則套接字正常關閉，數(shù)據(jù)也會全部發(fā)送。由于底層實現(xiàn)的差異性，不提倡應用開發(fā)人員打開該選項。

設置是否延遲發(fā)送數(shù)據(jù)

該選項由 setTcpNoDelay(boolean on) 方法配置，對應底層系統(tǒng)的 TCP_NODELAY TCP 選項。默認值為 off。打開該選項將禁用 Nagle 算法，TCP 包會立即發(fā)送；關閉該選項則會啟用 Nagle 算法，多個較小的 TCP 包會被組合成一個大包一起發(fā)送，雖然發(fā)送延遲了，但有利于避免網(wǎng)絡擁塞。默認為 false。該選項對實時性很強的程序可能有用，但一般的程序不需要關心。

設置流量類別

該選項由 setTrafficClass(int tc) 方法配置，對應底層系統(tǒng)的“流量類別”套接字屬性。該選項用于向網(wǎng)絡（例如路由器）提示從該套接字發(fā)送的包需要獲取哪些服務類型，對本地 TCP 協(xié)議棧沒有影響。IPv4 和 IPv6 分別定義了多個不同的值，例如 IPv4 將 0x08 定義為最大吞吐量，0x10 定義為最小延遲，等等。可以用或運算將多個值合并為一個選項。該選項用來調整性能，需要根據(jù)實際情況設置。由于只是建議值，可能被網(wǎng)絡忽略。