Shulou(Shulou.com)06/02 Report--

Java concurrent programming related concepts and matters needing attention, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

The concrete expression form of the corresponding concept in Java, as well as some problems that should be paid attention to in use.

In Java concurrent programming, the word synchronized is bound to be heavily used in the early days, unless developers are familiar with the relevant utility classes in the J.U.C package.

Here synchronized is also known as implicit lock, built-in lock, or pipe lock, all of which refer to the same one, so don't be surprised to see it with a new concept. The lock here seems to be invisible, and we developers only use it through keywords, without worrying about the details of lock acquisition, release and so on.

In essence, implicit locking is realized by adding instructions related to monitor enter and exit at the JVM instruction level.

For example, the following lines of code:

Object o = new Object ()

Public void test () {

Synchronized (o) {

System.out.println (o)

}

}

The converted jvm instruction is as follows. Note the monitor instruction.

Compared with synchronized, reentrant locks and read-write locks in J.U.C require developers to acquire and release explicit locks, and the two are implemented in different ways. Depending on the usage scenario, if you need finer-grained control locks, you can use the implementation of J.U.C.

Another thing that is often used and easily misused in Java concurrent programming is volatile.

We usually use volatile to set and judge some important logos, such as this.

Public static volatile boolean shutDown = false

In this case, when other threads change the identity, visibility can be guaranteed for subsequent threads.

For this type of declaration, volatile alone is not satisfied:

Public static volatile int count = 0

If here, we use count as a counter to count++ each thread's request. At such times, the results will not live up to expectations unless we explicitly add locks.

This is because the whole count++, is not a whole, although it seems to be indivisible in form. But it is actually composed of the steps of taking a value, adding 1, and assigning a value. When multithreaded execution, it is easy to cause confusion, and the final result is not in line with expectations.

It is also impossible to achieve secure count++ with volatile. After all, its function is to restrain CPU from reordering instructions, and to get the latest results in real time for both writing and reading, and is not affected by JMM. In order to achieve safe counting or increment, the intervention of lock is needed to ensure that the operation of the whole count++ is mutually exclusive. In the whole critical area, the operation of one thread on count is not affected by other threads.

In addition, one of the issues to be aware of when using synchronized for locking in Java concurrent programming is:

The wait and notify of the lock cannot be performed until you own the lock.

Otherwise you will encounter this exception:

Exception in thread "main" java.lang.IllegalMonitorStateException

It's like a man shouting to give you his bread, but he only has air in his hand. And you spit in his face:)

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.