qileilove

　　要充分理解本文，必須具備Windows 環(huán)境下桌面應(yīng)用程序的工作經(jīng)驗(yàn)，我認(rèn)為讀者對(duì)如何使用 Linux 桌面有一個(gè)基本的了解。使用一個(gè)運(yùn)行的 Linux 計(jì)算來機(jī)探討本文的概念和示例是很有幫助的。

　　概述

　　有時(shí)候第一次在 Linux 上運(yùn)行一個(gè)應(yīng)用程序需要一點(diǎn)額外工作。有些應(yīng)用程序，比如服務(wù)器服務(wù)，可能無法安裝為服務(wù)，因此您需要從命令行啟動(dòng)這些應(yīng)用程序。對(duì)于啟動(dòng)這些應(yīng)用程序的用戶帳戶而言，需要在應(yīng)用程序文件中設(shè)置執(zhí)行許可標(biāo)志 （x）。

　　運(yùn)行用戶空間應(yīng)用程序

　　Linux 在內(nèi)核空間或用戶空間運(yùn)行進(jìn)程。用戶空間 是操作系統(tǒng)的區(qū)域，應(yīng)用程序通常在此運(yùn)行。簡(jiǎn)單地說，每個(gè)用戶帳戶有其自己的用戶空間，應(yīng)用程序在這個(gè)領(lǐng)域內(nèi)運(yùn)行。

　　默認(rèn)情況下，只有 root 用戶有權(quán)訪問內(nèi)核空間。root 用戶 是 Linux 中的超級(jí)用戶，相當(dāng)于 Windows 中的管理員帳戶。在 root 用戶帳戶下運(yùn)行應(yīng)用程序可能會(huì)引起安全風(fēng)險(xiǎn)，是不可取的。

　　很多服務(wù)器服務(wù)需要 root 權(quán)限啟動(dòng)服務(wù)。然而，服務(wù)啟動(dòng)后，root 帳戶通常會(huì)將其移至服務(wù)帳戶。嚴(yán)格地說，Linux 中的服務(wù)帳戶 才是標(biāo)準(zhǔn)的用戶帳戶。主要區(qū)別是服務(wù)帳戶僅用于運(yùn)行一個(gè)服務(wù)，而不是為任何實(shí)際登錄的用戶準(zhǔn)備的。

　　設(shè)置權(quán)限

　　您可以使用 chmod 命令在一個(gè)文件中設(shè)置執(zhí)行權(quán)限。在 Linux 中，umask 設(shè)置通常用來防止下載的文件被執(zhí)行，也有充分的理由相信，因?yàn)樗兄诰S護(hù) Linux 計(jì)算機(jī)的安全性。

　 　大多數(shù) Linux 發(fā)行版具有一個(gè)值為 022 的 umask 設(shè)置，這意味著，默認(rèn)情況下一個(gè)新文件權(quán)限設(shè)置為 644。權(quán)限的數(shù)字表示形式采用讀 （4）、寫 （2）、執(zhí)行 （1） 的格式。因此，默認(rèn)權(quán)限為 644 的應(yīng)用程序下載意味著文件所有者有讀寫權(quán)限，而組用戶和其他用戶只有讀權(quán)限。

　　例如，為每個(gè)人賦予一個(gè)文件的執(zhí)行權(quán)限，使用 chmod a+x 命令。a 表示所有人，加號(hào) （+） 表示添加，而 x 表示執(zhí)行。同樣地，如果應(yīng)用程序是一個(gè)服務(wù)器服務(wù)，您應(yīng)該確保只有授權(quán)帳戶才有權(quán)執(zhí)行此服務(wù)。

　　如果一個(gè)應(yīng)用程序能夠在標(biāo)準(zhǔn)用戶帳戶權(quán)限下運(yùn)行，但只有特定組中的用戶才需要使用它，您可以將該組所有者權(quán)限設(shè)置為可執(zhí)行，然后將這些用戶添加到該組中。

　　更具體地說，您可以在一個(gè)可執(zhí)行文件中設(shè)置訪問控制列表 （ACL） 權(quán)限，賦予特定用戶或組權(quán)限來運(yùn)行該應(yīng)用程序。使用 setfacl 實(shí)用工具設(shè)置 ACL 權(quán)限。

　　對(duì)于這些需要以 root 用戶啟動(dòng)進(jìn)程的應(yīng)用程序，比如服務(wù)器服務(wù)，您有幾個(gè)選擇。總結(jié)了允許用戶執(zhí)行需要 root 權(quán)限的服務(wù)器服務(wù)的各種選項(xiàng)。

　　從命令行運(yùn)行

　　在管理 Linux 服務(wù)器時(shí)，從命令行運(yùn)行應(yīng)用程序是一項(xiàng)基本的任務(wù)。很多應(yīng)用程序使用 shell 腳本（類似于 Windows 批處理文件 .bat）來啟動(dòng)應(yīng)用程序并執(zhí)行其他任務(wù)，比如設(shè)置變量以及為其他用戶分配進(jìn)程。例如，應(yīng)用程序可能需要一個(gè) Java？ Virtual Machine (JVM) 來執(zhí)行。那樣的話，shell 腳本可以設(shè)置適當(dāng)?shù)沫h(huán)境變量，然后執(zhí)行 Java 命令來運(yùn)行 Java Archive (JAR) 或類文件。這同樣適用于使用 Perl、Python、甚至 C# 的應(yīng)用程序。（當(dāng)然，C# 編譯的應(yīng)用程序可以在 Linux 上運(yùn)行）

　　● sh
　　● php
　　● python
　　● perl
　　● java

　　但更多情況下，套裝應(yīng)用程序使用 shell 腳本，以 #！ 符號(hào)設(shè)置環(huán)境變量提供該語言的運(yùn)行時(shí)可執(zhí)行路徑，比如 #！/usr/bin/python。您也應(yīng)該熟悉這種方法。

　　清單 1 使用 catalina.sh 默認(rèn)腳本通過 ./ 方法啟動(dòng) Apache Tomcat 應(yīng)用程序服務(wù)器。然后，使用 sh 方法啟動(dòng)服務(wù)器。因?yàn)槟J(rèn)端口是 8080，標(biāo)準(zhǔn)用戶不需要對(duì)其進(jìn)行特別修改就可以啟動(dòng)該服務(wù)。

　　清單 1. 從命令行執(zhí)行應(yīng)用程序

　　考慮啟動(dòng)一個(gè)典型 Hypertext Transfer Protocol (HTTP) Web 服務(wù)器。在 Linux 中，任何低于 1024 的端口被認(rèn)為是一個(gè)權(quán)限端口，只有 root 可以打開權(quán)限端口。因?yàn)椋J(rèn)情況下，Web 服務(wù)器運(yùn)行于端口 80，root 需要啟動(dòng)該進(jìn)程。然而，如上所述，以 root 用戶運(yùn)行一個(gè)服務(wù)被認(rèn)為是不安全的。正確的步驟是以 root 啟動(dòng) 該服務(wù)，然后將其轉(zhuǎn)移到一個(gè)標(biāo)準(zhǔn)用戶或者服務(wù)帳戶。

　　幸運(yùn)的是，許多服務(wù)器服務(wù)由腳本來執(zhí)行這一操作。如果您從頭開始構(gòu)建 Apache Web 服務(wù)器，您將會(huì)發(fā)現(xiàn)它以 root 用戶啟動(dòng)，然后將 httpd 線程轉(zhuǎn)交給 apache 用戶。

　　清單 2 啟動(dòng)一個(gè)默認(rèn)的 Apache 2 Web 服務(wù)器編譯。安裝流程也做了一些事情，包括使 apachectl 命令可執(zhí)行。因?yàn)樵摿鞒绦枰褂枚丝?80，使用 root 用戶權(quán)限啟動(dòng)。然而，ps 命令顯示 httpd 流程在 apache 用戶帳戶下運(yùn)行。

　　清單 2. 啟動(dòng) Apache Web 服務(wù)器

　　在后臺(tái)運(yùn)行應(yīng)用程序

　　一些安裝的軟件可能不像 Apache Web 服務(wù)器那樣用戶友好。您很可能需要在流程啟動(dòng)后以后臺(tái)方式運(yùn)行它，除非您正在進(jìn)行故障排除，或者想要看看應(yīng)用程序到底怎么了。如果您沒有這么 做，shell 關(guān)閉后應(yīng)用程序?qū)⒔K止。運(yùn)行服務(wù)器服務(wù)時(shí)，可不希望每次關(guān)閉終端 shell 或者退出時(shí)服務(wù)都會(huì)停止！

　　如果在后臺(tái)運(yùn)行一個(gè)應(yīng)用程序，即使關(guān)閉了 shell 窗口，應(yīng)用程序也會(huì)繼續(xù)運(yùn)行。您可以通過在執(zhí)行命令結(jié)尾附加一個(gè) (&) 符號(hào)來啟動(dòng)應(yīng)用程序。例如，您可以使用 vi 編輯器打開文件，然后使用 vi /etc/sysconfig/network & 命令在后臺(tái)運(yùn)行該文件，因?yàn)?& 可以打開 /etc/sysconfig/network 文件并將其保留在后臺(tái)。即使在退出后，您也可以使用 nohup 實(shí)用工具支持進(jìn)程繼續(xù)運(yùn)行。例如，nohup vi /etc/sysconfig/network &。

　　清單 3 在 Vim 編輯器中打開一個(gè)用來編輯的文件，然后將其放在后臺(tái)。

　　清單 3. 在后臺(tái)運(yùn)行應(yīng)用程序

　　您可以輸入 jobs 命令來查看您在后臺(tái)上運(yùn)行的所有應(yīng)用程序。為在后臺(tái)上運(yùn)行的每個(gè)任務(wù)分配了一個(gè)序列號(hào)，從 1 開始。 清單 3 中的任務(wù)序列號(hào)是 1。24940 是進(jìn)程 ID (PID)。您可以使用 fg 命令和特定的任務(wù)號(hào)將應(yīng)用程序移到前臺(tái)。在本例中，進(jìn)程沒有被用戶所使用，因此顯示為 Stopped。但是，命令 fg 1 打開終端并回到編輯文件的活動(dòng)進(jìn)程。

　　從桌面運(yùn)行應(yīng)用程序

　　在 Linux 中從桌面運(yùn)行圖形用戶界面 (GUI) 應(yīng)用程序與在 Windows 中沒多大區(qū)別。通常，您需要了解特定的桌面環(huán)境下應(yīng)用程序在菜單中是如何分組的。Linux 有足夠的桌面應(yīng)用程序，可用于各種任務(wù)。有一些應(yīng)用程序是 Linux 本機(jī)固有的，還有另外一些應(yīng)用程序可能是在一個(gè)常用運(yùn)行時(shí)環(huán)境中使用 C# 開發(fā)的跨平臺(tái)應(yīng)用程序，比如，.NET Framework 應(yīng)用程序。您會(huì)發(fā)現(xiàn)，使用一個(gè) Wine 這樣的虛擬環(huán)境，您甚至可以在 Linux 上運(yùn)行您最喜愛的 Windows 應(yīng)用程序。

　　您很有可能會(huì)為您最喜愛的基于 Windows 的應(yīng)用程序找到一個(gè)替代的 Linux 應(yīng)用程序。在桌面上運(yùn)行 Linux 本機(jī)應(yīng)用程序比較直觀。與 Windows 一樣，您通常可以在菜單中找到這些已組織的應(yīng)用程序，當(dāng)您想要一個(gè) Windows 應(yīng)用程序時(shí)，只需單擊并運(yùn)行即可。

　　對(duì)于那些需要 root 權(quán)限的應(yīng)用程序，將會(huì)提示您輸入 root 密碼，然后才開始運(yùn)行。這在概念上類似于 Windows 中的 Run as Administrator 選項(xiàng)。否則，您運(yùn)行的所有程序都會(huì)位于您所登錄帳戶的用戶空間中。

　　在 Windows 中，您可以創(chuàng)建桌面快捷鍵。Linux 也有類似的快捷鍵 launcher，您可以將它放在面板或桌面上。單擊 launcher 時(shí)，快捷鍵將執(zhí)行程序。

　　圖 1 顯示 GNOME Desktop 上 Mozilla Firefox Web 瀏覽器的兩個(gè) launcher。一個(gè) launcher 位于面板上，另一個(gè)位于桌面上。

　　圖 1. 查看桌面或面板上的 launcher

Mono

　　許多 Windows 應(yīng)用程序都是使用 .NET Framework 開發(fā)的。Mono 是 .NET 的一個(gè)開源實(shí)現(xiàn)，可在很多平臺(tái)上運(yùn)行（包括 linux）。事實(shí)上，Mono 網(wǎng)站稱其為 C# 和 Common Language Runtime （CLR） 的一個(gè)實(shí)現(xiàn)，與 .Net 是二進(jìn)制兼容的。此項(xiàng)目目前由 Xamarin 支持。

　　在 Linux 上，您可以執(zhí)行使用 .NET framework（或 Mono）開發(fā)的應(yīng)用程序，就像在 Windows 上一樣。但是，記住 Linux umask 和默認(rèn)文件權(quán)限。您仍然需要提供文件的執(zhí)行權(quán)限，這樣 Linux 才會(huì)允許執(zhí)行可執(zhí)行文件。

　　在 Mono（可以安裝在您的 Linux GNOME 桌面上）上開發(fā)的一些跨平臺(tái)應(yīng)用程序，比如 F-Spot，同本機(jī) GNOME 應(yīng)用程序一同位于菜單中。F-Spot 是一個(gè)管理照片的開源應(yīng)用程序。盡管它是 C# 應(yīng)用程序，但是在 GNOME 桌面上表現(xiàn)為一個(gè)本機(jī)應(yīng)用程序。為應(yīng)用程序創(chuàng)建一個(gè) launcher 后，就可以像在 Windows 中那樣單擊并運(yùn)行。

　　圖 2 演示了基于 Mono 的應(yīng)用程序 F-Spot 的位置，以及為其創(chuàng)建桌面或面板 launcher 的方法。

　　圖 2. 為 F-Spot 創(chuàng)建一個(gè) launcher

Wine

　　Wine 使您可以在 Linux 和其他操作系統(tǒng)上運(yùn)行 Windows 軟件。有了 Wine，您就可以像在 Windows 中那樣安裝和運(yùn)行應(yīng)用程序。Wine 仍然在積極的發(fā)展中，而且并不是所有的 Windows 程序都可以使用 Wine。如果您的應(yīng)用程序是為 Windows 操作系統(tǒng)編譯的，您就會(huì)發(fā)現(xiàn)它可以使用 Wine 來充分運(yùn)行，前題是它是一個(gè)桌面應(yīng)用程序而不是一個(gè)服務(wù)器應(yīng)用程序。一定要檢查 Wine 文檔關(guān)于在 Linux 上運(yùn)行該應(yīng)用程序的可行性，因?yàn)? Wine 并不完全支持所有的應(yīng)用程序。

　　當(dāng)您在 Linux 中使用 Wine 時(shí)，在您帳戶主目錄下有一個(gè)模擬 Windows 環(huán)境的隱藏文件夾，如 清單 4 所示。

　　清單 4. 模擬 Windows 環(huán)境的 Wine 的隱藏文件夾

　　使用 Wine 安裝一個(gè)應(yīng)用程序之后，您通常可以在桌面菜單中找到它，然后以在 Windows 中同樣的方式來運(yùn)行。

　　例如，Camstudio 是一個(gè)開源工具，用于記錄和管理屏幕視頻。目前還沒有 Linux 操作系統(tǒng)的版本。但是，使用 Wine 就可以在 Linux 桌面安裝 Windows 版本。與 Wine 相關(guān)的應(yīng)用程序通常分組為 Applications > Wine > Programs，如 圖 3 所示。

　　圖 3. 使用 Wine 在 Linux 上運(yùn)行一個(gè) Windows 應(yīng)用程序

　　結(jié)束語

　　在管理一個(gè) Linux 服務(wù)器時(shí)，您肯定會(huì)遇到從桌面和命令行執(zhí)行軟件的問題。了解如何設(shè)置適當(dāng)?shù)臋?quán)限和用戶帳戶后，您就可以安全地運(yùn)行這些應(yīng)用程序。使用長期運(yùn)行的進(jìn)程，比如 服務(wù)器服務(wù)，您可以從命令行執(zhí)行，并在后臺(tái)進(jìn)行適當(dāng)設(shè)置。如果您的應(yīng)用程序適合于從桌面運(yùn)行，也可以那樣做，有時(shí)候甚至可以是 Windows 應(yīng)用程序！

　　0、Java 中多線程同步是什么？

　　在多線程程序下，同步能控制對(duì)共享資源的訪問。如果沒有同步，當(dāng)一個(gè) Java 線程在修改一個(gè)共享變量時(shí)，另外一個(gè)線程正在使用或者更新同一個(gè)變量，這樣容易導(dǎo)致程序出現(xiàn)錯(cuò)誤的結(jié)果。

　　1、解釋實(shí)現(xiàn)多線程的幾種方法？

　　一 Java 線程可以實(shí)現(xiàn) Runnable 接口或者繼承 Thread 類來實(shí)現(xiàn)，當(dāng)你打算多重繼承時(shí)，優(yōu)先選擇實(shí)現(xiàn) Runnable。

　　2、Thread.start ()與 Thread.run ()有什么區(qū)別？

　　Thread.start ()方法(native)啟動(dòng)線程，使之進(jìn)入就緒狀態(tài)，當(dāng) cpu 分配時(shí)間該線程時(shí)，由 JVM 調(diào)度執(zhí)行 run ()方法。

　　3、為什么需要 run ()和 start ()方法，我們可以只用 run ()方法來完成任務(wù)嗎？

　　我們需要 run ()&start ()這兩個(gè)方法是因?yàn)?JVM 創(chuàng)建一個(gè)單獨(dú)的線程不同于普通方法的調(diào)用，所以這項(xiàng)工作由線程的 start 方法來完成，start 由本地方法實(shí)現(xiàn)，需要顯示地被調(diào)用，使用這倆個(gè)方法的另外一個(gè)好處是任何一個(gè)對(duì)象都可以作為線程運(yùn)行，只要實(shí)現(xiàn)了 Runnable 接口，這就避免因繼承了 Thread 類而造成的 Java 的多繼承問題。

　　4、什么是 ThreadLocal 類，怎么使用它？

　　ThreadLocal 是一個(gè)線程級(jí)別的局部變量，并非“本地線程”。ThreadLocal 為每個(gè)使用該變量的線程提供了一個(gè)獨(dú)立的變量副本，每個(gè)線程修改副本時(shí)不影響其它線程對(duì)象的副本(譯者注)。

　　下面是線程局部變量(ThreadLocal variables)的關(guān)鍵點(diǎn)：

　　一個(gè)線程局部變量(ThreadLocal variables)為每個(gè)線程方便地提供了一個(gè)單獨(dú)的變量。

　　ThreadLocal 實(shí)例通常作為靜態(tài)的私有的(private static)字段出現(xiàn)在一個(gè)類中，這個(gè)類用來關(guān)聯(lián)一個(gè)線程。

　　當(dāng)多個(gè)線程訪問 ThreadLocal 實(shí)例時(shí)，每個(gè)線程維護(hù) ThreadLocal 提供的獨(dú)立的變量副本。

　　常用的使用可在 DAO 模式中見到，當(dāng) DAO 類作為一個(gè)單例類時(shí)，數(shù)據(jù)庫鏈接(connection)被每一個(gè)線程獨(dú)立的維護(hù)，互不影響。(基于線程的單例)

　　ThreadLocal 難于理解，下面這些引用連接有助于你更好的理解它。

　　《Good article on ThreadLocal on IBM DeveloperWorks 》、《理解 ThreadLocal》、《Managing data ： Good example》、《Refer Java API Docs》

　　5、什么時(shí)候拋出 InvalidMonitorStateException 異常，為什么？

　 　調(diào)用 wait ()/notify ()/notifyAll ()中的任何一個(gè)方法時(shí)，如果當(dāng)前線程沒有獲得該對(duì)象的鎖，那么就會(huì)拋出 IllegalMonitorStateException 的異常(也就是說程序在沒有執(zhí)行對(duì)象的任何同步塊或者同步方法時(shí)，仍然嘗試調(diào)用 wait ()/notify ()/notifyAll ()時(shí))。由于該異常是 RuntimeExcpetion 的子類，所以該異常不一定要捕獲(盡管你可以捕獲只要你愿意).作為 RuntimeException，此類異常不會(huì)在 wait ()，notify ()，notifyAll ()的方法簽名提及。

　　Thread.sleep ()使當(dāng)前線程在指定的時(shí)間處于“非運(yùn)行”（Not Runnable）狀態(tài)。線程一直持有對(duì)象的監(jiān)視器。比如一個(gè)線程當(dāng)前在一個(gè)同步塊或同步方法中，其它線程不能進(jìn)入該塊或方法中。如果另一線程調(diào)用了 interrupt ()方法，它將喚醒那個(gè)“睡眠的”線程。

　　注意：sleep ()是一個(gè)靜態(tài)方法。這意味著只對(duì)當(dāng)前線程有效，一個(gè)常見的錯(cuò)誤是調(diào)用t.sleep ()，（這里的t是一個(gè)不同于當(dāng)前線程的線程）。即便是執(zhí)行t.sleep ()，也是當(dāng)前線程進(jìn)入睡眠，而不是t線程。t.suspend ()是過時(shí)的方法，使用 suspend ()導(dǎo)致線程進(jìn)入停滯狀態(tài)，該線程會(huì)一直持有對(duì)象的監(jiān)視器，suspend ()容易引起死鎖問題。

　　object.wait ()使當(dāng)前線程出于“不可運(yùn)行”狀態(tài)，和 sleep ()不同的是 wait 是 object 的方法而不是 thread。調(diào)用 object.wait ()時(shí)，線程先要獲取這個(gè)對(duì)象的對(duì)象鎖，當(dāng)前線程必須在鎖對(duì)象保持同步，把當(dāng)前線程添加到等待隊(duì)列中，隨后另一線程可以同步同一個(gè)對(duì)象鎖來調(diào)用 object.notify ()，這樣將喚醒原來等待中的線程，然后釋放該鎖。基本上 wait ()/notify ()與 sleep ()/interrupt ()類似，只是前者需要獲取對(duì)象鎖。

　　7、在靜態(tài)方法上使用同步時(shí)會(huì)發(fā)生什么事？

　　同步靜態(tài)方法時(shí)會(huì)獲取該類的“Class”對(duì)象，所以當(dāng)一個(gè)線程進(jìn)入同步的靜態(tài)方法中時(shí)，線程監(jiān)視器獲取類本身的對(duì)象鎖，其它線程不能進(jìn)入這個(gè)類的任何靜態(tài)同步方法。它不像實(shí)例方法，因?yàn)槎鄠€(gè)線程可以同時(shí)訪問不同實(shí)例同步實(shí)例方法。

　　8、當(dāng)一個(gè)同步方法已經(jīng)執(zhí)行，線程能夠調(diào)用對(duì)象上的非同步實(shí)例方法嗎？

　　可以，一個(gè)非同步方法總是可以被調(diào)用而不會(huì)有任何問題。實(shí)際上，Java 沒有為非同步方法做任何檢查，鎖對(duì)象僅僅在同步方法或者同步代碼塊中檢查。如果一個(gè)方法沒有聲明為同步，即使你在使用共享數(shù)據(jù) Java 照樣會(huì)調(diào)用，而不會(huì)做檢查是否安全，所以在這種情況下要特別小心。一個(gè)方法是否聲明為同步取決于臨界區(qū)訪問(critial section access)，如果方法不訪問臨界區(qū)(共享資源或者數(shù)據(jù)結(jié)構(gòu))就沒必要聲明為同步的。

　　下面有一個(gè)示例說明：Common 類有兩個(gè)方法 synchronizedMethod1()和 method1()，MyThread 類在獨(dú)立的線程中調(diào)用這兩個(gè)方法。

字體:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿 

　　10、什么是死鎖

　　死鎖就是兩個(gè)或兩個(gè)以上的線程被無限的阻塞，線程之間相互等待所需資源。這種情況可能發(fā)生在當(dāng)兩個(gè)線程嘗試獲取其它資源的鎖，而每個(gè)線程又陷入無限等待其它資源鎖的釋放，除非一個(gè)用戶進(jìn)程被終止。就 JavaAPI 而言，線程死鎖可能發(fā)生在一下情況。

　　● 當(dāng)兩個(gè)線程相互調(diào)用 Thread.join()

　　● 當(dāng)兩個(gè)線程使用嵌套的同步塊，一個(gè)線程占用了另外一個(gè)線程必需的鎖，互相等待時(shí)被阻塞就有可能出現(xiàn)死鎖。

　　11、什么是線程餓死，什么是活鎖？

　　線程餓死和活鎖雖然不想是死鎖一樣的常見問題，但是對(duì)于并發(fā)編程的設(shè)計(jì)者來說就像一次邂逅一樣。

　　當(dāng)所有線程阻塞，或者由于需要的資源無效而不能處理，不存在非阻塞線程使資源可用。JavaAPI 中線程活鎖可能發(fā)生在以下情形：

　　● 當(dāng)所有線程在程序中執(zhí)行 Object.wait(0)，參數(shù)為 0 的 wait 方法。程序?qū)l(fā)生活鎖直到在相應(yīng)的對(duì)象上有線程調(diào)用 Object.notify()或者 Object.notifyAll()。

　　● 當(dāng)所有線程卡在無限循環(huán)中。

　　這里的問題并不詳盡，我相信還有很多重要的問題并未提及，您認(rèn)為還有哪些問題應(yīng)該包括在上面呢？歡迎在評(píng)論中分享任何形式的問題與建議。

相關(guān)鏈接：

Java程序員集合框架面試題

　　四、需求分析→數(shù)據(jù)庫設(shè)計(jì)

　　從這開始，就真正進(jìn)入項(xiàng)目實(shí)戰(zhàn)啦。先說點(diǎn)體會(huì)，我剛開始接觸編程的時(shí)候，都是編寫一些小東西，往往都是半天或者一天什么的就編完了，那時(shí)候根本沒想過做程序之前還要有需求分析。經(jīng)過快兩年的學(xué)習(xí)， 接觸的都是比較大的系統(tǒng)，才明白沒有需求分析的程序都太業(yè)余了，沒有任何技術(shù)含量。對(duì)于一個(gè)系統(tǒng)來說，如果需求分析不到位，那么將有災(zāi)難性的后果，從這節(jié) 的小標(biāo)題就能看出，需求是數(shù)據(jù)庫設(shè)計(jì)的基石，需求定了，數(shù)據(jù)庫基本上就定了，數(shù)據(jù)庫定了，程序的基本功能也就定了。我們以一個(gè)簡(jiǎn)單的學(xué)生管理系統(tǒng)為例子， 來分析一下需求。分析需求地球人一般都是用UML圖，啥是UML圖呢，就是一種把程序用圖形表示的標(biāo)準(zhǔn)，它可以表示需求、程序流程、程序模塊、程序功能等 等，可以說，UML圖畫完了，程序基本上就出來了，目前比較好的畫UML的工具是Rational rose，不多說啦，剩下的就交給google了。本系統(tǒng)的需求非常簡(jiǎn)單，就是老師可以添加、刪除、修改學(xué)生記錄，學(xué)生的記錄包括：學(xué)號(hào)、年級(jí)、班級(jí)、姓名、性別、年齡、備注（這些就是字段）。根據(jù)這些敘述，我們可以畫出UML用例圖（用例圖就是用來分析需求的）：

　 　根據(jù)需求分析我們就可以設(shè)計(jì)數(shù)據(jù)庫了，非常“簡(jiǎn)單”嘛，需要一個(gè)表就行了，把它命名為student表，里邊添加剛剛提的那些字段就可以了。注意，數(shù)據(jù) 庫中的一切，包括：數(shù)據(jù)庫名、表名、字段名、存儲(chǔ)過程等等，都要用英文，不可以出現(xiàn)中文，因?yàn)樵凼菍I(yè)菜鳥，不走業(yè)余路。接著往下看，教你如何創(chuàng)建數(shù)據(jù) 庫。

　　作為專業(yè)教程，俺不會(huì)教你用鼠標(biāo)建立數(shù)據(jù)庫，咱們要用T-SQL語句建立數(shù)據(jù)庫，也就是寫數(shù)據(jù)庫腳本。這樣建立數(shù)據(jù)庫，相當(dāng)于留了個(gè)備份，無論到哪，只要有SQL環(huán)境，直接執(zhí)行一下腳本數(shù)據(jù)就建好了，非常方便快捷，就算是第一次寫腳本，也比用鼠標(biāo)建立數(shù)據(jù)庫快。在大型系統(tǒng)開發(fā)時(shí)，腳本還可以作為數(shù)據(jù)庫維護(hù)的依據(jù)，非常有用。那么怎樣寫呢，打開SQL server 2005 Management Studio，輸入帳號(hào)密碼登錄平臺(tái)，然后點(diǎn)一下左上角的"新建查詢"就可以打開查詢分析器了，我們可以在這輸入任何SQL語句。

　　第一步先創(chuàng)建數(shù)據(jù)庫，我先把創(chuàng)建數(shù)據(jù)庫的標(biāo)準(zhǔn)格式給大家：

　　相信看著這個(gè)很多人都蒙了，簡(jiǎn)單說一下，其實(shí)這么多代碼，也就第一句最重要，意思是創(chuàng)建一個(gè)名字叫studentManager的數(shù)據(jù)庫。On primary下邊的是對(duì)數(shù)據(jù)庫的一些初始設(shè)置，比如：路徑、初始大小、增量等等。Log on下邊的是對(duì)數(shù)據(jù)庫日志的 設(shè)置，也是那么幾項(xiàng)。很明確的告訴大家，除非是特殊需求，否則我們沒必要管那么多，默認(rèn)的就夠咱們用了，創(chuàng)建數(shù)據(jù)庫就一句話：create database studentManager，輸入完后點(diǎn)一下工具欄上的“執(zhí)行”，就搞定啦。數(shù)據(jù)庫建完了，就該在數(shù)據(jù)庫里建表了，還是先給出代碼：

   --指定數(shù)據(jù)庫
   use t_studentManager;

   --創(chuàng)建t_student表
   create table t_student
   (
   number varchar(20) PRIMARY KEY, --PRIMARY KEY 是主鍵約束
   grade varchar(10) NOT NULL, --NOT NULL是非空約束
   class varchar(10) NOT NULL,
   [name] varchar(20) NOT NULL, --name屬于sql保留字，所以用方括號(hào)括起來
   sex varchar(1) NOT NULL CHECK(sex in ('男','女')), --CHECK約束，意思是性別字段只能是男或女。
   age int NOT NULL,
   remark varchar(100),
   addTime datetime DEFAULT(getdate())--默認(rèn)值約束，getdate()獲取服務(wù)器時(shí)間
   );

　　create table當(dāng)然就是建表的意思了，在表名前最好加一個(gè)“t_”，表示是表（table），這樣容易區(qū)分，而且專業(yè)。括號(hào)里的就是這個(gè)表中的字段，格式是： 字段名類型 約束，注意每個(gè)字段寫完后邊都要加逗號(hào)（最后一個(gè)就不用加啦），表示分隔。舉這個(gè)例子，約束用的還是比較全的，重點(diǎn)說說約束。約束可是數(shù)據(jù)庫中相當(dāng)重要的 東西，它保證了數(shù)據(jù)庫的安全和穩(wěn)定，同時(shí)也保證了數(shù)據(jù)完整性。約束主要有6種，分別是：NOT NULL約束（非空約束）、PRIMARY KEY約束（主鍵約束）、FOREIGN KEY約束（外鍵約束）、UNIQUE約束（唯一約束）、CHECK約束（檢查約束）、DEFAULT約束（默認(rèn)值約束）。這些約束可以用在任何字段的后 邊，一個(gè)字段也可以有多個(gè)約束，用空格分隔即可，比如上邊的sex字段，就同時(shí)使用了非空約束和檢查約束。當(dāng)然，有些約束只能用一次，比如主鍵約束。我只 是提了一下這些常用約束，大家了解我的目的就達(dá)到了，以后具體用到，再去google，就怕你不知道有這些約束。在查詢分析器中執(zhí)行這段代碼，表就建立好 了，提示一下：SQL查詢分析器可以選中執(zhí)行，也就是你選中那些代碼就執(zhí)行那些代碼，建表的時(shí)候注意不要再次執(zhí)行建數(shù)據(jù)庫的語句哦。

　　五、優(yōu)化數(shù)據(jù)庫。

　　數(shù)據(jù)庫設(shè)計(jì)是程序的根基，也是一門藝術(shù)。上一節(jié)我們?cè)O(shè)計(jì)的數(shù)據(jù)庫，太隨意了，什么都沒有考慮，作為專業(yè)菜鳥，這樣是不行的。

　　優(yōu)化數(shù)據(jù)庫，先要了解數(shù)據(jù)庫設(shè)計(jì)三范式，簡(jiǎn)單說下：

　　1、第一范式：是指數(shù)據(jù)庫表的每一列都是不可分割的基本數(shù)據(jù)項(xiàng)，同一列中不能有多個(gè)值，即實(shí)體中的某個(gè)屬性不能有多個(gè)值或者不能有重復(fù)的屬性。

　　2、第二范式：第二范式需要確保數(shù)據(jù)庫表中的每一列都和主鍵相關(guān)，而不能只與主鍵的某一部分相關(guān)（主要針對(duì)聯(lián)合主鍵而言）。

　　3、第三范式：第三范式需要確保數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。

　　這三個(gè)范式大致的意思就是：數(shù)據(jù)庫中表的職責(zé)要單一，依賴關(guān)系明確，盡量減少數(shù)據(jù)庫數(shù)據(jù)冗余。從網(wǎng)上查，可以查到很多個(gè)人理解，我在這也不理解 了，核心思想就是我剛剛說的。我首先聲明，三范式只是一個(gè)整體的指導(dǎo)思想，并不可能完全遵從，有時(shí)候數(shù)據(jù)冗余未必是壞事，要考慮實(shí)際情況。

　　很明顯，剛剛我們?cè)O(shè)計(jì)的數(shù)據(jù)庫不符合三范式的要求。在此表中學(xué)生應(yīng)該依賴的是學(xué)號(hào)，而我們冒昧的把班級(jí)、年級(jí)也放在了這里，學(xué)生當(dāng)然也應(yīng)該依賴 于班級(jí)、年級(jí)。這樣一來，表就亂了，造成的直接后果就是數(shù)據(jù)不完整，比如我們由于失誤，插入了一個(gè)年級(jí)是100的學(xué)生，而根本就沒有100這個(gè)班級(jí)。這樣 還有個(gè)比較大的問題就是數(shù)據(jù)冗余，因?yàn)槲覀兠坎迦胍粋€(gè)學(xué)生，不得不記錄一次班級(jí)、年級(jí)，造成大量無用數(shù)據(jù)。所以我們要改，要把一個(gè)表拆成三個(gè)，分別是：年 級(jí)表、班級(jí)表、學(xué)生表。這樣一來，數(shù)據(jù)庫就顯得漂亮多了。剛剛是一個(gè)表，我們還應(yīng)付得過來，現(xiàn)在三個(gè)表，記不住了怎么辦？別急，剛剛提到了UML圖，它可 以用來設(shè)計(jì)數(shù)據(jù)庫。在程序設(shè)計(jì)過程中，數(shù)據(jù)庫中的每一個(gè)表，都會(huì)在程序中映射成一個(gè)類，而表中的每一個(gè)字段，都是類中的一個(gè)屬性，它們的類型是一致的，我 們管他叫做實(shí)體類（可以提前google一下三層架構(gòu)哦），這時(shí)我們可以借助于UML中的類圖畫出數(shù)據(jù)庫的結(jié)構(gòu)。如下圖：

　　在講代碼之前，必須先說什么是外鍵約束，外鍵約束就是：A表的某個(gè)字段用到了B表的主鍵字段，那么A表中的這個(gè)字段就叫外鍵，A、B兩個(gè)表間的 約束關(guān)系就叫外鍵約束。A表的外鍵字段必須依賴于B表的主鍵字段，如果向A表外鍵字段中添加一個(gè)B表主鍵字段中不存在的數(shù)據(jù)，那么將失敗。外鍵約束保證了 數(shù)據(jù)的完整性和合理性。

　　這段代碼，我還是要重點(diǎn)說說約束，與上一次創(chuàng)建表不同的是，不僅僅是表多了，而且最后多了外鍵約束，CONSTRAINT是創(chuàng)建一個(gè)約束，后邊 接約束名；FOREIGN KEY代表該約束是外鍵約束，括號(hào)里寫字段名，代表這個(gè)字段是外鍵；REFERENCES是參考的意思，也就是參考哪個(gè)表里的哪個(gè)字段，也就是主鍵在哪， 后邊接"表名(字段名)"。其實(shí)我是故意把它寫在最后的邊的，外鍵約束也是約束，完全可以放在字段定義的最后邊，也就是NOT NULL那個(gè)位置上，我這樣寫是想告訴大家還有另一種寫法，所有的約束都可以類似這樣寫，就是換個(gè)位置，我現(xiàn)在提出來避免大家以后見到發(fā)蒙。需要注意的 是，創(chuàng)建表的括號(hào)里，無論是寫約束還是寫字段，都要用逗號(hào)分隔，千萬別忘了。

　　● 作者的研究表明，網(wǎng)頁響應(yīng)時(shí)間約80%-90%是由前端設(shè)計(jì)決定的。而我的經(jīng)驗(yàn)中，這個(gè)數(shù)字更應(yīng)該是50%-80%，但我的經(jīng)驗(yàn)多來自于那些被重新設(shè)計(jì)為WEB架構(gòu)的多用戶應(yīng)用，或者是那些有著嚴(yán)重后端性能問題的應(yīng)用（請(qǐng)我來定位問題）。

　　● 和性能測(cè)試人員有關(guān)的幾乎所有的工具、培訓(xùn)、文章和會(huì)議，都集中在系統(tǒng)的后端。以至于大部分人認(rèn)為，系統(tǒng)的前端性能無需擔(dān)心，因?yàn)槲覀儫o法控制客戶端的系統(tǒng)。

　　● 根據(jù)我的經(jīng)驗(yàn)，網(wǎng)站的前端設(shè)計(jì)和開發(fā)，幾乎不會(huì)考慮到性能問題，除了盡量減小圖片的大小。我也從未讓團(tuán)隊(duì)做過客戶端頁面的HTML代碼審查，從未在這些代碼上做過單元測(cè)試，也從未見過測(cè)試人員有意的對(duì)HTML進(jìn)行一些性能測(cè)試。

　 　結(jié)合上面幾點(diǎn)，你將得知，沒有人關(guān)注頁面上的可能存在的性能優(yōu)化，而這種優(yōu)化很可能是最容易實(shí)現(xiàn)，效果卻又最明顯的。讀了這本書我發(fā)現(xiàn)，我經(jīng)常對(duì)大多數(shù) 的前端性能問題進(jìn)行測(cè)試，但自己卻沒有意識(shí)到。作者提到的一些內(nèi)容，我可能永遠(yuǎn)也不會(huì)想到去測(cè)試，不對(duì)這些內(nèi)容進(jìn)行更主動(dòng)的測(cè)試是個(gè)錯(cuò)誤，這些測(cè)試的成本 是非常低的，無論是在時(shí)間上，還是在所需的工具和資源上。實(shí)際上，在測(cè)試網(wǎng)站的時(shí)候，我經(jīng)常拿出整個(gè)性能測(cè)試的前15分鐘來完成大部分的前端測(cè)試，雖然我 承認(rèn)，15分鐘只夠測(cè)試幾個(gè)頁面。

　　通過這篇文章，我講解了如何通過手工、負(fù)載生成工具、網(wǎng)絡(luò)協(xié)議分析工具、助手網(wǎng)站以及瀏覽器插件，來進(jìn)行測(cè)試。我已經(jīng)通過以下免費(fèi)工具（不是免費(fèi)試用版，是無任何限制的免費(fèi)版）完成了這些工作。 如果你的公司不允許使用免費(fèi)軟件，我相信只要簡(jiǎn)單的搜索一下，就可以找到一堆可以替代的工具，這些工具將花費(fèi)你公司足夠多的錢，從而讓他們重視。（如果你 認(rèn)為這只是個(gè)笑話，很可惜它不是。在咨詢過我的團(tuán)隊(duì)和接受我培訓(xùn)的個(gè)人中，有超過50%的人說過不允許在公司的機(jī)器和網(wǎng)絡(luò)上使用免費(fèi)、開源、共享、甚至是 有時(shí)間限制的免費(fèi)試用版軟件。）

　　● 免費(fèi)或者開源的負(fù)載生成工具

　　　　○ JMeter (http://jakarta.apache.org/jmeter/)
　　　　○ WebLoad (http://www.webload.org/)
　　　　○ OpenSTA (http://www.opensta.org/)

　　● 免費(fèi)或者開源的網(wǎng)絡(luò)協(xié)議分析工具

　　　　○ Ethereal (http://www.ethereal.com/)
　　　　○ Fiddler (http://www.fiddlertool.com/)

　　● 免費(fèi)的瀏覽器插件

　　　　○ Firebug (http://www.getfirebug.com/) with YSlow (http://developer.yahoo.com/yslow/) for 　　　Firefox
　　　　○ HttpWatch (http://www.httpwatch.com) for IE

　　● 免費(fèi)的助手網(wǎng)站

　 　　　○ Web Page Analyzer - from Website Optimization: Free Website Performance Tool and Web 　　Page Speed Analysis (http://www.websiteoptimization.com/services/analyze/)
　　　　○ Gomez Instant Site Test (http://www.gomez.com/info_center/instant_test.php)

　　有了這些，讓我們來看一些你只需看完本文能做的測(cè)試，這些測(cè)試只需在web層面上即可進(jìn)行，卻可能會(huì)顯著的改善終端用戶的響應(yīng)時(shí)間。

　　HTTP請(qǐng)求數(shù)

　 　頁面的獲取不是在一個(gè)事務(wù)中完成的。通常HTML文件需要一個(gè)請(qǐng)求，樣式表需要一個(gè)或多個(gè)請(qǐng)求，外部腳本需要一個(gè)或多個(gè)請(qǐng)求，圖片、多媒體內(nèi)容、以及第 三方那個(gè)內(nèi)容如廣告等需要多個(gè)請(qǐng)求。即使很多對(duì)象已經(jīng)存在于瀏覽器緩存中了，還是需要頻繁的向服務(wù)器發(fā)送請(qǐng)求，以確認(rèn)緩存中的對(duì)象是否“fresh”。這 意味著頁面上的每一個(gè)對(duì)象都十分可能會(huì)增加負(fù)擔(dān)，進(jìn)而在用戶視角上降低了了性能，即使客戶端的瀏覽器已經(jīng)緩存了所需的對(duì)象。如下幾種途徑，可以確定頁面發(fā) 送了多少個(gè)請(qǐng)求，以及請(qǐng)求的內(nèi)容。

　　無論你用哪種方法，你將首先清除掉瀏覽器的緩存，或者訪問頁面兩次（一次通過ctrl + F5來強(qiáng)制刷新緩存）以確保能夠看到所有的請(qǐng)求。因?yàn)檫@些方法只能收集到真實(shí)的請(qǐng)求，如果不清除或刷新緩存可能會(huì)導(dǎo)致一些遺漏，讓你以為沒有去請(qǐng)求一些樣 式表、腳本、圖片和多媒體內(nèi)容，很多配置或條件會(huì)對(duì)此產(chǎn)生影響，而你可能不知道要去設(shè)置這些。

　　1、如果你使用了負(fù)載生成工具或者網(wǎng)絡(luò)協(xié) 議分析工具，你可以直接開始錄制了，然后瀏覽感興趣的頁面。在你錄制的內(nèi)容中尋找“GET”語句，看一下請(qǐng)求了什么。記住，有些工具，錄制下來的腳本默認(rèn) 只顯示基礎(chǔ)的HTML請(qǐng)求，不包括子請(qǐng)求（對(duì)樣式表、圖片、腳本等的請(qǐng)求），如果要看到所有的請(qǐng)求需要進(jìn)一步的設(shè)置。

　　2、如果你的測(cè)試環(huán)境允許裝瀏覽器插件，那么有好幾種方法可以使這個(gè)工作變得簡(jiǎn)單。根據(jù)你所用的瀏覽器，或者希望測(cè)的瀏覽器，我推薦：

　　a）FireFox：FireBug+YSlow

　　b）IE： HttpWatch

　　a）訪問上面列出的一個(gè)助手網(wǎng)站，輸入你想測(cè)試的頁面的URL，點(diǎn)提交。

　　b）FireFox中，右擊頁面，選Page Info，導(dǎo)航至Media Tab。注意，這個(gè)方法不會(huì)顯示腳本和樣式表，但會(huì)顯示出請(qǐng)求的圖片和其他多媒體內(nèi)容。

　　c）IE中，右擊頁面然后選擇View Source。這里，你需要搜尋“link”和“img”字段。如果你找到了樣式表的連接（到.css文件的連接），你還需要手動(dòng)的下載每個(gè)樣式表，然后 在其中搜索“url”字樣，因?yàn)檫@些可能會(huì)用來請(qǐng)求腳本、圖片和多媒體內(nèi)容。（這是目前為止最笨的方法，但仍能為你提供信息）

　　有了你的請(qǐng)求列表以后，第一件事要做的就是看看數(shù)量——過多的請(qǐng)求會(huì)讓頁面變慢。有如下幾個(gè)指標(biāo)來判斷是否是過多的請(qǐng)求。

　　1、外部樣式表請(qǐng)求多于一個(gè)。確實(shí)有一些時(shí)候是應(yīng)該將頁面樣式拆分成幾個(gè)樣式表，但這情況并不常見，而且對(duì)性能顯然沒有好處。一般來說，只有當(dāng)有一個(gè)主樣式表應(yīng)用到很多頁面，第二個(gè)大的樣式表只應(yīng)用到幾個(gè)頁面時(shí)，保留多于一個(gè)樣式表才是個(gè)好方法。

　　2、同一域中腳本的請(qǐng)求多于一個(gè)。雖然連接多個(gè)外部腳本比連接多個(gè)樣式表有更好的理由，多個(gè)外部腳本連接比 一個(gè)連接性能更好，仍然是不常見的。如果你測(cè)試的頁面是一個(gè)復(fù)雜的數(shù)據(jù)輸入表單，那么將表單的驗(yàn)證腳本同其他頁面的通用腳本分離可能會(huì)有些意義。這樣做會(huì) 減少其他頁面（除了表單）的大小，從而改善那些頁面的性能，但多出的請(qǐng)求還是會(huì)輕微的降低表單頁面的性能。不管如何，多于一個(gè)外部腳本，至少是值得注意一 下的。

　　3、大量的圖片。我沒法說“大量的”是多少，但我可以告訴你，IE7和FireFox 2.x默認(rèn)每主機(jī)名可以有2個(gè)并行下載（HTTP/1.1，大部分新網(wǎng)站都是）。這意味著，不管你的圖片大小是多少，瀏覽器一次只能下載兩個(gè)，只有當(dāng)之前 的兩個(gè)都處理完，才會(huì)開始接下來的兩個(gè)。在HTTP/1.0中是不同的，F(xiàn)ireFox默認(rèn)每主機(jī)名可以有8并行下載，IE各版本不同，但肯定不會(huì)低于 2。這種變化產(chǎn)生的效果就是，使用類似大小但是數(shù)量最少的圖片易于產(chǎn)生最佳的性能。這和小圖片總是好的那種觀點(diǎn)是相反的。將幾個(gè)小圖片合成一個(gè)或兩個(gè)大些 的圖片，通常會(huì)改善性能。當(dāng)然，這就又會(huì)出現(xiàn)一個(gè)臨界點(diǎn)。圖片大小和圖片的數(shù)量是值得前端工程師仔細(xì)研究的，測(cè)試多種選擇以達(dá)到最佳性能。有一個(gè)廣受好評(píng) 的“rull-of-thumb”（提供類似問題的指導(dǎo)），奉勸當(dāng)一個(gè)頁面超過12個(gè)請(qǐng)求時(shí)，一定要謹(jǐn)慎。Souders的這本書和Andrew B. King的in Speed Up Your Site： Web Site Optimization（New Riders， 2003）中都采用了這個(gè)數(shù)字，而Aaron Hopkins在網(wǎng)站上發(fā)表的文章“Optimizing Page Load Time”讓這個(gè)數(shù)字更有說服力。

　　HTTP請(qǐng)求的順序

　　很多類似的方法都可以用來確定頁面上請(qǐng)求的順序（前面提到的助手網(wǎng)站和FireFox的“Page Info”除外，為了突出數(shù)量和大小等問題，將請(qǐng)求按類型或者大小進(jìn)行了分組和排序）。我們所關(guān)注的順序是：

　　1、首先請(qǐng)求樣式表。在樣式表下載完之前，頁面是不會(huì)顯示的。或者是下載完樣式表要重新刷新頁面。基于這一點(diǎn)，讓樣式表在HTML頁面之后第一批請(qǐng)求是非常重要的。

　　2、最后請(qǐng)求腳本（至少是要靠后）。當(dāng)開始請(qǐng)求一個(gè)腳本的時(shí)候，在腳本完全下載完之前不會(huì)再發(fā)出對(duì)其他對(duì)象 的請(qǐng)求。此外，腳本下載過程中，瀏覽器將暫停顯示頁面內(nèi)容。這意味著在腳本下載過程中完成的任何對(duì)象的下載，都不會(huì)被顯示出來，從而給人感覺頁面的展現(xiàn)停 止了。所以一定要把腳本的請(qǐng)求放到用戶最感興趣的對(duì)象之后。記住，大多數(shù)用戶眼中的響應(yīng)速度是由他們感興趣的內(nèi)容決定的，而不是整個(gè)頁面的載入時(shí)間。

　　不管你是看HTML源文件還是錄制請(qǐng)求，你需要關(guān)注的就是樣式表最先被請(qǐng)求，腳本在最后或者至少是非常靠后時(shí)請(qǐng)求。有一個(gè)常見的爭(zhēng)論，說負(fù)責(zé)與 用戶交互的腳本（如圖像映射、對(duì)象反轉(zhuǎn)）應(yīng)該早些被請(qǐng)求，這樣用戶會(huì)有更好的體驗(yàn)，即便整個(gè)頁面還正在下載過程中。但我的經(jīng)驗(yàn)里，由于下載而產(chǎn)生的頁面停 止比無法獲得圖像映射、對(duì)象反轉(zhuǎn)功能更容易使用戶變得焦躁甚至是離開頁面。

　　重定向和隱藏錯(cuò)誤

　　你仍然可以使用相同的方法來檢查重定向問題（3xx狀態(tài)碼），客戶錯(cuò)誤（4xx），和服務(wù)器錯(cuò)誤（5xx）。這里，你關(guān)注的信息是：

　　1、過多的3xx。3xx狀態(tài)表示，請(qǐng)求被處理了，但是瀏覽器需要到另一個(gè)地址去獲取所需對(duì)象，這就產(chǎn)生了 附加的請(qǐng)求和響應(yīng)。雖然有很多的原因可以使用重定向，檢查一下是否有意使用和存在好理由還是值得做的。比如，將一個(gè)刪除掉的頁面重定向到新地址，或者將明 顯拼錯(cuò)的頁面重定向到正確的地址，這就是個(gè)好的使用理由。圖片的父級(jí)目錄被移動(dòng)了，沒有人去維護(hù)更新鏈接，這就不是一個(gè)需要使用重定向、從而接受一些性能 下降的好理由。

　　2、任何4xx。用戶的請(qǐng)求有問題時(shí)就會(huì)返回4xx狀態(tài)碼。最常見的是404，表示服務(wù)器上找不到被請(qǐng)求的對(duì)象。一般說來，如果頁面的顯示和功能都正常，但請(qǐng)求卻返回了4xx，那就說明頁面請(qǐng)求了不需要的對(duì)象，也耗費(fèi)了多余的時(shí)間。

　　3、任何5xx。5xx表示處理請(qǐng)求時(shí)，服務(wù)器上發(fā)生了錯(cuò)誤。任何5xx的狀態(tài)都需要開發(fā)團(tuán)隊(duì)注意。

　　我將這些都稱作隱藏錯(cuò)誤，是因?yàn)楫?dāng)它們發(fā)生在非主HTML上時(shí)，用戶通常是察覺不到的。有時(shí)，這些狀態(tài)碼預(yù)示著有更深層的錯(cuò)誤，但是無論如何，它們都導(dǎo)致了與頁面內(nèi)容無關(guān)的請(qǐng)求，這些請(qǐng)求通常也都是完全沒有必要的。

　　要檢查HTTP響應(yīng)頭，需要使用負(fù)載生成工具、網(wǎng)絡(luò)分析工具或者是瀏覽器插件。如果你沒有這些工具，一個(gè)助手網(wǎng)站可以幫到你。我推薦Peter Forret的網(wǎng)站“View and analyze HTTP headers” （http：//web.forret.com/tools/analyze.aspx），你只需輸入頁面的URL，網(wǎng)站就會(huì)獲取到web服務(wù)器返回的一 系列HTTP頭，這樣就可以檢查頁面過期和緩存等配置了。至于具體哪些是合適的、哪些是不不要的性能損失，這是和很多內(nèi)容息息相關(guān)的，如網(wǎng)頁和對(duì)象變化的 頻率、用戶訪問網(wǎng)站的頻率、還有用戶看到過時(shí)內(nèi)容的相對(duì)風(fēng)險(xiǎn)。但是不管怎樣，下面的這些是永遠(yuǎn)值得檢查的：

　　1、過期時(shí)間是否恰當(dāng)。如果一個(gè)對(duì)象的HTTP響應(yīng)中沒有過期時(shí)間這行，每次用戶請(qǐng)求包含這個(gè)對(duì)象的頁面 時(shí)，都會(huì)向服務(wù)器發(fā)送一個(gè)請(qǐng)求，來判斷緩存的這個(gè)版本是否“新鮮”。如果你有一些不易過期的對(duì)象（如公司的Logo），你可以通過設(shè)置一個(gè)未來很遠(yuǎn)的日期 來避免這種有效性檢查。過期時(shí)間最多應(yīng)用在圖片上，但在腳本、樣式表、AJAX和FLASH等內(nèi)容上也經(jīng)常是適用的。檢查一下沒有過期時(shí)間的對(duì)象吧，看看 是不是有不合適的。

　　2、ETags是否恰當(dāng)。ETags是一種web服務(wù)器和瀏覽器使用的認(rèn)證手段，用來判斷客戶機(jī)器上緩存的 對(duì)象是否和服務(wù)器上的匹配。使用ETags的問題在于，它們對(duì)于一個(gè)特定的服務(wù)器通常是唯一的，這意味著如果網(wǎng)站有多個(gè)web服務(wù)器，ETags是會(huì)出現(xiàn) 問題的。如果你確定只有一個(gè)web服務(wù)器，那么使用ETags是個(gè)不錯(cuò)的主意。如果是多個(gè)服務(wù)器，你就必須查明是否考慮到了這點(diǎn)，或者干脆建議不使用 ETags。

　　3、其他緩存控制。你可能會(huì)看到類似的內(nèi)容，Cache-Control、Last-Modified、Pragma、Set-Cookie、Age。如果你看到了，那么確保這些配置是有意義的。如果沒有找到，而你又覺得應(yīng)該有這些東西，那么找人看一下吧。

　　說到底，其實(shí)本質(zhì)內(nèi)容就是你要檢查HTTP響應(yīng)頭，來判斷網(wǎng)站是否已被合理配置來利用瀏覽器的緩存。通常，判斷這些配置是否恰當(dāng)?shù)奈ㄒ环椒ǎ峭芾韱T和架構(gòu)師探討網(wǎng)站是如何使用的、以及是如何設(shè)計(jì)的，尤其是和瀏覽器緩存有關(guān)的地方。

　　源文件和其他對(duì)象

　　最后，如果你沒以前沒做過這些，你需要手工檢查HTML源文件、css、腳本、圖片以及其他對(duì)象。到現(xiàn)在，我還沒發(fā)現(xiàn)任何一款能夠節(jié)省我們的時(shí) 間、對(duì)各種情況做出充分檢查、并對(duì)前端性能提出建議的工具，雖然一些網(wǎng)站使用的HTML、腳本、圖片的編輯器還是有一些幫助的。最后，關(guān)于前端性能測(cè)試， 我的建議是：

　　1、確保腳本和CSS沒有寫在HTML源文件中。將腳本和CSS直接寫在HTML中來提高性能，幾乎是不可 能的。原因很簡(jiǎn)單：網(wǎng)頁的主HTML是更新最為頻繁的部分之一，因此從緩存中受益最少。既然HTML很可能每次都要下載，只有盡量減小大小才是上策。將腳 本和CSS與HTML分離，以便利用緩存，是肯定會(huì)提高性能的。

　　2、確保樣式和腳本不重復(fù)。樣式和腳本包含重復(fù)內(nèi)容是非常惡心的。有時(shí)，不同的文件中有重復(fù)內(nèi)容，有時(shí)在同一個(gè)文件中就會(huì)重復(fù)。你可能不想花費(fèi)時(shí)間去做一個(gè)全面檢查，那么只需快速的掃描一遍源文件，經(jīng)常就能發(fā)現(xiàn)是否存在明顯的重復(fù)。

　　3、檢查代碼最小化。最小化，指壓縮和優(yōu)化代碼，讓相關(guān)功能使用最少的代碼行數(shù)。當(dāng)檢查HTML源文件、外部腳本和樣式表時(shí)，需要注意過多的注釋、空格、換行、變量名長度、以及其他能夠增加文件大小的內(nèi)容。

　　4、檢查圖片的大小和壓縮。雖然大家都明白，仍然還有很多網(wǎng)頁設(shè)計(jì)者使用這樣一些圖片格式，要么有不必要的 文件大小、要么是同顯示尺寸不同的尺寸、要么就是超過了所需要的品質(zhì)。通常，GIF格式的圖片是被壓縮成64位甚至更少顏色的，它們完全滿足大部分的圖片 和縮略圖；JPG格式的圖片被壓縮成256位或者更少，對(duì)于照片來說也完全夠用；通過HTML的height/width屬性來縮放圖片，不如創(chuàng)建再一個(gè) 新的大小的圖片。

　　這些內(nèi)容，靠常識(shí)判斷即可。例如，一些網(wǎng)站將所有的文件、目錄以及變量的名字減少到兩個(gè)甚至更少的字符，將這作為一種減小文件大小的策略。從純 粹的性能角度來看，這是好的；但是，對(duì)大多數(shù)網(wǎng)站來說，維持這些東西所產(chǎn)生的工作量完全抹殺了它的價(jià)值。你需要同團(tuán)隊(duì)一起，在去重、最小化、壓縮和實(shí)用性 之間找到一個(gè)平衡點(diǎn)。

　　總結(jié)

　　本文介紹了幾種測(cè)試，可以用來判斷網(wǎng)站是否可能會(huì)出現(xiàn)前端性能問題。檢查這些可能的性能優(yōu)化，可能會(huì)讓用戶感受到的響應(yīng)時(shí)間提升50%甚至更 多。我確信，一旦你有了自己的工具箱、插件和助手網(wǎng)站，并且實(shí)際的練過幾次之后，你只需花費(fèi)比讀這篇文章更少的時(shí)間，就能檢查一個(gè)網(wǎng)站是否有這些問題了。 有了這么大性能優(yōu)化的可能性，又在時(shí)間和工具上投入這么少，我實(shí)在是找不到任何不進(jìn)行這些測(cè)似的理由。

　　捕魚，講究獵殺不絕，生生不息。

　　做公司思考著如何構(gòu)建自運(yùn)營的公司，做團(tuán)隊(duì)思考著如何構(gòu)建可持續(xù)發(fā)展的團(tuán)隊(duì)。而做我們測(cè)試，思考如何構(gòu)建穩(wěn)定，可持續(xù)發(fā)展的測(cè)試體系，如果，我想，可以稱之為完美測(cè)試體系。

　　順應(yīng)自然的運(yùn)行法則，我自底向上進(jìn)行一個(gè)分析和思考，看看我夢(mèng)想中的完美測(cè)試體系。

　　階段一，運(yùn)轉(zhuǎn)起來。

　　要有這樣一群人，他們能夠分析需求，制定測(cè)試計(jì)劃與策略，完成用例編寫和執(zhí)行工作，其中，有一定經(jīng)驗(yàn)的測(cè)試項(xiàng)目經(jīng)理。

　　他們能夠，有效按照用戶需求，進(jìn)行黑盒用例設(shè)計(jì)，對(duì)被測(cè)系統(tǒng)進(jìn)行功能測(cè)試，邊界測(cè)試，一定容錯(cuò)和異常測(cè)試，加一些場(chǎng)景測(cè)試和必要有效的性能測(cè)試。

　 　好了，流程制定起，運(yùn)轉(zhuǎn)起來，這個(gè)階段完美嗎？也挺好的，穩(wěn)定，有效，并且，可以比較OK的完成老板給定的任務(wù)。然而，許多團(tuán)隊(duì)易出現(xiàn)一種現(xiàn)象，進(jìn)入該 穩(wěn)定的狀態(tài)后，由于項(xiàng)目緊，大家工作忙無有效能力提高，一個(gè)項(xiàng)目接一個(gè)，忙，無改進(jìn)，忙，死循環(huán)。 人走人來，可謂穩(wěn)定而不完美。

　　階段二，打破平衡，改進(jìn)效益。

　　要有自動(dòng)化，打破忙的重復(fù)的勞動(dòng)，也許一開始并不順利，畢竟新生事物剛開始成長都是艱難的，相信自己，做下去。

　　要有業(yè)務(wù)專家，深度挖掘測(cè)試需求，改進(jìn)一開始很可能并不合理的測(cè)試點(diǎn)，精簡(jiǎn)無用冗長的測(cè)試用例，方便手工測(cè)試，方便自動(dòng)化。

　　要有性能專家，不斷改進(jìn)性能測(cè)試需求。

　 　如何打破？有潛力的，主動(dòng)性好的人，不要給予100%項(xiàng)目時(shí)間，50%－70%夠了，指派更有前瞻性的工作，例如，新的測(cè)試技術(shù)產(chǎn)出，自動(dòng)化實(shí)踐，即將 進(jìn)行的下版本測(cè)試分析預(yù)研性工作。記住，管理人員敢于失敗敢于承擔(dān)。培養(yǎng)起骨干人員，不斷有所產(chǎn)出。形成一個(gè)小的可持續(xù)改進(jìn)循環(huán)。靜等有能力的人出現(xiàn)。

　　階段三，旋轉(zhuǎn)，完美起來。

　　有了骨干人員的成長，相信，一定有能力完成：

　　1、自動(dòng)化可以在項(xiàng)目初期提交自動(dòng)化需求，融合自動(dòng)化在測(cè)試流程中，在適當(dāng)?shù)臅r(shí)候使用自動(dòng)化測(cè)試，也許，當(dāng)前自動(dòng)化已經(jīng)復(fù)用完成了許多功能模塊的覆蓋。這是自動(dòng)化專家可以完成的工作。

　 　2、業(yè)務(wù)精通的測(cè)試分析專家，能夠有效制定精細(xì)的測(cè)試策略，包括版本模塊的測(cè)試重點(diǎn)，使用哪些技術(shù)測(cè)試，制定有效的分層測(cè)試戰(zhàn)略。分層測(cè)試在這里可以大 規(guī)模節(jié)省成本，例如，使用自動(dòng)化完成關(guān)鍵部分的接口級(jí)測(cè)試，而不是做難于大規(guī)模產(chǎn)出效益的UI級(jí)自動(dòng)化。使用UI自動(dòng)化測(cè)試最有必要，易于改動(dòng)引發(fā)問題的 部分。分層測(cè)試可以有效節(jié)省測(cè)試用例設(shè)計(jì)和可測(cè)性的工作量。通過模塊分離，可以有效分離BUG產(chǎn)生原因，便于開發(fā)修改和回歸。

　　3、性能測(cè)試專家，與測(cè)試策略同時(shí)制定，分析系統(tǒng)可能存在的性能問題，完成高效的性能測(cè)試需求，如，利用什么樣的工具或改進(jìn)現(xiàn)有工具，高效完成哪些性能指標(biāo)測(cè)試。

　　4、高效執(zhí)行團(tuán)隊(duì)，固定的不易于改變的，通過一次手工執(zhí)行和方便的自動(dòng)化框架構(gòu)建下次可快速回歸的執(zhí)行過程。有效的BUG review，和有針對(duì)性的發(fā)散性和探索性測(cè)試，構(gòu)建場(chǎng)景測(cè)試的團(tuán)隊(duì)。如有需求，構(gòu)建安全測(cè)試團(tuán)隊(duì)。

　　項(xiàng)目立項(xiàng)，由用戶和BOSS立項(xiàng)，研發(fā)和測(cè)試跟進(jìn)，各技術(shù)專家評(píng)審需求，除提供有效的場(chǎng)景供用戶和開發(fā)確定外，測(cè)試分析專家（架構(gòu)師）給予可測(cè) 試性需求，包括不限于，用戶級(jí)需求的可測(cè)試性分析；白盒測(cè)試的約束和接口，如庫的導(dǎo)出標(biāo)準(zhǔn)；與開發(fā)的架構(gòu)師一起確定整體設(shè)計(jì)方案是否合理有效，并指導(dǎo)或確 定可測(cè)試性設(shè)計(jì)要求。

　　項(xiàng)目設(shè)計(jì)，開發(fā)在處理用戶需求的同時(shí)，跟進(jìn)前期測(cè)試，完成自動(dòng)化測(cè)試需求，測(cè)試專家的可測(cè)試性需求跟蹤和測(cè)試策略的制定。

　　項(xiàng)目編寫集成，項(xiàng)目的自動(dòng)化工程師和執(zhí)行人員介入，按照項(xiàng)目流程和策略進(jìn)行集成測(cè)試，并同時(shí)產(chǎn)出相關(guān)自動(dòng)化用例，完成制定的測(cè)試分析專家的分層測(cè)試策略與其他測(cè)試策略。

　　項(xiàng)目系統(tǒng)測(cè)試，根據(jù)策略，至少2輪以上，快速回歸自動(dòng)化，集成發(fā)散性測(cè)試和探索性測(cè)試，充分發(fā)揮大家的思考發(fā)散能力，將上一階段的問題發(fā)現(xiàn)并提交，并回溯起來，不斷改進(jìn)前期過程。

　　項(xiàng)目穩(wěn)定性和場(chǎng)景測(cè)試，由相關(guān)人員進(jìn)行場(chǎng)景測(cè)試，保證到最終用戶的可靠的使用。

　　是否完美呢？它有高效的運(yùn)作方式，有經(jīng)驗(yàn)豐富和技術(shù)牛人指導(dǎo)前期，有完整高效的分層策略和自動(dòng)化保證快速開發(fā)，有穩(wěn)定性與用戶場(chǎng)景保證最終的可 靠性發(fā)布。如果說不完美，有一點(diǎn)，還缺少那么一點(diǎn)點(diǎn)預(yù)見性，那么，培養(yǎng)具有市場(chǎng)前瞻性的技術(shù)專家吧，例如，提前半年分析超大流量的測(cè)試技術(shù)，提前研究移動(dòng) 終端的快速測(cè)試技術(shù)。

　　自底向上，意味著，很多東西我們管理需要培養(yǎng)起有能力的人員由他們自然推動(dòng)，而不是靠從上向下的強(qiáng)推自動(dòng)化，強(qiáng)推所謂的敏捷流程。

　　至于流程，在完美測(cè)試體系中，它應(yīng)該融入到我們的研發(fā)和測(cè)試平臺(tái)中。自然隨性，不知不覺跟進(jìn)了流程。這是流程的最高境界。

　　在測(cè)試界中，易于出現(xiàn)無成就感的問題，在這里，沒有任何問題，每個(gè)人有向上發(fā)展的動(dòng)力，有其不同的價(jià)值體現(xiàn)。最終的大牛進(jìn)入研發(fā)過程改進(jìn)中。

　　所謂大局觀，是一種思路，在管理過程中，抓住前瞻性的重要不緊急工作，把它做好。那么，自然，穩(wěn)定的，可持續(xù)的完美測(cè)試體系，在未來，可成矣。

　　“飲鴆止渴”， 萬萬不可。