Which one of the following statements about when setDaemon() may be called is true?
Answer: A
The javadoc states the method must be invoked before the thread is started, and that it throws IllegalThreadStateException if the thread is alive. Daemon status is therefore fixed for the whole life of a running thread and cannot be switched on later.
Please log in or register to report this question.
Consider how a new thread acquires its daemon status. Which statement is correct?
Answer: B
Daemon status is inherited: a new Thread is a daemon exactly when the creating thread is one, just as its initial priority is copied from the creator. Because the main thread is not a daemon, threads created from main default to non-daemon, which is why the explicit-call answer looks right.
Please log in or register to report this question.
When the JVM exits - which of the following is true?
Answer: C
Execution continues until all non-daemon threads have died, or Runtime.exit is called; the JVM exits when the only threads running are daemons. So main returning does not end the program if a non-daemon thread is still alive, and a daemon can be killed mid-work at shutdown.
Please log in or register to report this question.
Which of these statements about what happens to a daemon thread at shutdown is correct?
Answer: D
Because the JVM exits as soon as only daemons remain, a daemon can stop anywhere, including part-way through updating shared state or writing a file. No grace period is promised and holding a lock does not help. Work that must complete belongs on a non-daemon thread.
Please log in or register to report this question.
Which one of the following statements about which thread join() blocks is true?
Answer: A
join() waits for the thread it is invoked on to die, blocking the caller until then. The direction is the common confusion: t.join() suspends the current thread, not t. It is implemented as a loop of wait calls guarded by isAlive, with notifyAll issued as the thread terminates.
Please log in or register to report this question.
Consider how long join(0) waits. Which statement is correct?
Answer: B
The javadoc defines join() as behaving exactly like join(0), and states that a timeout of 0 means to wait forever. Treating zero as no wait is the natural reading and the wrong one, which is what makes it worth asking.
Please log in or register to report this question.
The Thread.State enum - which of the following is true?
Answer: C
Those six are the whole enum. There is deliberately no RUNNING state: a thread that is executing and one merely eligible to execute are both RUNNABLE, because the JVM does not distinguish them. A sleeping thread reports TIMED_WAITING, and getState is documented for monitoring rather than for control.
Please log in or register to report this question.
Which of these statements about BLOCKED compared with WAITING is correct?
Answer: D
BLOCKED means waiting for a monitor lock in order to enter or re-enter a synchronized region. WAITING means the thread called something like wait() or join() with no timeout and is waiting for another thread to act. The distinction is what makes a thread dump readable.
Please log in or register to report this question.
Which one of the following statements about an exception thrown out of run() is true?
Answer: A
A thread dies either by returning from run() or by throwing an exception that propagates beyond it, and that death is local to the thread. It cannot be caught by whoever called start(), because that call returned long before. The uncaught exception handler reports it, so it is not silent.
Please log in or register to report this question.
Consider how an uncaught exception in a thread is handled. Which statement is correct?
Answer: B
Handling is controlled first by the thread, via setUncaughtExceptionHandler, then by its ThreadGroup's uncaughtException method, and finally by the default handler. The chain is why a per-thread handler overrides a default one that is already installed.
Please log in or register to report this question.
