2.4 網絡移動性

長久以來，如何開發網絡軟件是Java開發人員所面臨的最大挑戰之一。在網絡領域需要實現平臺無關性，因為同一網絡中通常連接了多種不同的計算機和設備。除此之外，安全模式也是一個挑戰，因為網絡可以方便地傳輸病毒和其他形式的惡意代碼。在本節將詳細講解Java如何把握網絡所帶來的巨大機遇，為步入本書后面知識的學習打下基礎。

2.4.1 現實需要網絡移動性

當個人計算機互聯成網變得越來越普遍的時候，另一種軟件模式日益重要起來，即“客戶機/服務器”模式?！翱蛻魴C/服務器”模式將任務分為兩部分，分別運行在兩種計算機上：客戶端進程運行在終端用戶的個人計算機上，而服務器端進程運行在同一網絡的另一臺計算機上。客戶端和服務器端的進程通過網絡來回發送數據進行傳輸。服務器端進程通常只是簡單地接收網絡中客戶端發來的數據請求命令，從中央數據庫中提取需要的數據，并將該數據發送給客戶端。而客戶端在接到數據后，進行處理，然后顯示并允許用戶操作數據。這樣的模式允許個人計算機的終端用戶讀取并操作放在中央儲藏庫的數據，而不需強迫這些用戶共享中央CPU來處理數據。終端用戶地區是共享了運行服務器端進程的CPU，但在一定程度上，數據處理是由客戶端完成的，因此大大減輕了服務器端CPU的負載。

“客戶機/服務器”模式最初被稱作兩層客戶機/服務器模式，一層是客戶端，另一層是服務器。更復雜一些的模型叫做3層（表示有3個進程）、4層（4個進程）或者N層結構，也就是說層次結構越來越多了。當更多的進程加入計算時，客戶端和服務器的區別模糊了，于是人們開始使用“分布式處理”這個新名詞來涵蓋所有這些結構模式。

分布式處理模式綜合了網絡和處理器發展的優點，將進程分布在多個處理器上運行，并允許這些進程共享數據。盡管這種模式有許多大型計算機系統所無法比擬的優勢，但它也有個不可忽視的缺點：分布式處理比大型計算機系統更難管理。在大型計算機系統中，軟件應用程序存儲在主機的磁盤上，雖然可以有多個用戶使用該軟件，但它只需在一個地方安裝和維護。升級一個軟件后，所有用戶在下一次登錄并啟動該軟件的時候可以得到這個新的版本。但是相反，在分布式系統中，不同組件的軟件往往存儲在不同的磁盤上，因此，系統管理員需要在分布式系統的不同組件上安裝和維護軟件。要升級一個軟件時，管理員不得不分別升級每臺計算機上的這個軟件。所以，分布式處理的系統管理比大型計算機系統要困難得多。

Java的體系結構使軟件的網絡移動性成為可能，同時也預示了一種新的計算模式的到來。這種新的模式建立在流行的分布式處理模式的基礎上，并可以將軟件通過網絡自動傳送到各臺計算機上。這樣就解決了分布式處理系統中系統管理的困難。例如在一個C/S系統中，客戶端軟件可以存儲在網絡中的一臺中央計算機上，當終端用戶需要用該軟件的時候，這個中央計算機會通過網絡將可執行的軟件傳送到終端用戶的計算機上運行。

因此，軟件的網絡移動性標志著計算模式發展歷程中的重要一步，尤其是它解決了分布式處理系統中系統管理的問題，簡化了將軟件分布在多臺CPU上的工作，使數據可以和相關軟件一起被傳送。

2.4.2 網絡移動性

平臺無關性使得在網絡上傳送程序更加容易，因為不需要為每個不同的主機平臺都準備一個單獨的版本，因此也不需要判斷每臺計算機需要哪個特定的版本，一個版本就可以對付所有的計算機。Java的安全特性促進了網絡移動性的推廣，因為最終用戶就算從不信任的來源下載class文件，也可以充滿自信。因此實際上，Java體系結構通過對平臺無關性和安全性的支持，更好地推廣了其class文件的網絡機動性。

除了平臺無關性和安全性之外，Java體系結構對網絡移動性的支持主要集中在對在網絡上傳送程序的時間進行管理上。假若你在服務器上保存了一個程序，在需要的時候通過網絡來下載它，這個過程一般都會比從本地執行該程序要慢。因此對于在網絡上傳送程序來說，網絡移動性的一個主要難題就是時間。Java體系結構通過把傳統的單一二進制可執行文件切割成小的二進制碎片——Javaclass文件——來解決這個問題。class文件可以獨立在網絡上傳播，因為Java程序是動態鏈接、動態擴展的，最終用戶不需要等待所有的程序class文件都下載完畢，就可以開始運行程序了。第一個class文件到手，程序就開始執行。class文件本身也被設計得很緊湊，所以它們可以在網絡上飛快地傳送。因此Java體系結構為網絡移動性帶來的直接主要好處就是把一個單一的大二進制文件分割成小的class文件，這些class文件可以按需裝載。

Java應用程序從某個類的main()方法開始執行，其他的類在程序需要的時候才動態鏈接。如果某個類在一次操作中沒有被用到，這個類就不會被裝載。比如說，假若你在使用一個字處理程序，它有一個拼寫檢查器，但是在你使用的這次操作中沒有使用拼寫檢查器，那么它就不會被裝載。

除了動態鏈接之外，Java體系結構也允許動態擴展。動態擴展是裝載class文件的另一種方式，可以延遲到Java應用程序運行時才裝載。使用用戶自定義的類裝載器，或者Class類的forName()方法，Java程序可以在運行時裝載額外的程序，這些程序就會變成運行程序的一部分。因此，動態鏈接和動態擴展給了Java程序員一些設計上的靈活性，既可以決定何時裝載程序的class文件——而這又決定了最終用戶需要等待多少時間來從網絡上裝載class文件。

除了動態連接和動態擴展，Java體系結構對網絡移動性的直接支持還通過class文件格式體現。為了減少在網絡上傳送程序的時間，class文件被設計得很緊湊。它們包含的字節碼流設計得特別緊湊——之所以被稱為“字節碼”，是因為每條指令都只占據一個字節。除了兩個例外情況，所有的操作碼和它們的操作數都是按照字節對齊的，這使得字節碼流更小。這兩個例外是這樣一些操作碼，在操作碼和它們的操作數之間會填上1～3個字節，一邊操作數都按照字邊界對齊。

class文件的緊湊型隱含著另外一個含義，那就是Java編譯器不會做太多的局部優化。因為二進制兼容性規則的存在，Java編譯器不能做一些全局優化，比如把一個方法調用轉化為整個方法的內嵌（內嵌指把被調用方法的整個方法體都替換到發起調用的方法中去，這樣在代碼運行的時候，可以節省方法調用和返回的時間）。二進制兼容性要求，假若一個方法被現有class文件包括以后，那么改變這個方法的時候必須不破壞已有的調用方法。在同一個類中使用的方法可能使用內嵌，但是一般來說，Java編譯器不會做這種優化，部分原因是這樣為class文件瘦身得不償失。優化常常是在代碼大小和執行速度間進行的折中。因此，Java編譯器通常會把優化工作留給Java虛擬機，后者在裝載類之后，在解釋執行，即時編譯或者自適應編譯的時候都可以優化代碼。

除了動態鏈接、動態擴展和緊湊的class文件之外，還有一些并非體系結構必須的策略，可以幫助控制在網絡上傳送class文件的時間。因為HTTP需要單獨為Javaapplet中用到的每一個class文件請求連接，所以下載applet的很大一部分時間并不是用來實際傳輸class文件的時間，而是每一個class文件請求的網絡協議握手的時間。一個文件需要的總時間是按照需要下載的class文件的數目倍增的。為了解決這個問題，Java 1.1包含了對Jar的支持，Jar文件允許在一次網絡傳輸過程中傳輸多個文件，這和一次傳送一個個單獨class文件相比，大幅度降低了需要的總體下載時間。更大的優點是，Jar文件中的數據可以壓縮，從而使下載時間更少。所以有時候通過一個大文件來傳送軟件。例如有些class文件是程序開始運行之前所必需的，這些文件可以很快地通過Jar文件一次性傳遞。

另外一個降低最終用戶等待時間的策略就是不采取按需下載class文件的做法。有幾種不同的技術，例如MarimbaCastanet使用的訂閱模式，可以在需要class文件之前就已經把它們下載下來了，這樣程序就可以更快地啟動。

因此，除了平臺無關性和安全性能夠對網絡移動性有利外，Java體系結構的主要著眼點就是控制class文件在網絡上傳送的時間。動態鏈接和動態擴展允許Java程序按照小功能單元設計，在最終用戶需要的時候才單獨下載。Class文件的緊湊性本身有助于減少Java程序在網絡上傳送的時間。Jar文件允許在一次網絡連接中傳送多個文件，還允許數據壓縮。