1

I have a Java service that is multi-threaded. This a publisher-subscriber application.

There is a message bus and there are several plugin components listening to the message bus. Each request from a plugin is handled by the message bus in a separate thread. It runs as a Windows service.

In the stop method, currently what I am doing is calling System.exit(0). In several other similar questions, some people have said it to be a bad practice, while some others claim that it is fine. Even Sonarqube complains about it.

So what it is the graceful way to stop all these threads? Should I call Thread.interrupt on them?

These clients are continuously listening to the message bus and if any event messages are received they process it.

Erwin Bolwidt
  • 30,799
  • 15
  • 56
  • 79
AnOldSoul
  • 4,017
  • 12
  • 57
  • 118
  • If you know for a fact that it is safe to interrupt whatever it is that your threads are doing, `System.exit(0)` is fine and in fact preferable. If a thread might be doing something - writing to a file, say - that can't be safely interrupted, then you need to be more careful. – Harry Johnston Jan 01 '16 at 12:02
  • Can you please mark my answer correct if it serves the purpose? – Aaditya Gavandalkar Jan 04 '16 at 18:58
  • @AadityaGavandalkar I can use thread.interrupt to interrupt the main thread. But how do I close the threads and exit? Simply what will be my stop method implementation? I tried this but doesn't work. http://stackoverflow.com/questions/34589614/java-service-gets-hung-when-stopping – AnOldSoul Jan 04 '16 at 23:09

1 Answers1

1

Using Thread.interrupt() is a perfectly acceptable way of doing this. The reason being that if you're in an interruptable blocking call (like Thread.sleep or using java.nio Channel operations), you'll actually be able to break out of those right away.

More details on this SO question and here

For more detailed explanations visit: here

Summary:

  • thread.interrupt() does not stop a thread. It is used for coordination in multi-threaded programs. Don't use it unless you know exactly what you do.
  • Throwing a RuntimeException will (usually) terminate the thread but not necessarily the program.
  • System.exit(int) almost always terminates the program and returns a status code.
  • In unusual situations, System.exit(int) might not actually stop the program.
  • Runtime.getRuntime().halt(int) on the other hand, always does.
Community
  • 1
  • 1
Aaditya Gavandalkar
  • 814
  • 5
  • 17
  • But when calling System.exit, it does kill the threads using Thread.interrupt right? So why is it a bad practice? – AnOldSoul Jan 01 '16 at 06:09
  • After stopping a thread, we should ensure the thread is actually stopped before the program can continue to do other things. To do that, we can simply call Thread.join() at the calling thread and it will wait until the working thread is stopped. This cannot be achieved after you call `System.exit()` – Aaditya Gavandalkar Jan 01 '16 at 06:17
  • I guess the OP doesn't want the program to continue to do other things, so while that can't be achieved with `System.exit()`, it doesn't seem to be something the OP is looking for. – Erwin Bolwidt Jan 01 '16 at 06:29
  • When you call `System.exit()` it will stop the execution of the thread at that point and not call any finally blocks (which might contain cleanup code I assume, as it being a good practice to do so). – Aaditya Gavandalkar Jan 01 '16 at 06:33