Update current time date without exploding in memory

Question

I have written the following Java code:

Calendar now = Calendar.getInstance();
now.setTime(new Date());
Date currentDate = null;

while (now.compareTo(stop) < 0 ) {  
    currentDate = new Date();
    now.setTime(currentDate);
}

that is meant to track down the time passing while other components (in particular: a Twitter Streaming listener) perform other actions. So, this is not meant to be a simple sleep, since other components are running in the meanwhile: this loop is just meant to keep the machine occupied for a while, until the date indicated by stop arrives.

However, by doing this the memory size keeps increasing a lot. I profiled the thing and I saw that this generates a huge amount of Date objects in memory.

Is there a smarter way of doing this?

Thank you in advance.

Why don't you use a thread and semaphores? `while` loops cause the app to be detected as *non-responsive* when the time is longer than 3-5 seconds, and it looks bad for the user. — arielnmz, Jul 11 '14 at 13:12
I have never use them. Any pointer to a specific example would be appreciated. — Eleanore, Jul 11 '14 at 13:14
Here's a good start: [Concurrency](http://docs.oracle.com/javase/tutorial/essential/concurrency/). But if you're too lazy: [A simple example](http://www.cs.nccu.edu.tw/~linw/javadoc/tutorial/java/threads/simple.html) — arielnmz, Jul 11 '14 at 13:16
Nope, not lazy. Any new learned thing is a good start for improving :) — Eleanore, Jul 11 '14 at 13:20
possible duplicate of [Sleep and check until condition is true](http://stackoverflow.com/questions/14464544/sleep-and-check-until-condition-is-true) and [this](http://stackoverflow.com/q/319485/642706). — Basil Bourque, Jul 11 '14 at 16:03

T.J. Crowder · Accepted Answer · 2014-07-11T14:10:51.267

The minimum change is to use setTimeInMillis using System.currentTimeMillis rather than setTime:

while (now.compareTo(stop) < 0 ) {                  // Ugh, busy wait, see below
    now.setTimeInMillis(System.currentTimeMillis());
}

...or actually, just use milliseconds in the first place:

long stopAt = stop.getTimeMillis();
while (System.currentTimeMillis() < stopAt) {       // Ugh, busy wait, see below
}

However, surely with broader context there's a way to avoid busy-waiting at all. Busy-waits are almost never appropriate.

So, this is not meant to be a simple sleep, since other components are running in the meanwhile: this loop is just meant to keep the machine occupied for a while, until the date indicated by stop arrives.

Presumably those components are running on other threads, as your while loop is a busy-wait.

That being the case, this thread should sleep — either for a period of time, or until it's woken up by something else.

For instance, you haven't said what stop is, but as you're using it with compareTo presumably it's a Calendar. So it should be possible to get the difference (in milliseconds, via getTimeInMillis) between stop and now, and sleep rather than busy-waiting:

Calendar now = Calendar.getInstance(); // Initializes to "now", no need to do that yourself
long delay = stop.getTimeInMillis() - now.getTimeInMillis();
if (delay > 0) {
    Thread.sleep(delay);
}

It'd be better if you provided an example to avoid using busy-waiting. — arielnmz, Jul 11 '14 at 13:13
@arielnmz: Just did. Had to remind myself of `Calendar`'s awful API. :-) — T.J. Crowder, Jul 11 '14 at 13:16

Update current time date without exploding in memory

1 Answers1