Optimizeit Thread Debugger概覽本文通過介紹Optimizeit Thread Debugger的一些主要特征來使你對它有個簡要的了解。如果想要了解更多的信息，請查看Optimizeit Thread Debugger用戶手冊，也可以從Optimizeit Thread Debugger單擊主菜單info|help來查看所有的使用文檔。使用中有何問題，請隨時與Borland Technical Support聯系。測試java程序Optimizeit Thread Debugger是從運行程序的虛擬機中收集程序的覆蓋信息的。首先要運行一個java程序，您需要安裝一個java虛擬機。Optimizeit Thread Debugger默認安裝配置JDK 1.4 or 1.4.1。如果你想使用另外的虛擬機，可以查看Optimizeit Thread Debugger用戶手冊的如何增加新的虛擬機部分。從運行程序的虛擬機中收集程序的覆蓋信息的。首先要運行一個java程序，您需要安裝一個java虛擬機。Optimizeit Thread Debugger默認安裝配置JDK 1.4 or 1.4.1。如果你想使用另外的虛擬機，可以查看Optimizeit Thread Debugger用戶手冊的如何增加新的虛擬機部分。啟動應用程序Optimizeit Thread Debugger可以測試任何類型的java程序，比如標准應用程序，應用小程序, servlets, JSPs, EJBs。本文所使用的測試程序包含在\doc\thread_debugger\quicktour目錄下。所有的測試都是在Optimizeit Thread Debugger中進行的:打開Optimizeit Thread Debugge。如果你是第一次打開，將會自動彈出編輯設置窗口。如果已經打開，可以從file菜單下選擇new setting，調出編輯設置窗口。在程序類型框中選擇Application。單擊"Program main class or Jar file"右面的“Browse…”按鈕。找到\doc\thread_debugger\quicktour\ThreadDExample.class文件，然後單擊open。Optimizeit Thread Debugger會返回到設置窗口，並且自動帶入程序的工作區和類路徑。在Source Path框中，單擊change…按鈕。在Source path chooser窗口中，選擇安裝路徑下的\doc\thread_debugger\quicktour目錄；選中後單擊窗口中的向下按鈕把它加入到source path部分。單擊ok增加到源文件中路徑中。設置好後的對話框如下：選中Open a console選項；這是非常重要的，因為這個程序需要輸入一些命令來運行。 單擊Start now按鈕。編輯設置窗口會自動關閉， Optimizeit Thread Debugger會啟動被測程序。 查看線程Thread Debugger默認打開的是線程監視窗口。你也可以重新定義默認打開的窗口來查找程序在哪裡掛起了或者是比較耗時: 程序啟動後, Optimizeit Thread Debugger打開了一個DOS窗口，在DOS窗口中輸入1，然後按回車鍵開始第一輪測試。Thread Debugger窗口中會顯示當前運行的線程和他們各自的運行狀態：整個過程中窗口中會使用不同的顏色條來顯示當前的線程運行狀態:運行狀態 (綠色）表示線程正在運行並使用CPU 。堵塞狀態 (黃色）表示該線程沒有運行，因為在進入monitor時發生了阻塞。等待狀態（紅色）表示線程正在等待monitor的通知與其他線程共享資源。等待輸入輸出狀態 (紫色）表示該線程的本地代碼沒有執行任何的過程。這常常是由於一個輸入/輸出操作操作引起的，但也有可能是其它情況導致給代碼沒有分配使用CPU而造成的。注意：當相應的線程狀態應該被更新而未更新時，Optimizeit會在顏色條中顯示一些點。當測試程序退出或沒有收集到信息時，未知狀態的區域也將以不同類型的圖案來顯示。先選中主線程"main"，然後單擊I/O-Waiting View 切換到等待I/O監視窗口: 雙擊第三行，可以從源代碼窗口中看到發生等待的那行代碼。該程序基本上都使用了標准的輸入來方法。關閉源碼窗口並返回到線程活動監視窗口。在線程窗口中也可以選取某一段來分析該時間內的一些信息。返回到控制窗口並且輸入2，然後單擊回車啟動第二輪測試（使用了小的連接）。Thread Debugger顯示了當前正在運行的線程的狀態。你會看到在開始的某段時間內有10個線程在運行。 在線程活動監視窗口，拖動滾動條到剛才的這段時間范圍內。如果不想繼續查看線程活動信息，可以取消選中窗口右下方的Update continuously選項，這樣窗口中的信息就不會隨時間變化了。 在這段時間內黃色區域表示相應的線程堵塞在一個monitor中。在線程條上直接單擊黃色條上任意一部分，並按住鼠標左鍵向右移動。這樣就選中了該時間段： 選中時間段後：單擊Contention View 來分析為什麼線程在進入monitors時會發生阻塞。該信息表示的僅是選擇時間段的。 單擊Waiting View 來研究線程在哪裡等待monitors。同樣，該信息也僅僅是所選時間范圍的，所以應選擇圖中紅色條部分的區域。注意：如果線程已經退出或者已不存在該線程名在窗口中就會以斜體顯示。理解線程爭用在java多線程的應用程序中如果許多線程同時需要同樣的monitors（可譯為監視器或管程），就會造成嚴重的性能瓶頸。Monitors是被用來保護共享資源被多個線程同時調用的，每一個對象都有一個monitors，同時只允許一個線程持有monitors從而進行對對象的訪問，那些沒有獲得monitors的線程必須等待，直到持有monitors的線程釋放monitors。這部分被monitors保護起來的代碼，我們稱之為臨界區。為了優化性能，我們經常要盡可能地保持小的臨界區，特別是當臨界區在執行一些不耗用CPU資源的過程時。如果一個線程在臨界區域內由於等待輸入輸出而造成等待，它就不再使用CPU資源。然而，如果其他的線程也等待這個monitors的話就就不能充分利用CPU資源。下面我們用實例來說明這個問題：重新啟動被測試程序。程序啟動後，在DOS窗口中輸入1並按下回車鍵啟動爭用較大的示例。你會注意到在某段時間內有10個線程在運行。在線程窗口，拖動窗口下面的滾動條返回到這段時間，並且取消選中"Update continuously": 可以看到此例中相對於實際使用CPU的時間來說爭用monitor所花費的時間更長。為了更全面地了解這個情況，選中任何線程（例如線程7）並且單擊Contention View 切換到爭用查看窗口: 由於爭用ContentionExample$Consumer.run()方法100％的時間花在了堵塞上，爭用監視控制台上顯示了所有與該爭用有關的monitor。選中java.lang.Object monitor。爭用詳細說明控制台就會顯示列出所有與該爭用有關的線程,包括什麼時候發生了爭用。打開第一個線程： 在ContentionExample$Consumer.run()行上雙擊就會彈出該方法的源代碼。在源碼窗口顯示線程7正在獲取monitor，然而源碼窗口下方顯示線程1同時也在獲取monitor: 在被monitor“lock”保護的臨界部分，此例中調用了方法processData()。該方法用1毫秒來模擬輸入輸出。此例說明了使用過多的爭用會付出很大代價。對於使用幾毫秒CPU資源來說, 每個線程大概阻塞1秒。為了降低爭用的發生，當確認臨界區不再等待爭用時，有必要使臨界區最小化。我們的解決辦法很簡單，就是通過排除不需要同步處理的數據來處理縮小臨界區。這樣代碼調整為： synchronized (lock) { a = dataSourceA.nextElement(); b = dataSourceB.nextElement();}processData(a, b);演示程序中也包含了測試useBigLock 標志的情況。切換到線程監視窗口。重啟被測程序，在DOS窗口中輸入2 後按下回車鍵運行第二個測試。第二個測試也使用的同樣的代碼，但是這次useBigLock 標記被置為false。爭用時間降低到了每個線程只有幾毫秒。 這裡有一些技巧來防止由於爭用而引起的性能問題：盡量使臨界區最小。僅包含需要被保護的語句。鎖定可能最低的級別。在synchronized方法前加上explicit synchronized()語句。同步方法使用起來很方便，但是也可能導致過多的爭用，僅僅因為隨著時間的增長方法趨向於復雜化。 不要在臨界區執行一個I/O操作，除非唯一的目的是為了保護I/O描述符或者對象經常執行I/O操作。 猜測爭用的級別幾乎是不可能的。通過監視線程窗口，每次重大的變化都會看到有難以理解的爭用級別。 理解死鎖多線程的應用程序所面對的共同問題是，當一些線程由於不能獲得其所需的資源致使線程被掛起。死鎖對堆棧來說是極大的挑戰，因為它經常很少出現甚至不能復現。一個極少出現死鎖也有可能導致一個web應用程序長時間被掛起，並引起資源浪費。Optimizeit Thread Debugger提供了兩個強有力的特征使調試死鎖變得容易。第一是給開發人員提供死鎖發生的位置。第二個特征將在下一部分來說明，是幫助開發人員來監視應用程序的運行，並且一旦有可能發生死鎖會及時給出提示。單擊Monitor VIEw 按鈕切換到顯示執行臨界部區所有的線程和監視器的窗口。默認情況下該窗口的內容是實時顯示並每秒都更新的。 如果有必要，重啟被測試程序並在DOS窗口種輸入3然後回車來運行一個死鎖的例子。這個死鎖是由於一個同步的參數錯誤引起的： 單擊圖中的任一個按鈕，相應的棧軌跡就會顯示在窗口的下方。可以雙擊某一行來查看相應的源碼。線程顏色所表示的狀態與線程窗口中所表示的一樣。一旦單擊連接圖中的一個按鈕，監視內容就不再更新。可以再次單擊該按鈕或者重新進入該窗口圖就可以繼續保持更新。監視程序的死鎖由於重現和理解死鎖是比較困難的，基於這種情況， Optimizeit Thread Debugger提供了一個線程分析器。當一個Java程序運行時線程分析器記錄並監視所有的同步活動。然後搜索任何一個有可能導致死鎖的類型並且給出一個警告或者錯誤信息的列表，包含臨界區的詳細資料，諸如哪裡會有有可能發生死鎖和調用了那個線程。Optimizeit Thread Debugger會注意監視以下一些表現異常的鎖類型:鎖的順序：兩個線程直接或者連續地以不同的順序進入同一個monitors。鎖和等待：線程進入一個monitors然後等待進入其他的monitors。鎖和I/O等待：線程進入一個monitors然後停止執行任何的任務。除非兩個線程永遠不會同時運行，鎖的順序問題經常預示著有被鎖死的風險。對Lock-and-wait和Lock-and-I/O-wait類型的鎖，預示著情況比較正常，如果監視器的目的是限制對正在等待或者正在執行輸入輸出的資源的訪問。為了證實會發生死鎖，本文所指的示例程序中會有3個線程會同時進入同一個監視器來獲取數據。每個線程都使用了隨機函數調用，這樣有時它們會以不同的順序進入監視器。這個程序僅僅用來演示，然而可以細想當多個線程在一個大的應用程序中運行並且當處理一些臨界區時以不同的順序進入監視器會發生什麼樣的情況。本例在執行過程中經常會發生死鎖，但是無論是否真正地發生死鎖Optimizeit Thread Debugger分析器都將匯報一些警告信息和發生的錯誤信息：如有必要請重新打開示例程序。 單擊Monitor Usage Analyzer 按鈕。單擊Record 開始記錄測試過程。在程序啟動後會彈出一個DOS窗口，在窗口中輸入4並按回車鍵開始程序的運行。注意：分析器也可以通過選擇編輯設置窗口中的"start analyzer"選項來啟動。當以一定的順序發生阻塞時窗口中顯示符號 '>'，以另外的順序發生阻塞時顯示符號'<'。最後，程序會停止，但是再不會出現菜單。這意味著發生了死鎖。按下回車鍵可以重新顯示菜單： 再次單擊Record停止記錄。選擇第一條錯誤信息並切換到分析窗口： 在方法名上單擊調出源代碼。關閉源碼窗口返回到監視器使用分析窗口。這裡有一些避免產生死鎖的技巧：盡可能讓鎖簡單。兩個線程使用一個monitors來共享資源不會發生死鎖，同樣他們永遠不會在臨界區期間發生阻塞。在進入monitors後不要執行輸入輸出操作，除非該監視器是用於保護輸入輸出的。當進入另一個monitors時不要等待另一個monitors，除非完全有必要並且是可理解的。總是以同樣的順序進入monitors。當持有一個鎖時不要調用公共的synchronized方法。活鎖過多在多線程的應用程序中另一類典型的問題是有過多的鎖。當虛擬機被優化後，能夠非常快地進入多個monitors，減少monitors的使用就可以極大地提高性能。Optimizeit Profiler能夠用來度量每個方法使用了多長時間，包括進入monitors的時間，而Optimizeit Thread Debugger可使開發人員了解監視器使用的頻率和位置，無論爭用是否發生過：在線程窗口選擇一個線程或一個時間范圍後單擊Monitor Enter VIEw 按鈕切換到進入monitors詳細信息查看窗口。例如，在選擇main類後單擊出現如下所示的窗口：可以看到main類進入了22個monitor。 本文只是Optimizeit Thread Debugger的一個概覽。如果想要了解更多有關Optimizeit的信息，請查看Optimizeit Thread Debugger用戶指南。 翻譯：
[email protected] 時間：2004-11-11如果您對本文或白盒測試感興趣，請登錄http://groups.yahoo.com/group/WhiteBoxTestCN/，加入會員，即可下載到本文完整的內容（格式為呆圖片的Word文檔），在這裡還有其他一些白盒測試工具的介紹與相關討論。
