start() versus run() — the mistake everyone makes once
Call run() directly and your "thread" is just an ordinary method call on the main thread. Nothing runs in parallel, nothing looks wrong, and the output is quietly sequential. This session begins there, then maps every state a thread can be in.
This session has not been authored yet
You have reached a real page, but an empty one. The deck for Class 22 is planned in full in the course knowledge document and is queued for authoring — nothing on this page is finished teaching content.
The roster underneath is the actual plan for this session, so you can see exactly what will land here.
What this class will cover
- Class-22 openerThe hook: why calling
run()yourself silently defeats the whole point. - start() vs run(), provenThe same program both ways, with output that shows the difference beyond argument.
- The thread lifecycleNEW, RUNNABLE, RUNNING, BLOCKED/WAITING, TERMINATED — the full state diagram.
- sleep()Pausing a thread without giving up what it holds — and the checked exception it forces on you.
- join()Making one thread wait for another to finish, and why order suddenly becomes predictable again.
- Thread priorityA hint to the scheduler, never a guarantee — with a demonstration of it being ignored.
- InterruptionAsking a thread to stop politely, and why there is no safe way to force it.
- Activities + close cardLifecycle tracing and control drills, then the runway into race conditions.
The trap this class defuses
Priority is the most over-trusted idea in the whole unit. Students set a thread to maximum priority, watch it still finish last, and conclude Java is broken. It is not — the scheduler was never obliged to listen.