Threads, Runnable, and the Executor Framework

Modern machines have many CPU cores, and modern programs must do many things at once, serve concurrent requests, perform background work, parallelise computation. Concurrency is how a Java program runs multiple sequences of instructions seemingly or actually simultaneously, and a thread is the fundamental unit: an independent path of execution within a process, with its own call stack but sharing the process's heap memory with other threads.

You can create threads directly by implementing Runnable or extending Thread, but managing raw threads, creating, starting, and reusing them, is error-prone and wasteful. The Executor framework solves this by separating what work to run from how it is run: you submit tasks to an executor backed by a managed thread pool, and it schedules them onto a reusable set of threads, returning a Future for any result.

Understanding threads and executors matters because almost every real Java application is concurrent, and getting concurrency right is both essential and notoriously hard. Grasping what a thread is, why sharing mutable state across threads is dangerous, and why the Executor framework's pooled, task-based model is preferred over hand-managed threads is the foundation for everything else in this module.

Analogy🏏Cricket

🏏 Think of it like cricket: a team sheet does not just list players, it assigns each to a precise, declared role, opener, spinner, wicketkeeper, and the laws and the captain enforce that a player operates within their declared role: you cannot send a designated bowler to keep wicket without an official change. Just as each player's role is fixed and checked before play, each Java variable's type is fixed at compile time and checked by the compiler. Just as trying to use a player outside their role is caught by the officials before it disrupts the match, using a variable in a type-incompatible way is caught by the compiler before the program runs. Just as clear role assignments prevent on-field confusion, clear type declarations prevent runtime errors. The insight is that declaring and enforcing roles up front, for players or for data, catches mistakes early rather than mid-match.