Optimizeit Thread Debugger Overview

The Debug Optimizeit Thread Debugger Overview This article gives you a brief understanding of Optimizeit thread debugger by introducing some of its main features. For more information, check out the Optimizeit thread Debugger user manual, or click the main menu info|help from Optimizeit thread debugger to view all of the usage documents. Please feel free to contact Borland Technical support for any problems in use. The test Java program Optimizeit Thread Debugger collects program coverage information from the virtual machine where the program is running. To run a Java program first, you need to install a Java virtual machine. Optimizeit Thread Debugger The default installation configuration JDK 1.4 or 1.4.1. If you want to use another virtual machine, you can view how the Optimizeit Thread Debugger User's manual adds a new virtual machine section. Collects program coverage information from the virtual machine in which the program is running. To run a Java program first, you need to install a Java virtual machine. Optimizeit Thread Debugger The default installation configuration JDK 1.4 or 1.4.1. If you want to use another virtual machine, you can view how the Optimizeit Thread Debugger User's manual adds a new virtual machine section. Launch Application Optimizeit Thread debugger can test any type of Java program, such as standard applications, application applets, Servlets, JSPs, EJBs. The test program used in this article is included in the \doc\thread_debugger\quicktour directory. All tests are performed in the Optimizeit thread debugger: Open Optimizeit thread Debugge. If you are opening it for the first time, the Edit Settings window will automatically pop up. If it is already open, you can select new setting from the File menu and bring up the Edit Settings window. Select application in the Program type box. Click the "Browse ..." button to the right of program main class or Jar file. Locate the \doc\thread_debugger\quicktour\threaddexample.class file, and then click Open. Optimizeit Thread DebuGger is returned to the Settings window and is automatically brought into the workspace and classpath of the program. In the Source Path box, click Change ... Button. In the Source Path Chooser window, select the \doc\thread_debugger\quicktour directory under the installation path, and then click the Down button in the window to add it to the source path section. Click OK to add to the path in the source file. The dialog box is set up as follows: Select the open a console option; This is important because the program needs to enter some commands to run. Click the Start Now button. The Edit Settings window will automatically close and Optimizeit Thread debugger will start the program under test.   View threads thread debugger The default is to open the Thread Monitor window. You can also redefine the default open window to find out where the program hangs or is time-consuming: After the program starts, Optimizeit Thread debugger opens a DOS window, enters 1 in the DOS window, and presses the ENTER key to start the first round of testing. The Thread Debugger window displays the currently running threads and their respective running states: The entire process uses a different color bar in the window to display the current thread running state: The Running State (green) indicates that the thread is running and using the CPU. A blocking state (yellow) indicates that the thread is not running because of blocking when it enters the monitor. The wait state (red) indicates that the thread is waiting for Monitor's notification to share resources with other threads. Waiting for input-output status (purple) indicates that the thread's local code does not perform any procedures. This is often caused by an input/output operation, but it is also possible that other circumstances cause the code to not allocate CPU usage. Note: When the corresponding thread state should be updated and not updated, Optimizeit will show some points in the color bar. When the test program exits or does not collect information, the area of the unknown state will also be displayed in different types of patterns. Select the main thread "main" and click I/o-waiting View to switch to the wait I/O Watch window: Double-click the third row to see the line of code that is waiting in the Source code window. The program basically uses the standard input method. Closes the source window and returns to the thread Activity Monitoring window. You can also select a section in the thread window to analyze some of the information in that time. Return to the Control window and enter 2, then click Enter to start the second round of testing (using a small connection). Thread debugger shows the status of the currently running threads. You will see that there are 10 threads running at the beginning of a certain period of time. Online Event SupervisorDepending on the window, drag the scroll bar to the time range just now. If you do not want to continue to view thread activity information, you can uncheck the Update continuously option in the lower right of the window so that the information in the window does not change over time. During this time the yellow area indicates that the corresponding thread is blocked in a monitor. Click any part of the yellow bar directly on the thread bar, and hold down the left mouse button to move to the right. This time period is selected: After the selected time period: Click Contention View to analyze why the thread will block when it enters the monitors. This information represents only the selected time period. Click Waiting View to study where the thread waits for monitors. Again, this information is only the selected time range, so you should select the area of the Red Bar section of the diagram. Note: If the thread has exited or no longer exists, the thread name will appear in italics in the window. Understanding thread Contention in Java multithreaded applications if many threads simultaneously require the same monitors (which can be translated as a monitor or a pipe), it can cause serious performance bottlenecks. Monitors is used to protect shared resources by multiple threads, each with a monitors, while allowing only one thread to hold monitors for access to objects, and those that do not get monitors must wait. Until the thread holding the monitors releases the monitors. This part of the code that is protected by monitors, we call it the critical section. To optimize performance, we often have to keep as small a critical area as possible, especially if the critical section is performing some process that does not consume CPU resources. If a thread waits in a critical area because it waits for input and output, it no longer uses CPU resources. However, if other threads are waiting for this monitors, they will not be able to make full use of CPU resources. Here we use an example to illustrate the problem: Restart the tested program. After the program starts, enter 1 in the DOS window and press ENTER to start contention with a larger example. You will notice that there are 10 threads running in a certain period of time. Thread window, drag the scroll bar below the window to return to this time, and uncheck "Update continuously": you can see that this example takes longer to compete with the monitor than when it actually uses the CPU. To get a fuller picture of this, select any thread (such as thread 7) and click Contention View to switch to the Contention view window: Because contention Contentionexample$consumer.run () method 100% of the time spent on the blockage, The Contention monitoring console displays all of the monitor associated with the contention. Select Java.lang.ObjeCT Monitor. Contention details the console displays a list of all the threads associated with the contention, including when contention occurs. Open the first thread: Double-clicking on the Contentionexample$consumer.run () line pops up the source code for the method. In the source window display thread 7 is getting monitor, but the source window shows thread 1 while also acquiring Monitor: In the critical section protected by Monitor "lock", this example calls Method ProcessData (). This method simulates the input output in 1 milliseconds. This example shows that using too much contention can pay a high price. For a few milliseconds of CPU resources, each thread is likely to block for 1 seconds. In order to reduce contention, it is necessary to minimize the critical area when it is confirmed that the critical section is no longer waiting for contention. Our solution is simple by excluding data that does not need to be synchronized to handle narrowing the critical section. This code adjusts to: synchronized (lock) {  a = Datasourcea.nextelement ();  B = datasourceb.nextelement ();} ProcessData (A, b); The demo program also contains the test Usebiglock flags. Switch to the Thread monitoring window. Restart the program under test, enter 2 in the DOS window and press ENTER to run the second Test. The second Test also uses the same code, but this time the usebiglock tag is set to False. The contention time is reduced to just a few milliseconds per thread. Here are some tips to prevent performance problems caused by contention: Minimize the critical area. Contains only statements that need to be protected. Lock the lowest possible level. Add the explicit synchronized () statement before the Synchronized method. Synchronous methods are convenient to use, but can also cause excessive contention simply because the method of growing over time tends to complicate. Do not perform an I/O operation in the critical section unless the sole purpose is to protect the I/O descriptor or the object to perform I/O operations frequently. Guessing the level of contention is almost impossible. By monitoring the thread window, each significant change will see an incomprehensible level of contention. The common problem with understanding deadlock-multi-threaded applications is that threads are suspended when some threads are unable to obtain the resources they need. Deadlocks are a great challenge to the stack because they are often rare or even reproducible. A very small number of deadlocks can also cause a Web application to hang for a long time and cause a waste of resources. The Optimizeit Thread Debugger provides two powerful features to make debugging deadlocks easier. The first is for developers to mentionThe location for the deadlock to occur. The second feature, which is described in the next section, is to help developers monitor the operation of the application and give prompt hints when a deadlock occurs. Click the Monitor View button to switch to a window that displays all the threads and monitors in the Execution critical section. By default, the contents of the window are displayed in real time and updated every second. If necessary, restart the test program and enter 3 in the DOS window and then return to run a deadlock example. This deadlock is caused by a synchronous parameter error: Clicking any of the buttons in the diagram shows the stack trajectory below the window. You can double-click a row to view the corresponding source code. The thread color represents the same status as represented in the thread window. Once you click a button in the connection diagram, the monitoring content is no longer updated. You can click the button again or re-enter the window diagram to keep the update on. The deadlock of the watchdog is difficult to reproduce and understand deadlocks, and Optimizeit thread debugger provides a thread analyzer. When a Java program runs, the thread Analyzer logs and monitors all synchronization activities. Then search for any type that might cause the deadlock and give a list of warnings or error messages, including details of the critical section, such as where a deadlock might occur and the thread is invoked. Optimizeit Thread Debugger will be aware of the following types of locks that exhibit exceptions: Order of Locks: Two threads Enter the same monitors in different order, either directly or sequentially. Lock and wait: The thread enters a monitors and waits to enter the other monitors. Lock and I/O wait: The thread enters a monitors and then stops performing any tasks. Unless two threads never run at the same time, the sequence of locks often indicates the risk of being locked out. Locks on lock-and-wait and lock-and-i/o-wait types indicate a more normal situation if the monitor's purpose is to restrict access to resources that are waiting or are performing input and output. To confirm that a deadlock occurs, 3 threads in the sample program referred to in this article enter the same monitor simultaneously to get the data. Each thread uses a random function call, so that sometimes they enter the monitor in a different order. This program is only used to demonstrate, however, what happens when multiple threads are running in a large application and when dealing with some critical sections in a different order into the monitor. In this case, deadlocks often occur during execution, but whether or not the deadlock Optimizeit Thread Debugger parser will report some warning messages and error messages: Reopen the sample program if necessary. Click Monitor Usage Analyzer PressButton. Click the record to start recording the test process. A DOS window pops up after the program starts, enters 4 in the window, and presses the ENTER key to start the program running. Note: The parser can also be started by selecting the "Start Analyzer" option in the Edit Settings window. The symbol ' > ' appears in the window when blocking occurs in a certain order, and the symbol ' < ' appears in another order when blocking occurs. Finally, the program stops, but the menu does not appear again. This means that a deadlock has occurred. Press ENTER to display the menu again: Click the record to stop recording again. Select the first error message and switch to the Analysis window: Click on the method name to invoke the source code. The Close source window returns to the monitor using the Analysis window. Here are some tips to avoid deadlocks: make the lock as simple as possible. Two threads using a monitors to share resources do not have deadlocks, and they will never block during a critical section. Do not perform an input/output operation after entering the monitors, unless the monitor is used to protect input and output. Do not wait for another monitors when entering another monitors, unless it is absolutely necessary and understandable. Always enter the monitors in the same order. Do not invoke the public synchronized method when holding a lock. Too many live locks in multi-threaded applications another type of typical problem is having too many locks. When the virtual machine is optimized, it is able to enter multiple monitors very quickly, reducing the use of monitors can greatly improve performance. Optimizeit Profiler can be used to measure how long each method is used, including time to enter monitors, and Optimizeit Thread Debugger enables developers to understand the frequency and location of the monitor's use, Regardless of whether a contention has occurred: the thread window selects one or a time range and then clicks the Monitor Enter button to switch to the Monitors Details view window. For example, after selecting the main class, click the window that appears as follows: You can see that the main class has entered 22 monitor.   This article is just an overview of Optimizeit Thread debugger. For more information about Optimizeit, check the Optimizeit Thread Debugger User's Guide.   Translation:wyingquan@hotmail.com  time: 2004-11-11 If you are interested in this article or white box test, please login to http://groups.yahoo.com/group/ whiteboxtestcn/, join the membership, you can download to the full content of this article (formatA Word document for a stay picture, here are some other white box test tools for introductions and related discussions.