Practices that are not recommended in Java multi-thread programming

In practice, Java multi-thread programming does not advocate the use of methods, but does not advocate the use of methods that are reserved to support backward compatibility. They may appear in future versions, or not. Java multithreading support has been significantly revised in versions 1.1 and 1.2. The stop (), suspend (), and resume () functions are no longer recommended. These functions may introduce subtle errors in JVM. Although function names may sound attractive, resist the temptation not to use them.
Debug a threaded Program
In a threaded program, some common and annoying situations may occur: deadlocks, live locks, memory corruption, and resource depletion.
Deadlock
Deadlock may be the most common problem in multi-threaded programs. A deadlock occurs when one thread needs a resource and the other thread holds the lock of the resource. This situation is usually difficult to detect. However, the solution is quite good: Get all resource locks in the same order in all threads. For example, if there are four resources-A, B, C, and D-and A thread may need to obtain the Lock of any of the four resources, ensure that the lock on A is obtained before the lock on B is obtained, and so on. If "thread 1" wants to obtain the locks for B and C, and "thread 2" gets the locks for A, C, and D, this technology may cause blocking, but it will never cause deadlocks on these four locks.
Live lock
A life lock occurs when a thread is busy accepting new tasks and never has the chance to complete any tasks. This thread will eventually exceed the buffer and cause program crash. Imagine a secretary needs to input 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 avoid memory errors.
Resource Depletion
Some system resources are limited, such as file descriptors. Multi-threaded programs may use up resources because every thread may want such a resource. If the number of threads is large, or the number of waiting threads for a resource exceeds the number of available resources, it is best to use the resource pool. The best example is the database connection pool. As long as the thread needs to use a database connection, it will retrieve one from the pool and then return it back to the pool. A resource pool is also called a resource pool.
Debug a large number of threads
Sometimes it is very difficult to debug a program because a large number of threads are running. In this case, the following class may come in handy:
Public class Probe extends Thread {public Probe () {} public void run () {while (true) {Thread [] x = new 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 ());}