Java multithreaded programming in the actual combat of the methods not advocated

Methods that are not advocated are those that are reserved for backward compatibility, which may or may not appear in future versions. Java multithreading support has made significant revisions in version 1.1 and version 1.2, and the Stop (), suspend (), and resume () functions are not advocated for use. These functions may introduce subtle errors in the JVM. Although function names may sound tempting, resist the temptation not to use them.

Debugging a threaded Program

Some of the most common and annoying situations that can occur in an online program are deadlocks, live locks, memory corruption, and resource exhaustion.

Dead lock

Deadlocks can be the most common problem with multithreaded programs. A deadlock occurs when a thread needs a resource and another thread holds the lock on that resource. This situation is often difficult to detect. However, the solution is pretty good: get all the resource locks in the same order in all threads. For example, if you have four resources-A, B, C, and D-and a thread might want to get a lock on any of the four resources, make sure that you get a lock on a before you get a lock on B, and so on. If thread 1 wants to acquire a lock on B and C, and thread 2 gets the locks of a, c, and D, this technique may cause blocking, but it will never cause deadlocks in these four locks.

Live lock

A live lock occurs when a thread is too busy accepting a new task that it never has a chance to accomplish any task. This thread will eventually exceed the buffer and cause the program to crash. Imagine a secretary needs to enter a letter, but she has been busy answering the phone, so this letter will never be entered.

Memory corruption

If you use the Synchronized keyword wisely, you can completely avoid memory errors. The problem of the dead.

Resource Exhaustion

Some system resources are limited, such as file descriptors. Multithreaded routines can run out of resources because each thread may want to have one of these resources. If the number of threads is quite large, or if the number of selected threads for a resource far exceeds the number of available resources, it is best to use a resource pool. One of the best examples is the database connection pool. As long as the thread needs to use a database connection, it takes one out of the pool and returns it to the pool after use. Resource pools are also called resource libraries.

Debug a large number of threads

Sometimes a program is extremely difficult to debug because it has a large number of threads running. In this case, the following class might come in handy:

public class Probe extends Thread {public
Probe () {} public
void Run () {while
(true) {
thread[] x = NE　　W thread[100];
Thread.enumerate (x);
for (int i=0; i<100; i++) {
Thread t = x[i];
if (t = = null) break
;
else
System.out.println (t.getname () + "T" + t.getpriority ()
+ "T" + t.isalive () + "T" + T.isdaemon ()); 
  }}}