Java Line programming, State synchronization, volatile, thread.interupt, and Concurrentlinkedqueue

In some strict systems, we need to do a clean stop thread and clean up the State. Related to this topic will bring out a lot of relevant points, the simple summary is as Follows:

We know that in java, there is a volatile keyword whose official description (https://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html) is:

Using volatile variables reduces the risk of memory consistency errors, because any write to a volatile variable establishes a h Appens-before relationship with subsequent reads of that same variable. This means, changes to a variable is always visible to the other volatile threads. What's more, It also means this when a thread reads a volatile variable, it sees isn't just the latest change volatile to the, but Also the side effects of the the code that led up the Change.

It can be assumed that the value written to the volatile variable is always visible to other threads, and when a thread reads to a volatile variable, not only is its value up to date, but the other code that uses the altered judgment also changes in Cascade.

however, the scope of the volatile is limited to every time the value is read from the heap, after entering the body of the method, if the execution of longer or always in the loop, such as the thread of the run () method, during the change of volatile to the method body is not visible, so this need to note that if it must be effective, Then we'll wrap up a method.

If you do not want to add a method, you can consider using concurrentlinkedqueue, you can start empty, and then poll to determine the way status.poll () = = NULL is Implemented.

thirdly, we know that thread has a stop and interupt method that terminates the Thread. Because stop is already @deprecated, it is assumed not to be used. Look at the side effects of interupt, for many programs such as log4j, in fact, the use of interupt and no side effects, but in some cases, the use of interrupt will lead to unnecessary system inconsistencies, see interrupt javadoc, as Follows:

Interrupts this Thread.

Unless the current thread is interrupting itself, which are always permitted, the checkAccess method of this thread is invoked, W Hich cause A to be SecurityException thrown.

If this thread was blocked in an invocation of the wait() , wait(long) , or wait(long, int) methods of the Object class, or of join() the, , join(long, int) , sleep(long) , or sleep(long, int) , methods of this class, then its interrupt status would be cleared and it'll receive InterruptedException an .

If this thread was blocked in an I/O operation upon an interruptible channel then the channel would be CL osed, the thread ' s interrupt status would be set, and the thread would receive a ClosedByInterruptException .

If this thread was blocked in a Selector then the thread ' s interrupt status would be set and it would return Immediatel Y from the selection operation, possibly with a non-zero value, just as if the selector ' s wakeup method were Invo ked.

If none of the previous conditions hold and this thread ' s interrupt status would be Set.

Interrupting a thread, which is not alive need, has any effect.

therefore, the first two methods should be used Generally.

Java Line programming, State synchronization, volatile, thread.interupt, and Concurrentlinkedqueue