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 套接字。