Java multi-thread programming trap summary 3

Trap 9: Volatile only emphasizes data visibility, and does not guarantee atomic operation and thread security.

Volatile only emphasizes data visibility and does not guarantee atomic operations and thread security. Therefore, volatile is not omnipotent. Reference Command Re-sorting

Volatile is most common in the following two scenarios.

A. Cyclic Detection Mechanism

Volatile Boolean done = false;

While (! Done ){
Dosomething ();
}

B. Singleton model (http://www.blogjava.net/xylz/archive/2009/12/18/306622.html)

Public class doublelocksingleton {

Private Static volatile doublelocksingleton instance = NULL;

Private doublelocksingleton (){
}

Public static doublelocksingleton getinstance (){
If (instance = NULL ){
Synchronized (doublelocksingleton. Class ){
If (instance = NULL ){
Instance = new doublelocksingleton ();
}
}
}
Return instance;
}
}

 Trap 10: Lock cannot completely replace synchronized

It seems that lock has better performance and more flexible control. Can it completely replace synchronized?

As mentioned in some other questions about the lock, the performance of synchronized increases with the upgrade of the JDK version, and the space for Lock optimization is limited by the CPU performance. In addition, the JDK internal tool (thread dump) has some support for synchronized (to facilitate the identification of deadlocks, etc.), but does not support lock.

That is to say, synchronized can be used in simple logic. As the performance of the machine increases, this overhead can be ignored. In addition, the code structure is simpler. Simple is beautiful.

For complex logic, if it involves read/write locks, conditional variables, higher throughput, and more flexible and dynamic usage, you can consider using locks. Of course, pay special attention to the correct usage of lock here.

Lock =
Lock. Lock ();
Try {
// Do something
} Finally {
Lock. Unlock ();
}

Make sure to release the lock into the Finally block. Otherwise, once an exception or logical jump occurs, the lock may not be released, resulting in a deadlock. In addition, such deadlocks are difficult to troubleshoot.

If synchronized cannot be used to try the lock mechanism, or you are worried that a deadlock cannot be restored, trylock () is a wise choice.

Lock =
If (lock. trylock ()){
Try {
// Do something
} Finally {
Lock. Unlock ();
}
}

You can even use the lock timeout mechanism lock. trylock (long, timeunit ). For the use of the lock, refer to the description and suggestions in the previous article.

Trap 11: The more threads, the better.

The higher the number of threads, the better. In the next article, we will learn more about performance and scalability. Simply put, there is no fixed conclusion about the number of threads, limited by the number of CPU cores, Io performance, and dependent services. Therefore, selecting an appropriate number of threads helps increase throughput.

For CPU-intensive applications, the same number of threads as the number of CPU cores helps increase the throughput. All CPUs are busy and the efficiency is high. For Io-intensive applications, the number of threads is limited by the performance of Io. In some cases, a single thread may be more efficient than multithreading. However, increasing the number of threads is usually conducive to improving the network I/O efficiency, because we always think that the network I/O efficiency is relatively low.

For the thread pool, selecting the appropriate number of threads and task queue is a way to improve the efficiency of the thread pool.

Public threadpoolexecutor (
Int corepoolsize,
Int maximumpoolsize,
Long KeepAliveTime,
Timeunit unit,
Blockingqueue <runnable> workqueue,
Threadfactory,
Rejectedexecutionhandler handler)

 

For the thread pool, if there is always a backlog of tasks, you can appropriately increase the corepoolsize. If the machine load is low, you can appropriately increase the maximumpoolsize; when the task queue is not long, reducing the KeepAliveTime time helps reduce the load. In addition, the length of the task queue and the denial policy of the task queue also affect the processing of the task.