http://hi.baidu.com/widebright/item/bcddbc2596ba2a0977272c5c
JAVA's remote debugging is based on the Java Platform Debugger Architecture (JPDA: Java Platform Debugger Architecture). The JVM itself supports specifying parameters to make java programs start in debug mode. The virtual machine is running in debug mode, you just need to connect to its corresponding listening port.
Servers such as tomcat also provide a setting method for specifying debugging parameters
Typical debugging parameters are as follows
-Xdebug -Xrunjdwp:transport=dt_socket,address=8888,server=y,suspend=n
There is also a remote debugging option in Eclipse, "run" -> "Open Debug Dialog" -> "Remote Java Application" that is.
In the options, select the specific "project", "code directory", etc., fill in the ip and port, and finally click the "Debug" button below. Note that the code on the local machine and the code running on the remote machine should be the same.
---------------jdb usage ----------------
C:\Program Files\Java\jdk1.6.0_03\bin>jdb - help
usage: jdb <options> <class> <parameters>
Among the options are:
-help print this message and exit
-sourcepath <directories separated by ";">Directory
where to look for source files
-attach <address>
Use standard connector to connect to the VM running at the specified address
-listen <address >
wait for VMs running at specified address to connect using standard connectors
-listenany
wait for VMs running at any available address to connect using standard connectors
-launch
starts VM immediately without waiting for 'run' command
-listconnectors list this VM available connectors
-connect <connector name>:<name1>=<value1>,...
Connect to the target VM using the named connector and listed parameter values
-dbgtrace [flags] Output information for debugging jdb
-tclient Run the application in Hotspot(TM) Performance Engine (client)
-tserver Run the application in Hotspot(TM) ) to run the application in the Performance Engine (server)
Options forwarded to the debugged process:
-v -verbose[:class|gc|jni]
enable verbose mode
-D <name>=<value> set system property
-classpath <directories separated by ";">
list the directory where to look for classes
-X <options> non-standard target VM options
<class> is the name of the class to start debugging
<parameter> is the parameter passed to the main() method of <class>
For command help, type 'help' at the jdb prompt
C:\Program Files\Java\jdk1.6.0_03\bin>jdb
is initializing jdb...
> help
**command list**
connectors -- list the connections available in this VM
run [class[parameters]] -- the main class to start executing the application
threads [thread group] -- list threads
thread <thread id> -- set default thread
suspend [thread id] -- suspend thread (default is all)
resume [thread id] -- resume thread (default is all)
where [<thread ID> | all] -- dump the thread's stack
wherei [<thread ID> | all] -- dump the thread's stack and pc
up [n frames] -- move up the thread's stack
down [n frames ] ] -- move down the thread's stack
kill <thread id> <expression> -- abort the object with the given exception
interrupt <thread id> -- interrupt the thread
print <expression> -- output the value of the expression
dump <expression> -- output all object information
eval <expression> -- evaluate the value of the expression (same as
set <lvalue> = <expression> -- for the field /variables/array-element
locals -- print all the current stack frame
classes -- list currently known classes
class <class id> -- display details of the named class
methods <class id> -- list the methods of the class
fields <class id> -- list the fields of the class
threadgroups -- list thread groups
threadgroup <name> -- set current thread group
stop in <class ID>.<method>[(parameter type,...)]
-- set breakpoint in method
stop at <class ID>:<line> -- set breakpoint in line
clear <class ID >.<method>[(parameter type,...)]
-- clear breakpoints in method
clear <class ID>:<line> -- clear breakpoints in line
clear -- list breakpoints
catch [uncaught |caught|all] <class ID>|<class mode> -- interrupt ignore
when specified exception occurs [uncaught|caught|all] <class ID>|<class mode> -- for specified exception, cancel watch [access |all] <class ID>.<field name> -- watch access/modification to fields unwatch [access|all] <class ID>.<field name> -- stop monitoring accesses to fields / trace [go] methods [thread] -- trace method entry and exit.
-- unless 'go' is specified, all
trace [go] method exit | exits [thread]
-- trace the exit of the current method or
-- unless 'go' is specified, all
untrace [method] -- stop tracing the method's Enter and/or
step back -- execute the current line
step up -- execute to the current method and return to its call
stepi -- execute the current instruction
next -- skip a line (step over the call)
cont -- continue execution from the breakpoint
list [line number|method] -- output source code
use (or sourcepath) [source file path]
-- show or change source path
exclude [<class pattern>, ...|"none"]
-- do not report the specified class step or
method classpath -- output classpath information from target VM
monitor <command> -- execute a command every time the program stops
monitor -- list monitors
unmonitor <monitor number> -- delete a monitor
read <filename> -- read and execute a command file
lock <expression> -- output the lock information of the object
threadlocks [thread ID] -- output the lock information of the thread
pop -- pop the entire stack, and include when
reenter -- same as pop, but
redefine <class ID> <class file name>
-- redefine the class code
disablegc <expression> -- disable garbage collection of objects
enablegc <expression> -- enable garbage collection of objects
!! -- repeat the last command
<n> <command> -- repeat the command n times
# <command> -- give up (do not execute)
help (or ?) -- list command
version -- output version information
exit (or quit) -- exit the debugger
<class ID>: full class name with package qualifier
<class pattern>: class name with a leading or trailing wildcard (*)
<thread ID>: thread number reported in the 'threads' command
<expression >: Java(TM) programming language expression.
Most common syntaxes are supported.
Startup commands can be placed in "jdb.ini" or ".jdbrc"
(both in user.home or user.dir)
>
==========Reference Documents======================================== =
What is JPDA Java Platform Debugger Architecture (JPDA: Java Platform Debugger Architecture) It consists of Java virtual machine back-end and debugging platform front-end 1. Java virtual machine provides Java debugging functions 2. Debugging platform requests Java virtual machine through debugging interactive protocol Service to debug the program running in the virtual machine The framework of JPDA JPDA completes the above description through two interfaces and protocols, namely JVMTI (Java Virtual Machine Tool Interface), JDWP (Java Debugging Wiring Protocol) and JDI ( Java debugging interface). 1. JVMTI defines the debugging services that the virtual machine should provide, including debugging information (Information such as stack information), debugging behavior (Action such as the client setting a breakpoint) and notification (Notification such as notifying the client when a breakpoint is reached) , the interface is provided by the virtual machine implementer and combined in the virtual machine 2.JDWP defines the communication between the debugging service and the debugger, including defining the debugging information format and debugging request mechanism 3.JDI is defined at a high level of the language A debugging interface that can be used by a debugger to easily interact with a remote debugging service is implemented in Java, and the debugger implementer can directly use the interface to access the debugging service of the virtual machine.
Operation mode When the debugging service of the virtual machine runs, the virtual machine acts as a debugging service provider, listening to a connection, and the debugger interacts with the virtual machine through this connection. At present, the JVM of the Windows platform provides two types of connections: shared memory and socket connection. The shared memory service provider and debug end can only be located on the same machine, while the socket connection supports different different machine debugging, that is, remote debugging.
Virtual machine parameter setting 1．Enable debugging service -Xdebug Enable debugging -Xrunjdwp:<sub-options> Load JVM's JPDA reference implementation library 2．Xrunjdwp sub-parameters (sub-options) The configuration format of Xrunjdwp sub-parameters is as follows -Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...
A few examples - Xrunjdwp:transport=dt_socket,server=y,address=8000 listens for socket connections on port 8000, suspends the VM and runs the main function without loading until the debug request arrives -Xrunjdwp:transport=dt_shmem,server=y,suspend= n select an available shared memory (because no address is specified) and monitor the memory connection, and load and run the main function -Xrunjdwp:transport=dt_socket,address=myhost:8000 to connect to the debugging service provided by myhost:8000 (server=n, Existing as a debug client), suspend the VM and run the main function without loading -Xrunjdwp:transport=dt_shmem,address=mysharedmemory Connect to the debugging service through shared memory, suspend the VM and run the main function without loading -Xrunjdwp:transport= dt_socket,server=y,address=8000, onthrow=java.io.IOException,launch=/usr/local/bin/debugstubWait for java.io.IOException to be thrown, then suspend the VM and listen for connections on port 8000. After the debug request is reached, execute the command /usr/local/bin/debugstub dt_socket myhost:8000 -Xrunjdwp:transport=dt_shmem,server=y,onuncaught=y,launch=d:\bin\debugstub.exe
Wait for a RuntimeException to be thrown, then suspend the VM and monitor an available shared memory, execute the command d:\bin\debugstub.exe dt_shmem <address> after receiving a debug request, <address> is the available shared memory
启动tomcat-Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n
The above two lines are sentences in the catalina.bat file of tomcat 5.5.12. It can be seen how tomcat is started in JPDA mode. To start tomcat, use catalina jpda start to start, not startup.bat, set it before starting JPDA_TRANSPORT, JPDA_ADDRESS is OK
-------------------------------------
Java remote debugging
is actually JPDA using JDK. Add to the command line parameters of the server (Jboss or Tomcat, etc.):
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
If you use Eclipse as a debugging tool, create a Remote Java Application and fill in the correct IP and port (8787 above) for the connection parameters.
First of all, JAVA itself supports the debugging function, and provides a simple debugging tool-JDB, similar to the powerful GDB, JDB is also a character interface debugging environment, and supports setting breakpoints and thread-level debugging.
------------------------------------------------
JAVA The debugging method is as follows:
1. First support JVM, and set parameters to make it work in DEBUG mode, add parameters: -Xdebug -Xrunjdwp,transport=dt_socket,server=y,address=5432,suspend=n,onthrow=java.io.IOException,launch= /sbin/echo
Among them, -Xdebug informs the JVM to work in DEBUG mode, and -Xrunjdwp informs the JVM to use the (java debug wire protocol) to run the debug environment. This parameter also includes a series of debugging options:
transport specifies the transmission mode of debug data, dt_socket refers to the SOCKET mode, and dt_shmem refers to the shared memory mode. Among them, dt_shmem is only applicable to the Windows platform.
The server parameter refers to whether to support the VM in server mode.
onthrow indicates that when an Exception of this type is generated, the JVM will be interrupted and debugged. This parameter is optional.
launch specifies the executable program to execute when the JVM is interrupted. The optional
suspend parameter indicates whether to execute the JVM after the debug client is established.
onuncaught (=y or n) indicates whether to interrupt the execution of the JVM after an uncaught exception occurs.
2. Start the debug tool.
The simplest debugging tool is the JDB mentioned above. Taking the above debugging JVM as an example, you can start the JDB with the following command:
jdb -connect com.sun.jdi.SocketAttach:port=5432,hostname=192.168.11.213
In addition , There are many visual debugging tools, such as eclipse, jsawt and so on. Eclipses can use ant debug to create a debug method.