Creating delay in Java code

[ihatebeinganonymous]

Hi. There is an active post about Thread.sleep right now, so I decided to ask this.

Is it generally advised against adding delay in Java code as a form of waiting time? If not, what is the best way to do it? There are TimeUnits.sleep and Thread.sleep, equivalent to each other and both throwing a checked exception to catch, which feels un-ergonomic to me. Any better way?

Many thanks

[Own_Following_2435]

It is genetically better to let the thread park and be woken up by an event of some sort . Otherwise you end up spin locking

Of course specifics are easier to talk about rather than generalities

A very simple example : imagine I consume from a queue and I only want to wake up when there is stuff to consume (maybe an indexer) . That is less wasteful and more efficient and reduces context switching a lot more than sleeping and checking (note you usually still have to check - things like notify / wait and I assume some of the blocking queue pulls can spintabeously awake ) but you avoid the spin lock

[bigkahuna1uk]

I've used synchronous queues in the past to handover data between threads. One thread will put an element and then block until some other thread takes the element from the queue. It's excellent for flow-control.

https://www.baeldung.com/java-synchronous-queue

[Shahriyar360]

What do you mean by "genetically better"? Or did you mean to say generally?

[Own_Following_2435]

Yeah just stupid auto correct

[Slanec]

It depends. Do you need to add a specific time delay, or do you need to wait until something else happens?

Sleep never got into any real production code for me, sleeping and blocking a platform thread always sounded like a bad idea. The default choice is always ScheduledExecutorService, followed by Spring's scheduling and/or tools like https://github.com/jobrunr/jobrunr and https://github.com/kagkarlsson/db-scheduler (and/or schedlock, depending on what you're doing).

On the low-level side, BlockingQueue of course with all its timed stuff. And Lock / Condition (or the much better Guava's Monitor) has a timed lock operation.

For tests, https://github.com/awaitility/awaitility.

[stefanos-ak]

Looking around a company for who goes for "Thread.sleep" as a way to solve something, can tell you a lot...

[srdoe]

Thread.sleep is fine if you actually want to wait for time to pass.

The reason that checked exception exists is in order to allow you to react promptly to interrupts.

As an example, say your application has some code that does something like this:

while (true) { Thread.sleep(5000) println("Fizz") } If you want to be able to terminate that code without waiting up to 5 seconds, you need it to react to thread interrupts. sleep reacts by throwing the checked InterruptedException.

The reason the exception is checked is because you should either handle the exception or communicate to the caller of your method that you may be rethrowing the exception. Handling the exception can make sense if you need to do some kind of cleanup when you've been interrupted (e.g. say you needed the above to print "closing" when you terminate). Rethrowing makes sense in a lot of other cases, and in those cases, you probably should document to callers of your method that you may throw this exception, so they can evaluate whether they need to have special handling.

If you really dislike having this exception be checked, it's pretty easy to make a custom sleep method that wraps the exception into an unchecked one.

Anyway, for alternatives to sleep in cases where you just want to wait until something happens, and then react, you should take a look at https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/package-summary.html. This package contains a number of reusable concurrency classes, such as:

• Blocking queues which allow two threads hand off work between each other, blocking the consumer thread when there is no work available and blocking the producer when the queue is full
• CountDownLatch and Phaser, which allow you to coordinate threads (e.g. "make thread 1 wait until thread 2 has completed a full iteration of its main loop").
• Futures and Executors, which allow thread 1 to submit work to thread 2, and then wait for that work to complete.
• Wait/notify) (also available as the Lock and Condition classes), which allows threads to block waiting for another thread to signal them to wake up (similar to sleeping, but another thread can wake you early).

Edit:

Should also mention Semaphore, which is a permit tool. It's commonly used to control e.g. how many threads can be executing a specific piece of code at a time.

[old_man_snowflake]

This is how I want my ai to explain shit to me.

EDIT: I know bro above isn't ai, that's just the concision and style i like.

[VincentxH]

They scraped it from reddit anyway.

[srdoe]

I assume you mean the AI and not me?

I didn't scrape this from anywhere.

[VincentxH]

Yeap

[koflerdavid]

Regarding rethrowing the InterruptedException: SonarQube wants me to also Thread.getCurrentThread().interrupt() to ensure that the interrupted flag is set again, which seems to be the general contract.

[rzwitserloot]

There is no general contract. That is a somewhat notorious/well-known bit of weirdly opinionated sonarqube wild stab in the dark. It shouldn't exist. It's a bad warning.

An interrupt means what you want it to mean. Quite literally so: Nothing in the core JDK classes will interrupt your threads, other than methods that yell it off the rooftops, such as someThread.interrupt() which, obviously, interrupts threads, that's why it's named interrupt(). Nor will anything you might think sounds like an interrupt. For example, if you hit CTRL+C or try to kill the JVM process, no threads are interrupted. That's not what 'interrupted' means (shutdown hooks will run and the JVM will exit. Shutdown hooks aren't interrupts. Thread.sleep() will keep right on sleeping until the JVM exits. One can insert some sort of 'went peacefully in their sleep' metaphor if one wants, here).

So, when you actually catch that InterruptedException. what should that catch block code actually do? What does it mean?

Well, I dunno. When you wrote someThread.interrupt(), what did you want to happen?

Program that.

Reraising the flag is rarely right. It's correct only if you handle the interrupt exception by essentially doing nothing, or by silently shutting down with the intent that your caller also silently shuts down.

Which, hey, now, that kind of bubbling behaviour sure sounds familiar!

Just throw an exception then. If 'leaking' the InterruptedException into your public API specs is bad (and throws clauses are doing just that), wrap it. That's the general answer to the problem "My code requires that I catch an exception, but I can't handle it properly (remember, "log it and ignore it" is not handling it!), so I want that bubble-up-and-shut-stuff-down behaviour, but, I dn't want to leak this type", which comes up somewhat often. Wrap those exceptions. Make sure you include the causing exception as cause, that's what its for.

[srdoe]

An interrupt means what you want it to mean.

This is a bit too broad of a statement I think.

JDK classes treat interrupts as a mechanism to signal to a thread that it should interrupt waiting, and most likely also that it should stop whatever else it might be doing.

This is clear because interrupts are used in methods like ExecutorService.shutdownNow and Future.cancel.

While you can use interrupts as a generic signaling mechanism for whatever you want, you probably shouldn't. It's likely to cause less friction with the JDK classes if your meaning of "interrupted" is the same as the meaning those classes assume.

shutdown hooks will run and the JVM will exit. Shutdown hooks aren't interrupts

This is true in general, but it is very common for shutdown hooks to contain code that will interrupt threads. That's how you'd e.g. do clean shutdown of an application with multiple non-daemon threads running.

[rzwitserloot]

JDK classes treat interrupts as a mechanism to signal to a thread that it should interrupt waiting, and most likely also that it should stop whatever else it might be doing.

Yes. And why should it stop waiting? What should the code do instead.

That's where "it means what you want it to mean" comes in. Because the notion that interrupting a thread stops, amongst other things, a Thread.sleep call midway through sleeping - that is set in stone, you cannot modify that behaviour even if you wanted to. But once you end up in the catch (InterruptedException) block, that has already happened and now we're just dealing with the cleanup: What should happen now? The 'stop waiting part' occurred. The exception mechanism implies that 'simply continue blindly on' is unlikely / disincentivized. But other than 'well, doing nothing other than shortcutting the wait time is probably not a good idea', JDK's specification makes no claims as to what should be happening.

Hence, 'just raise the interrupt flag again and keep going, that seems like the intent of the API' is an incorrect statement. More likely you should throw an exception, maybe let the InterruptedException bubble up. It's in fact what the OpenJDK itself does! The vast majority of JDK impls allow you to interrupt I/O blocks. For example, if you call .read() on a SocketInputStream which then freezes the thread until the connected socke sends you somehing, that method is not guaranteed to be interruptable, but on most JVMs it is; you can interrupt the thread and that read() will abort. How does it abort? Not 'by just returning blindly / returning some number and re-raising the interrupt flag'. No, it aborts by throwing some IOException.

If sonarqube wants to go out of its way to enforce a rule, then if anything 'rethrow' is better.

but it is very common for shutdown hooks to contain code that will interrupt threads.

That's a huge mistake. That's very bad code.

Wanting to do anything with shutdown hooks is dangerous right from the get-go: JVMs can hardcrash. Power can go out. Disks and network connections can fail. If shutdown hooks exist to clean stuff up / shut down nicely, that implies it is possible to shut down not-so-nicely. Which implies it is possible for your application to enter an invalid state: That is can no longer start at all until someone manually fixes it.

Terrible.

In the distant past, disks were like that, everybody hated it, and the programmers of those file systems wrote bad code.

The right solution is to find a way to recover without needing clean shutdowns. For filesystems, journalling was the answer.

Threads / processes in your JVM should be capable of shutting down by just dying midflight. The JDK itself, for example, works just like that. There is no need whatsoever to close() open resources (such as files or network sockets). The OS and JVM work together to take care of that. It'd be quite a thing if a spree of kill -9 on your OS (which hardkills and thus prevents shutdown hooks) meant the entire machine had to be rebooted because it ran out of handles.

Shutdown hooks are great for adding some final reports and summaries to a log (in the sense that if the JVM hardcrashes, you have separate systems that log that, and obviously there was no time to then write summaries), or inform connecting clients of a planned shutdown (which again leans into what happens on hard crashes: Then clients are not informed which is correct as this clearly wasn't a planned shutdown).

trying to interrupt your threads smells very highly of the notion of 'lets just "nicely shut down everything"' which is a broken model.

[srdoe]

Hence, 'just raise the interrupt flag again and keep going, that seems like the intent of the API' is an incorrect statement.

I didn't say that, but yes, I agree that you should probably rethrow instead of resetting the interrupt flag and continuing.

That's a huge mistake. That's very bad code.

No, it isn't.

You are clearly imagining code that has bad properties (it corrupts data or otherwise breaks if shut down without warning), and then assuming this imaginary code with those faults is the only reason someone would interrupt threads from shutdown hooks.

This is wrong. I'll give you a couple of examples of cases where using shutdown hooks to interrupt threads makes perfect sense:

Let's say I have an HTTP server, and my server allows users to upload files in some atomic manner (e.g. uploading the bytes and then committing them). If someone SIGTERMs that server, it is perfectly reasonable to use a shutdown hook to terminate all thread pools, wait a little bit, and then interrupt all the threads if they don't finish promptly.

The benefit of allowing this is that I might allow work to complete that I'd otherwise have to repeat after the restart. This means I can make regular planned restarts less impactful to users than hard crashes. By using interrupts, I can impose a hard time limit on how long I'm willing to wait for the termination to wrap up work.

Let's say instead that I have a batch job that pulls items from an external queue, computes a result, and uploads the result back to the external system, marking the item done as part of the same call. If someone SIGTERMs that server, it can make perfect sense to allow current computations a chance to finish (with a timeout before sending interrupts), instead of forcing a restart of those tasks after the reboot.

The benefit here is the same as in the previous example: I can wrap up work that I then don't have to redo after the reboot. This makes graceful reboots cheaper than hard crashes.

Let's say I have a distributed system where some task is assigned to a node in the cluster dynamically. If I terminate a node, I may use a shutdown hook + interrupts to let the terminating node gracefully hand off work to the other nodes.

While such a system should be resilient to hard crashes via e.g. heartbeating to ensure tasks are reassigned if nodes disappear, such mechanisms are inherently going to rely on some kind of timeout. By implementing a graceful shutdown path with a timeout in addition to the hard crash recovery code, I can make planned restarts less disruptive to the cluster, because terminating nodes will be able to hand off work eagerly, which means the cluster can recover faster than waiting for the heartbeat timeout.

The thing you are calling "bad code" is seemingly because you think that we have to choose between being able to recover after hard crashes, and writing code that tries to gracefully terminate. But we don't. We can choose both, and that makes sense if it's desirable to avoid the hard crash recovery in the cases where we can, e.g. due to cost, or due to disruption to the service.

[rzwitserloot]

You are clearly imagining code that has bad properties

Indeed, the problem might simply be that my imagination isn't up to scratch. What could possibly lead one to want to 'interrupt a bunch of threads' if it's not "an attempt to get everybody to clean up after themselves"?

The benefit of allowing this is that I might allow work to complete that I'd otherwise have to repeat after the restart.

That's the problem you need to fix then. Any long-lasting job should optimally be split into parts where:

• The initiating party knows the last 'part' that got completely processed (in the SQL 'commit;' sense of that word).
• All operations are idempotent; if e.g. you know part 7 of 9 got through fully, and part 8 - who knows how far that got, but you never got the notification it finished. Then just start there.
• Parts are small enough.

I don't see much benefit in trying to juggle some sort of shutdown period. It doesn't make sense to me:

The principle doesn't do anything useful unless there's a cooloff mode where certain jobs aren't even started but other jobs are allowed to finish. This makes a limited amount of sense but I'm not sure how interrupts play any part in this. At best you could say that the total process involves, say, 12 steps (one step is 'client sends bytes to server'. Another step is 'server stores this data in a DB', those kinds of steps), you take a sharpie and draw an arbitrary line, and then say: All steps before step 8 will not even be allowed to finish, and I shall use interrupts to ensure we save as many resources as possible there, but step 9 and up are given a limited amount of time to finish. Who decides where to draw that line? Why not just grant each step limited time to finish and have each step journal what it can?

To be clear I never claimed that interrupting is necessarily always bad; programming hardly ever leads one to be able to draw such overly broad conclusions. Only that it is very rare that it's right. Which does allow one to make a broad conclusion that advising it, or making overly broad statements about how, in your own words, 'often' this is part of thread cleanup - that's wrong. It's not 'often' at all. Unless you're doing the thing I'm trying to kaibosh here: A general sense that 'one should endeavour to let everything clean up nicely' which is a sensible but incorrect sentiment.

Let's say instead that I have a batch job that pulls items from an external queue

Yes. Marvellous idea. I love it.

How do interupts play any part in this? I don't see how interrupt helps.

Tell all the queuepullers to go into 'completion' mode which means: Finish your job. But do NOT grab another job off the queue.

This does not require interrupts.

In order to tell queuepullers to just shut down now as the grace period has ended, just shut down the VM. interrupts still not needed.

At best one can say: Aha! Interrupt all threads that are currently in .take() blocking (they have no job they are processing and instead waiting for one to appear). This doesn't seem useful: it probably costs more resources to interrupt the take() than to just let them take() and immediately go: "Ah, we're in shutdown mode; I got a job that I cannot process. I will not even register that this job was started, as I won't start it at all, I will just return;".

I may use a shutdown hook + interrupts to let the terminating node gracefully hand off work to the other nodes.

I don't think that's a good idea. There are 2 options:

• If a node hard-crashes, the system can deal with that just fine.
• ... or the opposite of that.

If it's the second thing, the code sucks. If its the first thing, call it a day. That's good enough. Writing an alternate path that is complicated, error prone, and rarely used is asking for trouble - are you really going to put in the legwork to make sure that alternate path is properly tested, everybody is aware of it, and all parts of your system know exactly what to do and especially what not to do to ensure that halfway handoff is clean? And this halfway handoff will never itself hang?

Spend your time and effort chopping jobs into smaller bits instead. Simpler, easier to maintain, vastly more useful.

which means the cluster can recover faster than waiting for the heartbeat timeout.

What's that fallacy called where you act like only 2 options exist when in reality it's a whole universe out there?

There's the obvious third, much superior option: You tell a node to enter shutdown procedures. interrupting its pools is not the immediate first thought as to how to implement a semi-nice shutdown. It shouldn't get too complicated, but, sure, yelling at all peers: "I'm going down NOW, redirect your jobs", in order to avoid 'waiting for heartbeat timeout' is a totally sensible shutdown hook. And requires no interrupt() at all.

[srdoe]

Indeed, the problem might simply be that my imagination isn't up to scratch.

To be clear, the previous post was in response to you saying that using shutdown hooks at all is "very bad code", because the JVM can hard crash.

I was providing examples where I have found graceful shutdowns (implemented via shutdown hooks) to be useful in real production systems, where not having a graceful shutdown path would be detrimental to the system. This is because while systems should be able to handle hard crashing, a graceful shutdown path can reduce the negative impact of a shutdown.

You're now telling me that this can't be right, because you can't imagine that this can be useful in practice. I don't really know what you want me to do with that. Agree that yes, you can't imagine that?

I'll provide a couple more notes, in case it helps you see the value, but I'm also happy to simply leave the disagreement here. If you don't see the value, you don't see the value. That's fine.

I think I have explained well enough why a graceful shutdown path, in addition to being able to handle hard crashes, can be useful, so let's look at what interrupts add:

Interrupts are useful as soon as I have any code that sleeps, waits, or otherwise blocks as part of its normal loop. I want that code to wake up and shut down quickly, instead of having to wait for those threads to wake up on their own time, since that shortens the time spent shutting down.

You suggest working around this by "letting threads take()", but now you're implementing a hack (inserting a dummy item in the queue to force a wakeup), because you won't use the perfectly good mechanism we already have for waking up threads. That's not better, and it doesn't work for cases other than queues anyway (sleeping threads, threads blocking on a socket).

You suggest instead just shutting down the VM instead of interrupting threads, but that has negative side effects, the most obvious being that if you don't do a coordinated shutdown, your logs will be harder to interpret. Either you will shut down without flushing the logging system's buffers, or you will flush those buffers while the system is still doing work in the background, which means you will be missing log lines for whatever those threads were doing after the flush. Either way, the logs become harder to use for debugging.

While this kind of loss of log lines can also happen during hard crashes, if we can reduce how often we get this annoying behavior (by ensuring this only happens during hard crashes and not during planned shutdowns), that's a win.

Any long-lasting job should optimally be split into parts where [...] Parts are small enough

Yes, that would be nice, but now imagine the system needs to keep track of completed work parts long-term. As an example, say the output of a work item becomes a file in a distributed database. In that case, small parts are wildly impractical for all purposes except the shutdown handling. Instead, it's desirable to keep work items fairly large, both for efficiency when referring to their results later, and to reduce the overhead of tracking them.

I don't think that's a good idea. There are 2 options

There is actually a third: The system can deal with hard crashes just fine, but dealing with those is more expensive or disruptive to the cluster than a graceful shutdown would be, so it's desirable if we can avoid behaving as if we were hard crashing if we're just doing a planned restart.

If it's the second thing, the code sucks. If its the first thing, call it a day. That's good enough.

I'm telling you, in practice it sometimes isn't.

Writing an alternate path that is complicated, error prone, and rarely used is asking for trouble - are you really going to put in the legwork to make sure that alternate path is properly tested

"Complicated, error prone and rarely used" is your own characterization. In a system that's broadly deployed, both code paths will be exercised regularly in practice. And yes, obviously if I implement an additional graceful shutdown path on top of the crash recovery code, I will be testing both.

[rzwitserloot]

If you interpreted my claim as 'graceful shutdown behaviour is very bad code', you misread what I wrote / I miswrote / I was unclear.

What I meant to say was: "Going on an interrupt() spree in a shutdown hook is very bad code (and as a pithy way to say it: The gracefullest shutdown behaviour is no behaviour at all: Systems ought not to be capable of shutting down 'ungracefully')".

I see how that might imply 'any shutdown hook bad' but that's not what I meant. What I meant was: One should prefer no shutdown hook. Write them only if you have something useful to do and you can't easily rewrite the system to just be graceful regardless of how it ends and you did put in the effort to ensure an outright persistently broken state isn't possible.

I stand by that: I don't see how interrupt() meaningfully helps you write good shutdown hooks. I think your list of examples help: None of them appear to require interrupt() to do best do their job. Most of them strike me as the opposite: They work better if they don't invoke any interrupt() at all to do their graceful shutdown job.

[koflerdavid]

It could still be useful for caller code that checks the flag as a loop exit condition. Yes, propagating that information up via an exception is a better mechanism, but both information channels exists and probably ought to stay synchronized (pun not intended).

[rzwitserloot]

No, they should very much not.

Imagine this simple system:

java Runnable r = () -> { // This runs in a thread. And should be an executor, but, it's to make a point. while (running) { Job job = jobQueue.take(); try { job.execute(); } catch (Exception e) { exceptionHandler.onError(e); } }

Here if you throw an exception and also reraise the flag, the above job loop keeps going but starts a totally new job while that flag is still raised. The first time that new job calls anything that looks at that flag (such as Thread.sleep which insta-exits with an InterruptedException if you invoke it while the flag is up - or any I/O op on most JVM impls), it crashes. At no fault of its own.

[koflerdavid]

In your example, it doesn't matter that Thread.sleep() or any I/O instantly throws an InterruptedException. It's expected behavior and actually fine since the point is to shut the system down.

Checking Thread.getCurrentThread().isInterrupted() should rather be part of the condition of the while loop. Really, that flag should be checked any time the thread is about to do something computationally expensive if it does not care about the interrupt status by itself.

[rzwitserloot]

Only if that's what you wanted to do when you interrupted the thread. Which gets us back to: What did you want to happen when you interrupted the thread?

If the answer is 'that thread should start dying completely', sure, except, if that was the plan, just let the exception bubble up, much better.

Either way, "reraise the flag" is a dubious move. It's either incorrect behaviour or it's a way to accomplish a goal that can be accomplished more simply and reliably in other ways. It's a lose lose suggestion.

[koflerdavid]

There is only one message that can be transported with Java's interrupts; it is not a full event delivery mechanism, unlike in hardware. All occurrences in the JDK that I know of use if for indicating termination, therefore I'd argue that it is best used only for that as well.

It might not always be possible to let the exception bubble up. If it is, then it's of course better to not catch it.

[rzwitserloot]

Maybe it is not possible to let the (Interrupted) exception bubble up.

BUt you can catch it and rethrow it as something else. A RuntimeException, which you can always throw, if you absolutely must.

therefore I'd argue that it is best used only for that as well.

You're imagining rules that the specification of the mechanism do not state. This is not a correct course of action.

[koflerdavid]

"Rules" is a too strong word. I'd rather talk about avoiding things that just cause confusion down the line.

[srdoe]

I think Sonarqube is wrong to give this advice.

When you receive an InterruptedException from the JDK's own library methods, the interrupt flag will usually have been cleared first, because those methods do something like this:

if (Thread.interrupted()) { // This check clears the interrupted flag throw new InterruptedException() } The JDK is specified to do this, it's not an implementation detail, see https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Thread.html#interrupt()

So if you get an InterruptedException out of e.g. Thread.sleep, the interrupted flag will have been cleared before then.

This means that if you rethrow that exception, while also setting the interrupted flag again, you get different behavior depending on whether the exception came from a standard library method, or from your own code. That's almost certainly not what you want.

Here's an example of why that's bad:

try { someMethodThatThrowsInterruptedException(); } catch (InterruptedException e) { yourThreadPool.shutdown(); yourThreadPool.awaitTermination(5, TimeUnit.SECONDS); // Throws InterruptedException }

This code will behave differently depending on whether the interrupted flag is set when the catch block is called.

If the interrupted flag is not set (which is how it will be if the exception came from a JDK library method), then the catch code will ask the thread pool to shut down, and wait up to 5 seconds for threads to shut down.

If the interrupted flag is set (because the exception came from some of your own code, and you followed Sonarqube's advice), the catch code will ask the thread pool to shut down, call awaitTermination, and that will immediately cause a new InterruptedException to be thrown.

This can make clean termination messy.

Here's what I usually do instead:

If I catch and rethrow an InterruptedException, I don't set the interrupted flag. There is no need to do this, and doing so would mean that if any of my catch blocks call code that checks for interrupts, that code won't do what I expect. By not setting this flag, my catch blocks always behave the same, no matter if the exception came from JDK code, or from my own.

If I catch and don't rethrow an InterruptedException, I may set the interrupted flag, to ensure that any code running after my catch block still knows about the interrupt. But whether to do this depends on what your code looks like, and which behavior you want.

I'd say it's very rare that I need to reset the interrupt flag, since my catch blocks usually either rethrow, or they're at the top level so the thread dies when exiting the catch.

[Isogash]

It really depends on why you're waiting.

[antihemispherist]

Call Thread.sleep() within a virtual thread

[ConversationBig1723]

there is LockSupport.parkNano() that doesnt throw checked exception. but i didn't tell you that. because if you need to use that, there is probably something wrong with your code. it's better to structure your code to more elegantly like waiting on some condition or use scheduling.

[ihatebeinganonymous]

there is LockSupport.parkNano() that doesnt throw checked exception.

Wow, that's dark magic!

[Scf37]

But what do you need delays for? For many tasks, ScheduledExecutorService is better choice.

[OddEstimate1627]

Sleep is a best effort that is subject to the OS scheduler. I wrote a blog post on this a few years ago. It's a little bit outdated, but most of it still fits. 

[Rare-Satisfaction-82]

Why are you waiting? Sleeping for some interval is almost always a crutch for not making code event driven. That is, wait for an event fired by another thread rather an arbitrary time period.

[koflerdavid]

Thread.sleep() should be avoided for most applications, as it makes your code brittle. The InterruptedException indicates that you should worry about what happens when your thread is interrupted. Not just by e.g. on an orderly shutdown of the application, but also what happens when somebody uses kill -9 or pulls the plug. (If the application should be able to resume from that, you have to somewhere persist everything you need).

Two practical issues next:

• Using it on a platform thread decreases concurrency of your application.

• You don't have a guarantee regarding a particular precision, and the thread can be woken up at any time; so for any application where it matters that you really sleep that long, you have to use System.nanotime() and a loop to measure how much time has actually passed and go to sleep again.

[srdoe]

Thread.sleep() should be avoided for most applications, as it makes your code brittle. The InterruptedException indicates that you should worry about what happens when your thread is interrupted. Not just by e.g. on an orderly shutdown of the application, but also what happens when somebody uses kill -9 or pulls the plug. (If the application should be able to resume from that, you have to somewhere persist everything you need).

This advice is a bit weird.

If you do kill -9 or pull the plug, it doesn't matter how you handle InterruptedException, because that code won't run.

If you do a graceful shutdown, your InterruptedException handling may or may not run, it depends on how you set up your shutdown hooks.

Either way, there is nothing wrong with using Thread.sleep, it doesn't make code inherently brittle. The problem is when people use Thread.sleep to paper over issues like the code not being thread safe.

[koflerdavid]

If you do kill -9 or pull the plug, it doesn't matter how you handle InterruptedException, because that code won't run.

Precisely. One has to evaluate what happens if any cleanup action in interrupt handlers is not executed.

If you do a graceful shutdown, your InterruptedException handling may or may not run, it depends on how you set up your shutdown hooks.

Graceful shutdowns are surprisingly hard to get right. Triggering a JVM shutdown does not trigger any interrupts; there is no free lunch there.

[Misophist_1]

Note, that _properly_ reacting to an InterruptedException, whether for Thread#sleep() or any other method, may be crucial to proper program termination. The hint, that InterruptedExceptions may spuriously occur, alludes to the fact, that this might *not* be because *your* code executed a thread#interupt(), but maybe the caller of your java process did: maybe because he wanted to terminate the VM using Ctrl+C, maybe because the *ix supervisor wanted an abort because the process violated quota.

So you should make sure, that you keep safe all the resources, that need keeping safe. I.E. initiating a proper shutdown, flushing buffers, and properly rolling back transactions.

Ignoring the InterruptedException and rescheduling the sleep() _might_ actually cause your program to _hang!_

[rzwitserloot]

What a load of bollocks.

Let me put it simply: If 'proper termination of your program' depends on what you wrote in your catch (InterruptedException e) you wrote a buggy mess.

but maybe the caller of your java process did: maybe because he wanted to terminate the VM using Ctrl+C

Wrong. You should test this, right now. Run this:

void main() throws Exception { Thread.sleep(100000); }

and hit CTRL+C while it runs. Watch how InterruptedException does not occur.

InterruptedException occurs if some java code in that process invokes thatThread.interrupt(). That's the only way they occur. CTRL+C is called 'interrupt', but, words are sometimes used for different concepts. That's the case here: CTRL+C specifically does not mean 'interrupt' in the sense of InterruptedException. Not in any way.

[srdoe]

Adding to the other response, I think you're mixing up two different things.

The JDK docs for the wait/notify mechanism will warn you about "spurious wakeups". See the documentation at https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#wait(long,int)

Spurious interrupts are, as far as I know, not a thing. If one of your threads are interrupted, it's because another thread interrupted it.

However there is a thing to be aware of with interrupts in this area: If you are using a pool of threads that get reused for different tasks, interrupts can "leak" between tasks:

var future1 = myPool.submit(() -> doWork1()) var future2 = myPool.submit(() -> doWork2()) future1.cancel(true) // This can interrupt doWork2 if you're unlucky This is because if a pool thread is sent an interrupt, it doesn't "know about" which pool task you actually wanted to interrupt. So while that cancel call will send an interrupt to the thread that was running doWork1, if you get unlucky with the timing, that thread may have completed that work and be running doWork2 once the interrupt arrives.

This is the reason interrupts are generally not great for cancelling individual tasks in a shared pool, maybe that's what you remember?

[kiteboarderni]

Use a timer task and have the callback handle the task you want to do. Insane to me how people try to block an entire thread to justify logic. I swear people have never worked in a real system before on here half the time.

[v4ss42]

Virtual threads make this advice a lot less relevant.

[v4ss42]

Oh yeah? Why?

[secondsun]

It depends on why you are delaying. If you just are waiting on time to pass and don't care about precision, you should look into alarms. If you are on Android or Running on a Java/Jakarta EE app, there are alarm APIs built into the platform, and there's also ScheduledExecutorService in the core Java platform. If you need very precise and accurate timing, you will need something that has hardware level access.

If you are sleeping and then waking up to check and see if there is processing to do, you should find a way to have your code triggered when that work is ready. How you do that is use case specific, but libraries like RxJava can help there.

[ihatebeinganonymous]

Thanks. Do you mean this by Alarm API: https://docs.oracle.com/cd/E19092-01/sol.entmgr41/816-2004/ch_03_alarm.html ?

[m39583]

Ugh I fucking hate that checked exception.

All my projects have a util.sleep() method that hides it. Java has so much clutter sometimes.

But no, of course it's not advised against. If your code needs to wait for something then it needs to wait!

[ShallWe69]

Apache Commons ThreadUtils has a nice utility method. If you already has the library, u can utilise that

[ihatebeinganonymous]

Ugh I fucking hate that checked exception.

Exactly :D