preface

How to interrupt a thread, definitely not using stop. Instead, use the interrupt method. Also, we know that interrupting a thread is just a flag bit. It doesn’t really interrupt the thread, but what if the thread is blocked?

In Java, there are many ways to block a thread.

  1. synchronized
  2. Object.wait()
  3. Lock
  4. Condition.await()
  5. LockSupport.park()
  6. Thread. The join ()

Of course, the above is very simple to say, the API is not that detailed. Apis like Lock respond to interrupts. There is Thread. Sleep (). You know this, it must be responding to interrupts.

So let’s solve our problem.

To solve the fog

After careful analysis, interrupts actually have two states, interrupts at run time and interrupts at block time.

As the name implies, runtime interruption means that when a thread is running, we interrupt it, which of course has no effect on the thread, only by flag bits.

Blocking interrupts fall into two categories. One is to interrupt while waiting for a lock, the other is to interrupt while waiting for a lock.

For example, a synchronized block. When multiple threads access a synchronized block, the state outside the synchronized block is waiting for a lock. Enter lock, execute wait, also block state.

Although both are blocking states, the two blocking states are different.

Based on the blocking mode in the preface, we analyze them one by one.

To summarize

Non-lock interfaces, namely synchronized, Object, and Thread related methods, except synchronized does not respond to interrupts, and all others respond to interrupts and throw exceptions.

The Lock interface, whether using the Lock family of methods or the await family of methods in Condition, is free to use whatever schema you want. This feature is very useful in daily development.

Lock-related interfaces are more flexible in their response and handling of thread interrupts, whereas non-Lock interfaces need to be aware of their interrupt nature.

The sleep and wait methods, for example, clear the interrupted state.

The Lock family of methods also clears the interrupted state when they throw an exception.

Lock clears the interrupted state using the Thread.interrupted method.

Why clear the interrupted state? The next time a thread interrupts again, you can tell.

Note the difference between the thread.interrupted static method and the Thraed#isInterrupted() member method

They are both called by the private native Boolean isInterrupted(Boolean ClearInterrupted) method of the Thread class.

This method takes a Boolean argument: true clears the interrupt state, false does not. Use it with care.

gleanings

The shutDown and shutDownNow methods of the thread pool stop a thread by setting it to abort.

ShutDown must wait for the task to complete before executing the interrupt method on the thread pool thread. ShutDownNow doesn’t implement interrupt directly.

So, when you execute a shutDown method, you must wait for the task to complete before setting the interrupt state. The interrupt response methods you set up in your code will not work. What matters is the state variable set inside the thread pool. Interrupt is set up to interrupt a thread that is blocking on a queue.

When you execute the shutDownNow method, the thread pool will execute interrupt methods for all active threads if you happen to have any of the above interrupt methods in your task. Then, the thread can be interrupted immediately. If not, wait for the task to finish.

Interesting things

When the Worker of the thread pool is initialized, the state variable of AQS will be set to -1 to prevent users from executing shutDown method to try to stop the thread. The AQS variable is set to 0 when the actual task is about to be executed, and only when the user executes shutDwon is valid. What about the shutDownNow method? Similarly, it is determined that the state variable must be greater than or equal to 0 to execute the interrupt method. Keep the thread pool as a whole state safe.

In fact, the article is still a bit cluttered and full of stuff. But it’s all about thread interrupts.

Familiarity with these apis is important for concurrent programming.

To summarize again

What does this article say:

  1. Which synchronization and lock-related apis in Java respond to interrupts and which do not. The bottom line is that Lock is more flexible with interrupts.
  2. The static method clears the interrupt state, but the member method does not.
  3. The shutDownNow method of the thread pool decides whether to interrupt the task immediately based on whether there is an API in the task that responds to interrupts. If so, it interrupts immediately, and if not, it waits for the task to complete.
  4. Interesting phenomenon of thread pool: When Worker is initialized, a variable is set to -1 to prevent users from calling shutDown and shutDownNow methods during initialization.