Java調試是一個復雜的空間。 調試器的類型很多，工具也很多。 在此頁面中，我們將介紹7種類型的調試器之間的區別，并查看每個類別中的主要工具，以幫助您為正確的工作選擇正確的工具。

以下是我們介紹的調試器類型：

CLI調試器

IDE調試器

構建自己的調試器

堆轉儲

歷史調試器

動態追蹤

生產調試

塔基皮

定義

使用廣泛的定義，錯誤是實例，其中我們編寫的代碼與我們獲得的輸入不匹配。 這些的不同影響可以大致分為–

意外的流控制 ，導致異常或代碼中我們不希望出現的位置。 在這里，調試器通常用于檢查代碼和狀態的相關性。

意外的堆分配 。 在這種情況下，我們要么分配了太多的對象，要么分配了太大的對象。 保留對這些內容的長期引用只會增加樂趣。 這就是堆分析器起作用的地方。

延遲流量控制 。 這很可能與我們將錯誤的輸入傳遞給外部調用(即“ SELECT * FROM everything”)或卡在長循環或無限循環中有關。 這是性能分析器通常會出現的地方。

當然，工具和類別之間存在重疊，因為它們本質上都具有相同的目的-讓我們看到我們所期望的狀態，以便我們可以修復代碼，并使其達到期望。

1.命令行調試器

主要工具 ：主要參與者是jdb ，它是JDK附帶的，與JVM等效，是gdb。 它具有命令行界面，可以連接到正在運行的JVM。 像gdb一樣，它的功能也很強大，您可以使用jdb進行任何功能，就像使用功能強大的IDE調試器一樣。 jdb有一個補充-jstack-它使您可以在給定時刻打印實時JVM的線程調用堆棧。 但是，這不會捕獲變量或堆狀態。

在以下情況下使用 ：jdb的最大優點是其可移植性。 您可以相當快地將其安裝到服務器上，而不必遠程連接調試器。 如果您正在處理服務器上的惡劣環境，并且有能力讓JVM檢查它，那么jdb是您最好的朋友。

缺點 ：jdb和jstack的缺點是，與其他命令行工具一樣，它們在日常使用中效率不高。 這將我們帶入下一個類別。

2. IDE調試器

主要工具 ：Eclipse和NetBeans是該類別中的兩個工具。 兩者都使用與jdb類似的技術來附加或啟動新的JVM。 盡管不是很輕便，但您確實會遇到麻煩，這可以使調試更短，更有趣。

在以下情況下使用 ：假設您每天都不是Dexter( 神童 ，而不是連環殺手)。

缺點 ：作為高端桌面應用程序，它們不是您要在生產計算機上運行的東西。 始終存在進行遠程調試的可能性，但是在復雜的環境中，解決該問題的可能性很小。

3.構建自己的調試器

到目前為止，我們已經描述的所有調試器都基于相同的JVM開放調試體系結構，最常見的是使用JDWP(Java調試器有線協議)與正在運行的JVM通信。 JSwat是在此框架之上構建的獨立調試器的示例。 是否想學習如何構建自己的Java / Scala調試器? 請點擊這里 。

在以下情況下使用 ：構建自定義JVM擴展，或者對JVM的工作方式非常感興趣。

缺點 ：這是一件很復雜的事情，尤其是當您不想影響目標JVM的狀態時，這是非常正確的事情，因此，您需要一個非常有說服力的理由來說明為什么不能使用經過考驗的現有工具。

4.堆轉儲

主要工具 ：jmap，MAT。 在許多情況下，就像Rick Grimes一樣 ，您正在與死者打交道。 在這些情況下，您正在查看的是JVM堆的快照，而不是已停滯的實時JVM的快照。 JDK附帶的jmap允許您從實時JVM生成堆轉儲。 有很多工具可以讓您瀏覽和分析轉儲。 JDK附帶的jhat和visualVM在這方面做得很好。 Eclipse插件MAT和NetBean的HeapWalker是很好的選擇，因為它們利用了已經強大的IDE UI。

在以下情況下使用 ：發生復雜錯誤且無法應用常規調試技術(例如，該應用程序在客戶的服務器上運行)。 另一種選擇是通過打開JVM -HeapDumpOnOutOfMemoryError標志來使用堆轉儲來分析內存泄漏，以使JVM在堆耗盡后自動轉儲堆的內容。

缺點 ：使用堆轉儲的最大缺點是它們的重量與堆本身的重量一樣大(這很可能意味著堆在GB中)。 然后必須將其轉回給您進行分析。 在生產中捕獲它們也不是在公園中漫步。

5.歷史調試器

主要工具 ：這類工具取決于您是否能夠或不想停止JVM來收集狀態或進行堆快照。 Chronon DVR是這種方法的一個很好的例子。 在此，調試器使用字節碼檢測從代碼本身內部記錄數據。 這通常包括諸如調用方法的順序以及傳遞給它們的參數之類的事情。 這使調試器可以“重播”代碼，并讓您了解執行時的流控制。 重播解決方案(由CA收購)是另一種使用不同方法的示例，其中記錄了對JVM的IO輸入，然后將其“重播”回活動實例–模擬執行后的代碼。

在 以下情況下使用 ：此類工具的主要途徑通常是在質量檢查期間，通過捕獲實際的運行時狀態，它們可以幫助使錯誤更易于重現。 另一種情況是讓客戶或支持工程師臨時運行該工具，以在應用程序在生產中表現異常時從JVM捕獲狀態。

缺點 ：這些工具的最大缺點是日志記錄會花費您很多，而日志記錄會花費很多。 這意味著歷史悠久的調試器可以將應用程序的速度降低50%到一個數量級，從而限制了可以使用這些應用程序的生產方案的數量。

6.動態跟蹤

主要工具 ：BTrace。 使用此類別中的工具，您可以從正在運行的JVM中有選擇地打印(“跟蹤”)狀態信息，而無需暫停它，也不必記錄正在發生的一切。 可以將它視為動態編織到一段新代碼中，該新代碼從代碼本身中打印值以供您查看。 BTrace是一個杰出的工具，它引入了自己的語法，可讓您定義要在代碼中跟蹤的位置和內容。 該語法還設計為僅支持只讀操作，以防止您實際更改程序的狀態或引起無限循環。

在以下情況下使用 ：最常用于嘗試針對特定問題調試服務器(例如，連接池已耗盡)或在不停止JVM執行的情況下臨時收集特定統計信息的情況。

缺點 ：與調試器一樣，通常不建議從生產服務器進行動態跟蹤(并且很多時間是不允許的)。 還有一個小的學習曲線，可以在服務器環境中有效地使用動態跟蹤。

7.生產調試

主要工具 ：用于記錄狀態的日志記錄框架(log4j，Logback)和用于大規模分析數據的日志分析器(Logstash，Splunk…)。

在以下情況下使用 ：這是一個相當困難的區域，因為當您處理生產系統時，使JVM停頓以查看狀態或進行堆轉儲通常是很大的禁忌。 那是因為您實際上是要關閉服務器來調試它，這通常僅在極端情況下才能完成。

我們通常在運行時從JVM中提取狀態而不停止狀態的方法是通過有選擇地將變量值記錄到文件中(通常是在Java記錄框架的幫助下)。 稍后，我們可以使用各種工具來解析數據，從簡單到尾部，一直到可擴展的日志分析器，例如開源Logstash和企業Splunk。

缺點 ：這里最大的缺點是我們當然需要事先知道(并有效地執行)登錄。 日志也可以很快被填滿，并且無需開發團隊的大量紀律，還可能包含很多不必要的數據或錯過了一些關鍵數據。

科學家觀察到，將日志文件中的數據拼湊在一起以了解導致錯誤的變量狀態，這是夜間和假日消遣的一種非常受歡迎的開發人員。

我們在構建Takipi時考慮了一個簡單的對象。 我們想讓開發人員輕松知道何時以及為何中斷生產代碼。 這意味著，無論何時開始發生新的異常或日志錯誤，我們都會捕獲它并通知您。 第二部分是跟蹤部署，以說明問題從哪個開始以及發生的頻率。 最后(也是最有趣的部分)是生產調試部分。 對于每個異常或錯誤，Takipi會在錯誤發生時向您顯示確切的源代碼和變量狀態(包括本地值和對象值)，就像發生錯誤時您在那兒一樣。

以上就是關于“Java調試工具介紹”，其他的Java開發工具還有很多，大家可要多了解一些，這對以后的學習會有很大的幫助。