Optimizeit Thread Debugger overview
This article introduces some of the main features of Optimizeit Thread Debugger to make you a brief understanding. If you want to learn more, please see the Optimizeit Thread Debugger User Manual, or from the Optimizeit Thread Debugger Click Main Menu INFO | Help to view all documents.
If you have any questions, please feel free to contact Borland Technical Support.
test
Java
program
Optimizeit Thread Debugger is the overlay information of the program from the virtual machine running program.
First run a Java program, you need to install a Java virtual machine. Optimizeit Thread Debugger default installation configuration JDK 1.4 OR 1.4.1. If you want to use additional virtual machines, you can view how the Optimizeit Thread Debugger user manual adds a new virtual machine section. Collect the override information of the program from the virtual machine of the runtime.
First run a Java program, you need to install a Java virtual machine. Optimizeit Thread Debugger default installation configuration JDK 1.4 OR 1.4.1. If you want to use additional virtual machines, you can view how the Optimizeit Thread Debugger user manual adds a new virtual machine section.
Launch application
Optimizeit Thread Debugger can test any type of Java program, such as standard applications, app, servlets, JSPS, EJBS. The test program used herein is included in the / doc / thread_debugger / quicktour directory. All tests are performed in Optimizeit Thread Debugger:
Open Optimizeit Thread Debugge. If you are open for the first time, you will automatically pop up the editing setting window. If you have already opened, you can select New Setting from the File menu to call the Edit Settings window. Select Application in the Program Type box. Click the "Browse ..." button on the right of "Program Main Class or Jar File". Find /Doc/thread_debugger/quicktour/threadDexample.class file, then click Open. Optimizeit Thread Debugger will return to the settings window and automatically bring the program's workspace and classpath. In the Source Path box, click the Change ... button. In the Source Path Chooser window, select the / doc / thread_debugger / quicktour directory under the installation path; select the down button in the window to add it to the Source path section. Click OK to add to the source file in the source file. Set the good dialog box as follows:
Check the Open a console option; this is very important, because this program needs to enter some commands to run. Click the Start Now button. The editing setting window will automatically shut down, Optimizeit Thread Debugger will start the test program.
View thread
Thread Debugger The default open is the thread monitor window. You can also redefine the default open window to find where the program hangs or time consumes:
After the program is started, the Optimizeit Thread Debugger opens a DOS window, enter 1 in the DOS window, then press Enter to start the first round of test. The Thread Debugger window displays the current running thread and their respective running status:
Different colors are used in the entire window to display the current thread operation status:
Running status (green) indicates that the thread is running and using the CPU. The clog state (yellow) indicates that the thread is not run because it occurs when entering Monitor. Waiting Status (red) means threads waiting for Monitor to share resources with other threads. Wait for the input and output status (purple) indicates that the local code of the thread does not perform any process. This is often caused by an input / output operation operation, but it may be caused by other situations resulting in no assignment of the CPU to the code. Note: When the corresponding thread state should be updated without updating, Optimizeit will display some points in the color strip. When the test program exits or does not collect information, the unknown area will also be displayed in different types.
First select the main thread "main", then click I / O-WAITIW View to switch to the waiting I / O monitor window:
Double-click the third line, you can see the line of code that happens from the source code window. This program basically uses a standard input method. Turn off the source window and return to the thread activity monitor window. You can also select some of the information in this time in the thread window. Returns to the control window and enter 2, and then click Enter to start the second round of test (using a small connection). Thread Debugger shows the status of the currently running thread. You will see 10 threads running in a certain period of time. In the thread activity monitoring window, drag the scroll bar to the time range just. If you don't want to continue to view thread activity information, you can uncheck the Update Continuously option in the lower right below the window so that the information in the window will change over time. In this time, the yellow area indicates the corresponding thread blockage in a monitor. Click any part of the yellow strip on the thread strip and press and hold the left mouse button to move. This will select this period of time:
After selecting the time period:
Click Constion View to analyze why the thread occurs when you enter Monitors. This information is intended to select a time period. Click Waiting View to study the thread where to wait for Monitors. Similarly, the information is only the selected time range, so the area of the red strip portion in the figure should be selected.
Note: If the thread has exited or no, the thread name is not displayed in the window.
Understand the line
In the Java multi-threaded application, if many threads need the same MONITORS (which can be translated as a monitor or duct), it will cause a serious performance bottleneck. Monitors is used to protect shared resources simultaneously by multiple threads. Each object has a monitors, and only one thread is allowed to hold Monitors to perform access to objects, those threads that have not got Monitors must wait until they hold Threads with Monitors release Monitors. This section is protected by Monitors, we call it critical area.
To optimize performance, we often have to maintain small critical regions as much as possible, especially when the critical regions are executing some processes that do not consume the CPU resource. If a thread is waiting in the critical area, it will no longer use the CPU resource. However, if other threads are waiting for this Monitors, they cannot fully utilize the CPU resources.
Below we use examples to explain this problem:
Restart the test program. After the program is started, enter 1 in the DOS window and press the Enter key to start the contention of the contention. You will notice that there are 10 threads in a certain period of time. On the thread window, the scroll bar under the drag window returns to this time and uncheck "Update Continuous":
It can be seen that the time spent in Monitor is longer relative to the actual use of the CPU. In order to more fully understand this, select any threads (such as thread 7) and click Constion View to switch to the contention View window:
Because the contentionexample $ consumer.run () method is 100% spent on the block, all the monitor related to the contention is displayed on the monitor console. Select Java.lang.Object Monitor. Striving Detailed Description The console will display all threads related to this contention, including when it happened. Open the first thread: Double-click on the ContentionExample $ consumer.run () to pop up the source code of the method. In the source window display thread 7 is being acquired, however, the source window is displayed under the source window and is also acquired by Monitor:
In this case, Method ProcessData () is called in this case in the critical part of the Monitor "Lock". This method simulates the input and output in 1 millisecond.
This example shows that too much contention will pay a lot. For a few millisecond CPU resources, each thread is generally blocked for 1 second. In order to reduce the occurrence of contention, it is necessary to minimize the critical regions when confirming that the critical regions are no longer waiting for the contention.
Our solution is simple, which is to handle reduced critical regions by excluding data that does not require synchronous processing. This code is adjusted to:
Synchronized (LOCK) {
a = datasourcea.nextelement ();
B = DatasourceB.nexTelement ();
}
ProcessData (A, B);
The presenter also contains the case of testing the USEBIGLOCK flag. Switch to the thread monitor window. Restart the measurement in the DOS window, press 2 to press Enter to run the second test after entering 2 in the DOS window. The second test is also used the same code, but this time the usebiglock tag is set to false. The consideration time is reduced to each thread only a few milliseconds.
Here are some techniques to prevent performance problems due to contention:
Try to minimize critical regions. Only statements that need to be protected are included. Locks the minimum level. Plus the explicit synchronized () statement before the Synchronized method. It is very convenient to use the synchronous method, but it may also lead to excessive contention, just because of the growth method of time. Do not perform an I / O operation in the critical region unless the unique purpose is to protect I / O descriptors or objects often perform I / O operations. Guess the level of contention is almost impossible. By monitoring the thread window, each major change will see a contention level that is difficult to understand.
Understand dead lock
The common problem facing multi-threaded applications is that the thread is hang because some threads cannot get the resources they need. The deadlock is a great challenge to the stack because it often does not even recover. A very small deadlock is also possible to cause a web application to hang up for a long time and cause resource waste.
Optimizeit Thread Debugger provides two powerful features to make debug-off locks easily. The first is to provide the developer's position where the deadlock occurs. The second feature will be described in the next part, and it is to help developers to monitor the operation of the application, and once a deadlock will be prompted in time.
Click the Monitor View button to switch to the window where the threads and monitors that execute the critical part. By default, the content of the window is displayed in real time and is updated per second. If necessary, restart the test program and enter the DOS window input 3 and then enter the example of a deadlock. This deadlock is caused by a synchronized parameter error:
Click any of the points in the figure, the corresponding stack trajectory is displayed below the window. You can double-click a row to view the corresponding source code. The state represented by thread colors is the same as in the thread window. Once a button in the connection diagram is clicked, the monitoring content is no longer updated. You can continue to update again if you click on the button again or re-enter the window chart.
Monitor procedure deadlock
Because of the difficulty and understanding of dead locks, Optimizeit Thread Debugger provides a thread analyzer based on this. When a Java program is running, the thread analyzer records and monitors all synchronization activities. Then search any of the types that may lead to deadlocks and give a list of warnings or error messages, including detailed information on the critical regions, such as where there is a possibility of deadlock and calling that thread. Optimizeit Thread Debugger will pay attention to monitoring the following performance unusual lock types:
The order of the lock: two threads enter the same monitors in different orders in different orders. Lock and waiting: Threads go into a monitors and wait for the other Monitors. Lock and I / O Wait: Threads enter a monitors and stop executing any tasks.
Unless the two threads will never run at the same time, the order of locks often indicate the risk of being locked. Locks for Lock-Wait and Lock-And-I / O-Wait types, indicate that the situation is normal, if the purpose of the monitor is to limit access to resources that are waiting or being executing input and output.
In order to confirm the deadlock, there will be 3 threads in the sample programs referred to herein to enter the same monitor at the same time to obtain data. Each thread uses a random function call, which sometimes enters the monitor in different order. This program is only used to demonstrate, however, it can be thought of when multiple threads run in a large application and how different sequential enters the monitor when processing some critical regions.
This example often occurs during the execution, but no matter whether there is a deadlock Optimizeit Thread Debugger analyzer, some warning information will be reported to the error message:
If necessary, please reopen the sample program. Click the Monitor USAGE Analyzer button. Click Record to start recording the test process. A DOS window pops up after the program is started, enter 4 in the window and press Enter key to start the program.
Note: The analyzer can also start by selecting the "Start Analyzer" option in the Edit Settings window.
The display symbol '>' in the window occurs at a certain order, and the symbol '<' is displayed when blocking occurs in an additional order. Finally, the program will stop, but no menus will appear. This means a deadlock occurs. Press the back key to re-display the menu:
Click Record to stop recording again. Select the first error message and switch to the analysis window:
Click on the source code on the method name. Turning off the source window Returns to the monitor using the analysis window.
Here are some techniques to avoid deadlocks:
Simple as much as possible. Two threads use a Monitors to share resources that will not have a deadlock, and they will never block occurs during the critical area. Do not perform an input and output operation after entering Monitors unless the monitor is used to protect the input and output. Do not wait another Monitors when entering another Monitors unless it is necessary and is understandable. Always enter Monitors in the same order. Do not call the common synchronized method when holding a lock.
Excessive live lock
Another type of typical problem in multi-threaded applications is too many locks. Once the virtual machine is optimized, you can 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 the time to enter Monitors, while Optimizeit Thread Debugger enables the developer to understand the frequency and location used by the monitor, whether it is considered:
After selecting a thread or a time range after the thread window, click the Monitor Enter View button to enter the Monitors more check the window. For example, click the window as shown below after selecting the main class:
You can see that the main class enters 22 Monitor.
This article is just an overview of Optimizeit Thread Debugger. If you want to learn more about Optimizeit, see the Optimizeit Thread Debugger User Guide. translation:
Wyingquan@hotmail.com Time: 2004-11-11
If you are interested in this article or a white box test, please visit
http://groups.yahoo.com/group/whiteboxtestcn/
Join the member, you can download the complete content of this article (the format is a Word document with a picture), and there are other white box test tools here, and related discussion.
