This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
Mathew Mintalm wrote:I made code in quite biiig class, and few people said that:
"Using thread.sleep is really bad idea"
You may be taking the critic out of context. Perhaps they were saying that the technique (of sleeping) you are using is a bad idea -- not the actual implementation. If this is the case, all you are doing is doing the same thing, just differently -- which from this topic, you can conclude is also a bad idea.
If you tell us exactly what code the critic is about, maybe we can tell you why (and whether the critic is even valid).
One unconventional way to achieve the same......see the sample code
But again..it will be processor dependent and not as reliable as Thread.sleep. But since you asked for a different way to do this, I remembered my degree class for Algorithm. this is the way we used to determine the time taken by a sample code.
This is just a basic idea ; you can change the parameter value as per your wish.
A JVM might optimize that loop right out of existence: you can never rely on simple looping to provide a consistent delay.
in that case you can put some one liner statement(meaningless) in the for loop like int p = p + 1.
And you are right about relying on this method to provide a delay but this is just another way to create some delay in program and yes which is not reliable.
Using Sleep will not release allocated resources for that thread... can be condition for deadlock hence it is a bad idea
Joined: Apr 04, 2010
But forcing the thread to do something else in a loop for 10 seconds will also not release any locks, so is just as likely to cause deadlock, plus it is consuming processor resource as well and the actual time it takes cannot be guaranteed...
In this case it's not sleep that is "causing" deadlock by not releasing the resources, it's poor design.
The problem of deadlock and not releasing resources would be caused just the same by using a function designed to take 10 seconds to elapse.
Consider this pseudocode
This will do the work, then wait 10 seconds without releasing the lock.
If your alternative is a function which uses up processor resources then it is subject to exactly the same design considerations
will have exactly the same problem. It will do the work, then it will hold onto the resource, potentially causing locking issues, until the 10 seconds are up.
But if you just design it right
then it does the work, releases the lock, then sleeps 10 seconds.
In terms of locking resources and deadlock, I see no difference between the Thread.sleep() option and the methodThatDoesNothingButTakesTenSeconds() option.
In terms of performance, the methodThatDoesNothingButTakesTenSeconds() has the following drawbacks which various people have highlighted : may be optimised out by JVM; will use processor resources which could be used on real work; may run for more or less than 10 seconds depending on the processor time allocated to it.