ReentrantLock Condition how does signallAll() work?

I am trying to understand How does signalAll() not break the critical section for example

//Some Class Here is Trying to use an resource which is to to initialized in an seperate thread
ReentrantLock lock=new ReentrantLock();
Condition wait=lock.newCondition();
Resource res=new Resource(lock); //An Important Resource Which Should Be Accessed Only By One Thread At A Time
void doStuff()
{
lock.lock();
try
{
if(!res.initialized.get()) //Check If Resource Was Previously Not Initialized
{
res.init();//Spawns An Seperate Thread For Initialization
wait.await();//If Resource Is Not Initialized Make Whatever Thread Which Reached This Point Wait
} 
res.use(); //Here Is What I Don't Understand If Let's Say 5 threads were parked in the previous statement then when signalAll() is called won't all 5 threads wake up simultaneously and resume execution at this point and use this resource at the same time and break this resource? But it dosen't turn out like that why?
}
}
finally{lock.unlock();}
}    
private static final class Resource extends Thread
{
private final ReentrantLock lock;
private final Condition init;
private final AtomicBoolean 
started=new AtomicBoolean(false), 
initialized=new AtomicBoolean(false);
private Resource(ReentrantLock lock)
{
this.lock=lock;
this.init=lock.newCondition();
}
private void init()
{
if(!initialized.get())
{
if(!started.get())
{
start();
started.set(true);
}
while(!initialized.get()){init.awaitUninterruptibly();}//In case of spurrous wakeups check repeatedlly
}
}
private void use(){}//Important Stuff  
private int get(){return 5;}
@Override
public void run()
{
lock.lock();
try
{
TimeUnit.SECONDS.sleep(5);
initialized.set(true);
init.signalAll(); //This should in the above example wake up all 5 threads simultaneously and break the critical section but that does not happen how?
}
catch(InterruptedException ex){}
finally{lock.unlock();}
}
}

With just signal() only one thread wakes up and resumes execution at the critical section so nothing breaks but with signalAll() multiple threads resumes execution at the point it was parked[i.e inside the critical section] so how does nothing break? and when/where should we use each i.e best practises

The short answer:

await() does not only suspend the current thread, it also releases the lock. signalAll() wakes up all suspended threads but each thread has to re-acquire the lock before the await() call can return. With it, even after calling notifyAll() the critical section can only be entered by a thread after the thread that acquired the lock before relinquishes the lock.

The long answer:

For better understanding - let's pretend that neither await(), singal() nor signalAll() would exist in Java. How would you wait for the asynchronous initialization of your resource? Your code would probably look something like this:

void doStuff(Resource resource) throws InterruptedException {
lock.lock();
try {
while (!resource.isInitialized()) {
resource.startAsyncInit();
lock.unlock();
Thread.sleep(100);
lock.lock();
}
doSomethingWith(resource);
} finally {
lock.unlock();
}
}

But this would have the following drawback:

Each thread that waits for initialization is suspended and woken up again and again.
Each single thread acquires the lock and releases the lock again and again.
The more frequent you do this and the more threads are waiting the more expensive
does it get. This busy waiting consumes CPU. Without an explicit sleep the code would easily
lead to 100% CPU usage.

await() allows you to replace the busy waiting with a signal-based mechanism.
All waiting threads are suspended and do not consume any CPU while they are waiting.
Only sporadically occuring spurious wake-ups (at least on some systems) may consume some CPU.

When to use singal(), signallAll() in general:

Waking up a thread and suspending a thread is not for free and gets more expensive with
the number of threads. If you have a resource that has to be initialized
before it can be used concurrently by all threads it makes sense to wake up all threads at once by calling signalAll().

But think of a consumer/producer pattern with multiple consumer threads and multiple producer threads where a single producer thread provides only one work item that is processed by one consumer thread. In this case it would make much more sense that a producer thread wakes up only one consumer thread instead of all. Otherwise all awakened threads would first compete for the single work item, one would win and all others would have to be sent back to sleep again. This would have to be repeated every time when a single work item is produced. When a lot of work items are produced in short time
you would finally loose all the advantage of the singalling. The majority of threads would be suspended and woken up again and again, they would compete for one single item again and again and you would finally end up with nearly the same overhead as the example above with busy waiting but without an explicit sleep

signal() vs signalAll() in your example:

When the first thread gets the hold of the lock it calls the init() method, starts the thread for initialization and then releases the lock when it calls awaitUninterruptibly(). The initialization thread in the meanwhile tries to acquire the lock but it will not get it until awaitUninterruptibly() is called.

Locks are by default unfair. This means that it is not guaranteed that the longest-waiting thread will get the lock first. When awaitUninterruptibly() is actually called and the lock is released other theads may have already tried to acquire the lock in the meanwhile by calling the lock() method. Even when your initialization thread tried to acquire the lock first, it is not guaranteed that it will get the lock before any other thread. Every other thread that will get the lock before your initialization thread will be able to call the await() method. If you then only call singal() in your initialization thread all threads that were able to get to the await() call would never be woken up and sleep forever. To avoid this, it is essential to use singalAll() in your example. Another possibility would be to use a "fair" lock (see the JavaDoc of the ReentrantLock). With a "fair" lock it shouldn't make any difference whether you call singal() or signalAll(). But since "fair" locks have quite an overhead I would suggest to keep the unfair lock and use singalAll().

Whether you run into a situation where some threads sleep forever depends on the right timing. So you propably may run this code on one host hundreds of times without any problem but run into this situation frequently on other hosts. Even worse, in environments with spurious wake-ups you would run into this only from time to time