Multithreading in Java

23.1 Preliminaries — Process, Context Switching and Multitasking

23.1.1 What a Process Is

A process — an instance of a program in execution — owns its own memory area and its own data. The lecture uses three everyday examples labeled P1, P2, and P3: P1 is the music player, P2 is the web browser, and P3 is an open file such as a Word document or a spreadsheet. Each of these three counts as a distinct process because P1 has memory that belongs to the music player, P2 has memory for the browser, and P3 has memory for the file. From the user view they work together, but the machine maintains strict separation.

In a single-processor illustration, imagine one CPU for the whole machine. At any moment only one process holds that CPU. At time slice 1 the music player holds the CPU, at time slice 2 the browser holds it, at time slice 3 the file process holds it. The operating system moves the CPU very fast among P1, P2, and P3. The speed is so high that the human eye cannot notice the switching in the background. The system creates the illusion that all three run together by sharing the CPU quickly. The lecture calls that fast sharing the beauty of the operating system.

The idea is operating-system related even though we learn it through Java. You need this background before threads make sense, because threads will add one more level inside a process.

Visual to keep in mind: draw a horizontal timeline. Mark three lanes for P1, P2, P3. Shade a short block in P1, then a short block in P2, then a short block in P3, repeating. The x-axis is time in milliseconds, the y-axis lists the processes. The shaded blocks never overlap on the single-CPU diagram. The takeaway is that at any vertical line only one block is active, but across a full second each lane gets many blocks, so the user feels continuous play, browsing, and editing.

Real-world anchor: every icon you double-click — music player, browser, Word, Excel — becomes a process with its own address space. When the system runs out of memory for a new process, creation can fail. That is why later examples wrap thread or process creation in try and catch — resources are finite and governed by operating system policy.

23.1.2 Context Switching Between Processes

Context switching — shifting the control of the processor from one process to another — is the second preliminary. With the same three processes P1, P2, and P3, the system gives the CPU from P1 to P2, later from P2 to P3, and later back to P1. Taking the CPU away from the currently running process and giving a chance to another process to run is exactly what context switching means. The lecture describes it as shifting processor control between processes.

Think of context switching like changing desks in an office where each person has a separate locked office with private files. To switch, you must lock your office, carry your papers out, unlock the next office, and lay out new papers. The move is safe but slow. This analogy breaks for threads, where people share one open-plan room — a picture we will extend in the next concept.

23.1.3 Multitasking and the Illusion of Parallelism

Multitasking — performing more than one task at the same time — names what the user perceives. In the lecture the term labels the situation where different processes at different memory addresses appear to run together on a single processor.

Common pitfall to avoid now: do not equate multitasking with simultaneous use of the CPU on a single core. The CPU still serves one process at a time. The illusion comes from time slicing, not from duplication of the processor.

23.1.4 Why These Preliminaries Matter for Threads

These three ideas — process, context switching, multitasking — are presented as required background before directly learning about threads. They are largely operating system concepts, yet they prevent confusion when multithreading is introduced. The hierarchy will soon go one level deeper: from sharing a CPU among processes to sharing a CPU among parts of a single process.

23.2 Thread and Multithreading Fundamentals

23.2.1 Definition of a Thread

A thread — a programmed unit that is executed independently of other parts of the program — is the central definition. The definition is given verbatim in the lecture and then expanded with a diagram. Thread defined as independent programmed unit part of process captures the same idea: a thread is a programmed unit that is independent and is part of a process. A thread is not a separate program; it is a part inside one process that can be scheduled on its own.

Plain meaning on first use: a thread here means a lightweight flow of instructions, like a lane on a single road, all lanes sharing the same road surface.

23.2.2 Multithreading as One Level Down in the Hierarchy

Take a single process P1 and divide it into multiple parts. Those parts are labeled thread number one, thread number two, thread number three, thread number four. Earlier the diagram showed different processes P1, P2, P3 sharing one processor with context switching between processes. Now the same single processor is shared between multiple parts of a single process. That is the core image of multithreading.

The same illustration is repeated for another process P2. Threads of P2 also look to get the single CPU when P2 is given a turn. The idea transfers to any process that is partitioned.

Visual: draw the same single-CPU timeline as before but now zoom into the P1 block. Inside that block draw a finer striped pattern of T1, T2, T3, T4 alternating. The x-axis is still time, but now you see nesting: coarse switching between P1, P2, P3, and fine switching between T1 and T2 inside the P1 window. The takeaway is that thread switching happens within the process window and is much finer grained.

23.2.3 Shared Address Space and Data Structures

If a program creates multiple threads, all those threads execute in the same address space and use the same data structures. Why? Because they belong to one process that has been divided, so the data and the structures remain common. This shared address space is the key distinction from processes. Threads of P1 work on the memory that belongs to P1, threads of P2 work on memory of P2, and so on.

Analogy: processes are separate houses with private gardens — safe but each move between houses needs a full relocation. Threads are roommates in one house sharing the kitchen and living room — moving from one roommate's task to another is quick because the house stays the same, but roommates can spoil shared food if they do not coordinate. The analogy breaks when hardware adds multiple cores, where true parallel execution inside one house becomes possible.

23.2.4 Intuitive Program Partitioning Example

A concrete program helps: suppose a program needs input, then it processes that input, then it prints the result on the screen or into a file. The overall input handling can be one thread, the data processing can be another thread, and the printing can be another thread. This is how a process is logically divided into threads. Each thread can be given a turn on the CPU one by one so the process executes in parts. The example makes the abstract splitting tangible: input, processing, output as three threads of the same process.

23.3 Process versus Thread — A Direct Comparison

23.3.1 Memory Sharing

For processes, there is no sharing of memory. P1 belonging to the music player, P2 to the browser, and P3 to a Word file or Excel sheet each have a different address space. No memory is shared between processes. For threads, if T1 and T2 are threads of P1, they must work on the same memory because they belong to the same process. Sharing of memory exists for threads, no sharing exists for processes. That contrast is repeated for emphasis.

This single rule explains the other two comparison points.

23.3.2 Risk of Data Structure Corruption

Processes cannot easily corrupt each other's data structures because each has its own memory address and its own structures. Chances of corruption are negligible when there is no sharing. Threads are different. T1 and T2 of P1 work on common memory, so the chance of corrupting that memory and its structures is high if synchronization is missing. A typical hazard is described: one thread starts a change and has not yet finished, while another thread starts work on the same memory address and destroys the data. The risk is present for threads and requires careful synchronization. The warning is explicit: be very careful when using multithreading.

A second concrete hazard from later in the lecture uses the bracket printer: two threads interleave print("[msg") and sleep and print("]") on the same shared printer buffer, producing garbled brackets. The root cause is the same: shared memory plus unsynchronized timing.

23.3.3 Cost of Context Switching

Context switching between processes is expensive because the CPU is taken entirely from one process and given entirely to another. The operating system must maintain process data structures and underlying fields, which costs time. Context switching between threads is cheaper and easier because threads share the same memory address and the same data structures within one process. The cheaper thread-level switching is a direct consequence of shared address space.

Visual: imagine two cost bars. The process-switch bar is tall, labeled with save registers + save page tables + flush cache. The thread-switch bar is short, labeled with save registers + stack pointer only. The x-axis is switch type, the y-axis is time cost. The takeaway is that for many rapid switches, thread-level switching keeps the CPU more productive.

23.3.4 Summary in Words

In short, processes have separate memory, negligible cross-corruption risk, and expensive switching; threads have shared memory, higher corruption risk if unsynchronized, and cheaper switching. The comparison is operating system related, but it is stressed as essential to avoid confusion about threads.

Comparison table for fast recall:

One-sentence chooser: use processes to isolate whole programs; use threads to cooperate quickly inside one program and protect shared parts with synchronization.

23.4 Thread Life Cycle and States

23.4.1 Overview of States

A thread moves through several states during its lifetime. The lecture names the states and describes how a thread switches between them based on program conditions and planning. The states discussed are New, Runnable, Running, Blocked or Waiting, Timed Waiting, and Terminated or Dead. This life cycle is used to explain how multiple threads can be coordinated even when one thread needs a long time.

23.4.2 New, Runnable and Running

A new thread is one that has been created but not yet started. Once the start method is invoked the thread becomes Runnable, meaning it is ready to run and waiting for CPU allocation. When the scheduler gives it the CPU it enters the Running state and executes its run method. The lecture focuses more on the waiting and terminated states because they are used to control execution order, but the New to Runnable to Running progression is implied in every example where start leads to run.

23.4.3 Blocked, Waiting and Timed Waiting — Sleep Example

If only T1 is given a chance, T2 and T3 remain inactive until T1 finishes. To avoid that stall, a planned waiting period is introduced. A detailed scenario is given: put T1 into sleep mode for 1000 milliseconds. That is a planned waiting. During those 1000 milliseconds when T1 sleeps, chance should be given to T2. After some time T2 should also go to sleep for 500 milliseconds, then chance goes to T3. With this planning, all threads get at least one chance without waiting for another thread to complete fully. This is called the timed waiting state that is planned in advance so the thread can be put to sleep for a decided amount of time.

The description distinguishes a general blocked state — the thread is running but waiting for some event or temporary condition — and the specific timed waiting where sleep duration is fixed. Examples later use sleep to demonstrate the state in code.

The same idea is repeated with different numbers: T1 sleep 1000 milliseconds, T2 sleep 500 milliseconds, and the interleaving consequence is explained. When T1 sleeps, T2 runs; when T2 sleeps, T3 or the next waiting thread runs. This planned sleep avoids keeping the CPU idle unwatched and lets other threads progress. The lecture notes that when a sleeping thread wakes, it does not automatically resume running — it becomes runnable and must be picked again by the scheduler.

Visual: draw a state diagram with nodes New, Runnable, Running, Blocked/Waiting, Timed Waiting, Terminated. Arrows: start from New to Runnable; scheduler pick from Runnable to Running; sleep or wait from Running to Timed Waiting or Blocked; timeout or notify from those back to Runnable; run return from Running to Terminated. The takeaway is that only Running uses the CPU, while the waiting states explicitly free it.

23.4.4 Terminated or Dead State and State Transitions

The last state is Terminated, also called Dead. As the name suggests, the thread is dead and no longer needed after it has done its functioning. It has moved to the dead state. The lecture presents the life cycle as a set of switches between these states driven by program conditions and whatever planning the developer has done. State transitions are not automatic alone; they respond to sleep calls, waiting for events, and completion of the run method.

23.5 Creating Threads in Java — Thread Class and Runnable Interface

23.5.1 Two Ways to Create a Thread

There are two ways to create threads in Java. The first way is by extending the Thread class. The second way is by implementing the Runnable interface. Both are predefined: Thread is a predefined class available with Java, Runnable is a predefined interface. Either path lets a program create a thread. How to do each is shown through examples later. This two-path framing is repeated for retention.

23.5.2 Thread Class — Constructors, Fields and Methods

The Thread class provides constructors and methods to create and perform operations on a thread. As a class it supplies constructors and methods designed for thread work.

Four constructors are listed:

1. No argument constructor — new Thread().
2. Single argument constructor where we receive the name of the thread as a String — new Thread("MyThread").
3. Single argument constructor where we receive an object of the Runnable interface which is initialized taking a reference of the class on which it is implemented — new Thread(runnableObj).
4. Two argument constructor taking the name of the thread as well as the Runnable object — new Thread(runnableObj, "MyThread").

Any of these constructors can be used to create an object of the Thread class. The lecture demonstrates each of these forms in later examples.

Data members of the Thread class include two fields:

• Name of the thread — the first field.
• Priority of the thread — the second field.

Priority is order of execution. An example is given: T1 has priority 2, T2 has priority 6. Six is higher than two, so T2 has higher priority and should be considered first when allocating the CPU. Once T2 has done its execution or moved to sleep mode, chance is given to T1. The default priority for a newly created thread is 5, and it can be changed.

Methods available with the Thread class that are named include:

• getName and setName for getting and setting the name of the thread.
• getPriority and setPriority for priority.
• isAlive which returns true if the thread is alive.
• currentThread which returns the current active thread when multiple threads exist. It is a public static method called as Thread.currentThread().
• activeCount which returns the total number of threads currently active.

In the examples these constructors and methods are used to observe functioning. Line-by-line demos of each are promised and then delivered.

Visual for constructors: picture four factory doors labeled no-arg, name-only, runnable-only, runnable+name. Each door outputs a Thread object, but only the doors that receive a Runnable carry custom work; the no-arg door outputs a thread with empty run.

23.5.3 Runnable Interface and the run Method

The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread. As an interface it means method declarations. The key fact is that any class implementing Runnable must define one method: public void run. The name is repeated: public void run. Thread execution starts from public void run. A class may have other methods, but having public void run is necessary because whatever task the thread must perform should be available in public void run and must be defined in the program.

23.5.4 Relationship — Thread Implements Runnable

A point presented as surprising: the Thread class itself implements the Runnable interface. So there are two routes that converge. If a class ABC extends Thread, that is the first way of creating threads, it indirectly goes through Runnable because Thread implements Runnable, and that is why public void run is available there. Alternatively, a class can directly implement Runnable and provide public void run. Both routes lead to defining run for the thread task. This duality is explained twice for clarity.

23.5.5 Thread Priority — Default and Customization

Priority was already introduced as a data member. The elaboration covers default value 5, how to change it, and how to read it back. The methods setPriority and getPriority are paired with setName and getName. The lecture notes that changing priority affects scheduling order but the actual selection also depends on underlying system resources and operating system policies. A later worked example shows changing main thread priority from 5 to 2 and printing the values before and after.

23.5.6 Exception Handling Around Thread Operations

When creating multiple threads, the surrounding code in several examples wraps thread work in try and catch blocks. The reason given is that based on available resources on the system or operating system policies, an attempt to create multiple threads may not be allowed, or sufficient memory or resources may be unavailable. In that case an exception may occur. To avoid abnormal termination and runtime exceptions, the statements that get the current thread or id or other thread operations are placed in try and catch blocks. This practice is presented as part of multi-threaded programs, not as an afterthought.

23.6 Worked Examples of Single Thread Creation

23.6.1 Example 1 — Extending Thread with Public Void Run

This first example talks about creating a thread using the Thread class.

class ABC extends Thread {
    public void run() {
        // task for the thread
        System.out.println("Task inside run");
    }
}
public class Main {
    public static void main(String[] args) {
        ABC a = new ABC();
        a.start();
    }
}

This pattern is presented as the equivalent of example number one in the slides, extending Thread and defining run and starting with start.

23.6.2 Example 2 — Direct Thread Object Without Extending

This second example uses the Thread class again but with a different constructor where the name of the thread is not explicitly given, and no subclass is created.

public class Main {
    public static void main(String[] args) {
        Thread t = new Thread();
        t.start();
        System.out.println(t.getName());
    }
}

Why it matters: it proves that thread creation is tied to the Thread object and start, while useful work is tied to run. No run means no work, but still a lifecycle was traversed.

23.6.3 Example 3 — Implementing Runnable and Passing to Thread

Previous two examples were related to the Thread class; this one is related to the Runnable interface.

class ABC implements Runnable {
    public void run() {
        System.out.println("Task from Runnable");
    }
}
public class Main {
    public static void main(String[] args) {
        ABC a = new ABC();
        Thread t1 = new Thread(a);
        t1.start();
    }
}

The Runnable path keeps class ABC free to extend another class if needed, because it does not extend Thread.

23.6.4 Example 4 — Runnable Object Plus Thread Name Using the Fourth Constructor

This example creates a Thread object using the fourth constructor which takes both a Runnable object and a String name.

class ABC implements Runnable {
    public void run() {
        System.out.println("Task from Runnable with name");
    }
}
public class Main {
    public static void main(String[] args) {
        ABC a1 = new ABC();
        Thread th1 = new Thread(a1, "MyThread");
        th1.start();
        String str = th1.getName();
        System.out.println(str);
    }
}

23.6.5 Example 5 — The Main Thread and Changing Name and Priority

This example is about changing thread name and priority and is described as very interesting, explained line by line with output.

class Test1 {
    public static void main(String[] args) {
        Thread t = Thread.currentThread();
        System.out.println("Current thread: " + t);
        System.out.println("Name: " + t.getName());
        System.out.println("Priority: " + t.getPriority());
        t.setName("MyThread");
        System.out.println("After name changed: " + t.getName());
        t.setPriority(2);
        System.out.println("After priority changed: " + t.getPriority());
        System.out.println("After change details: " + t);
    }
}

Concepts reinforced across all five single-thread examples: Extending Thread with public void run and starting via a.start is Example 1; a direct Thread object without extending shows defaults in Example 2; implementing Runnable and passing to Thread via the Runnable constructor is Example 3; adding a name via the fourth constructor is Example 4; and inspecting and changing the automatic main thread's name and priority via currentThread, setName, setPriority, getName, getPriority is Example 5.

23.7 Multithreading in Practice — Creating and Controlling Multiple Threads

23.7.1 What Multithreading Means and Why Shared Memory Matters

Multithreading is defined as a process of executing multiple threads simultaneously. Recall P1 with threads T1, T2, T3 sharing the memory address available to P1. That memory address is shared between all threads. After some time a thread gets a chance to execute in the Running state and may go to a temporary suspended Blocked or Waiting state. For example, first T1 is given a chance, then after some reason T1 must wait so its execution is stopped but not completed, and chance is given to T2. When T1 stops and returns, it resumes from where it stopped, but during that time contents of memory may have been changed by T2. Whenever multiple threads execute simultaneously, side effects are possible and awareness is needed, along with methods to deal with them.

This section is framed as three subparts: first learn multi-threading and how to create and execute multiple threads and see output, then look at consequences of having multiple threads, then how to resolve them.

Additional points restated: When a program starts a thread is automatically created called the main thread, threads use a shared memory area covering the heap and many structures, they do not allocate a separate memory area per thread and so save memory, and context switching between threads takes less time than between processes. The saving and speed are due to shared area. A common template for upcoming examples is class Test1 extends Thread or a class that uses Runnable with run wrapped in try and catch for resource reasons, and main creating multiple threads.

23.7.2 Creating Five Threads with a Loop Using the Thread Class

This example corresponds to example numbers five and six in the slides that create five threads using the Thread class.

class Test1 extends Thread {
    public void run() {
        try {
            System.out.println("Current thread: " + Thread.currentThread()
                               + " ID: " + Thread.currentThread().getId());
        } catch (Exception e) { }
    }
}
public class Driver {
    public static void main(String[] args) {
        int n = 5;
        for (int i = 0; i < n; i++) {
            Test1 obj = new Test1();
            obj.start();
        }
    }
}

23.7.3 Creating Five Threads with a Loop Using Runnable

The same five-thread creation is now done by implementing Runnable instead of extending Thread.

class Test2 implements Runnable {
    public void run() {
        try {
            System.out.println("Current thread: " + Thread.currentThread()
                               + " ID: " + Thread.currentThread().getId());
        } catch (Exception e) { }
    }
}
public class Driver2 {
    public static void main(String[] args) {
        int n = 5;
        for (int i = 0; i < n; i++) {
            Thread obj = new Thread(new Test2());
            obj.start();
            // alternative: Runnable r = new Test2(); Thread obj = new Thread(r);
        }
    }
}

Note: The lecture mentions a planned program to create two threads with factorial functionality as example number seven, but the lecture had already run over an hour and a short break of seven to eight minutes was taken, so that factorial example's detailed walkthrough is not included beyond its mention.

23.7.4 Controlling Execution with Sleep — Timed Waiting

The sleep method is used to put a thread into a waiting state for a decided temporary time, implementing timed waiting.

This demonstrates timed waiting and how sleep lets other threads get CPU instead of keeping it idle while one thread would otherwise monopolize it. Note that sleep is static: Thread.sleep(500) always sleeps the currently running thread, regardless of which object you call it on.

23.7.5 Controlling Execution with Join — Waiting for Completion

The join method is used to wait for the current thread to complete its execution. sleep puts a thread to sleep for a set time; join makes the calling thread wait until the target thread finishes.

23.7.6 Combining Sleep and Join — Coordinated Interleaving

A combined example puts both concepts together. It has the same Test1 with run sleeping 500 milliseconds each iteration and driver Test2 creating t1 and t2, printing alive status then invoking t1.t.join() and t2.t.join(). Because both threads go to the same run with sleep(500), the behavior is: t1 executes and sleeps 500 milliseconds, chance is given to t2, t2 sleeps 500 milliseconds, chance back to t1, and the cycle continues despite the join waiting and keeping the scheduler active. The lecture notes that when a thread goes to sleep the CPU cannot be kept idle, so chance must be given to another thread. The interleaving is shown in output: Waiting for threads to finish then prints alternating lines from both workers and finally One exiting and Two exiting, indicating alternating execution rather than strict sequential blocking. After both finish, isAlive returns false, printed as not alive. This demonstrates coordination: sleep creates timed waiting, join ensures waiting for completion, and together they show how threads interleave when given chances.

Practical guidance: change the sleep timer and join usage to better understand how threads work and how the operating system responds. That hands-on experimentation is highly recommended.

23.7.7 Observations on Thread IDs and Nondeterministic Ordering

Both five-thread examples yielded ids 14, 15, 16, 17, 18 but in order 14, 18, 17, 16, 15. The lecture stresses that this sequence is not fixed and may be different on the next execution or on another machine due to JVM policies and underlying resources. Thread id allocation is up to the JVM, not the specification. Context switching decisions depend on which thread is in Blocked or Running, and the operating system performs switching at high speed invisible to the user. Only the final printed order is seen. Students are advised to run the programs themselves to see their own sequences and ids.

23.8 Thread Synchronization — Monitors, Synchronized Methods and Blocks

23.8.1 The Problem — Corruption of the Shared Resource Without Synchronization

Even after controlling priority, sleep, and join, desired tasks may still fail because shared memory or data structures can be corrupted. When multiple threads are created and executed simultaneously but side effects are not handled, synchronization is needed. There are predefined methods, statements, and blocks available to better control thread functioning. This is described as one of the important and interesting topics, with several examples.

The underlying risk was already introduced: threads share memory, so unsynchronized access to a common area can corrupt data. Synchronization addresses that.

23.8.2 Monitor and Mutually Exclusive Block Concept

Synchronization is introduced when two or more threads need access to a shared resource and must be synchronized. The key to synchronization is the concept of the monitor — an object that is used as a mutually exclusive block.

Visualization: Suppose thread T1 executes some task, T2 executes some task, and there is some common area between them with common code. After executing that common area, each continues. That common area is called a mutually exclusive block. Why mutually exclusive? Because at a time if T1 is executing then T2 should not be able to enter, or if T2 is executing then T1 should not be able to enter. Only one thread should execute that block at a time.

Control is via a monitor, described like a token to access the mutually exclusive block. First T1 is given grant to the monitor, so when T2 comes and sees T1 holding the monitor it cannot enter. Similarly if T2 holds the monitor T1 cannot enter. Only one thread can own a monitor at a given time because it is like a token for the mutually exclusive block, acquiring a lock that suspends all other threads attempting to enter until the first thread exits the monitor. The monitor locks other threads until exit.

Method-level rule: To enter an object's monitor just call a method that has been modified with the synchronized keyword. While a thread is inside a synchronized method, all other threads that try to call it on the same instance have to wait. When a thread exits the monitor it simply returns from the method and the monitor becomes available for other threads. This definition of synchronized method is the first synchronization mechanism.

Telephone-booth analogy from the companion book: the object is a booth, threads are people wanting to make a call. Only one person can be inside. If the coin reservoir is full, the person inside must wait outside to let a technician in — that maps to wait and notify.

23.8.3 Worked Demonstration Without Synchronization — CallMe Caller Synch

Code without synchronization is shown to make the problem visible.

class CallMe {
    void call(String msg) {
        System.out.print("[" + msg);
        try { Thread.sleep(1000); } catch (Exception e) {}
        System.out.println("]");
    }
}
class Caller implements Runnable {
    String msg;
    CallMe target;
    Thread t;
    Caller(CallMe targ, String s) {
        target = targ;
        msg = s;
        t = new Thread(this);
        t.start();
    }
    public void run() {
        target.call(msg);
    }
}
class Synch {
    public static void main(String[] args) {
        CallMe target = new CallMe();
        Caller ob1 = new Caller(target, "Hello");
        Caller ob2 = new Caller(target, "Java");
        Caller ob3 = new Caller(target, "Programming");
        try {
            ob1.t.join();
            ob2.t.join();
            ob3.t.join();
        } catch (Exception e) {}
    }
}

23.8.4 Solution 1 — Synchronized Method

To avoid the problem, use the synchronized method. Put the synchronized keyword before the definition of the call method.

class CallMe {
    synchronized void call(String msg) {
        System.out.print("[" + msg);
        try { Thread.sleep(1000); } catch (Exception e) {}
        System.out.println("]");
    }
}

Visual after the fix: the same timeline now shows bracket blocks that never overlap. Each block [msg] occupies a solid interval on the target lane, with sleep inside the block. The x-axis is time, the y-axis lists threads; the target monitor line shows only one thread owning it at a time.

23.8.5 Solution 2 — Synchronized Block or Statement

The second way is simple: put the calls to the method inside a synchronized block, also called the synchronized statement. If you do not want the whole method to be synchronized, do not put synchronized before the method but just wrap the call to the mutually exclusive method within a synchronized block.

public void run() {
    synchronized(target) {
        target.call(msg);
    }
}

23.8.6 Effect on Timing versus Correctness

Synchronization affects functioning because purposely keeping the monitor locked for 1000 milliseconds makes output come later but keeps correctness. The trade-off between timing and atomicity is explicit: unsynchronized runs faster in wall-clock interleaving but produces garbled brackets; synchronized runs slower but preserves unit order. That distinction is used to justify synchronization overhead.

23.8.7 Practical Guidance for Practice

It is stressed that slides will be uploaded to the portal and students are highly recommended to take the slides and examples and practice on their own to get a good understanding at practice level. Changing sleep time and join handling and observing operating system response is advised. The lecture closed after covering threads, difference between process and thread, creation via Thread class or Runnable, different constructors, runnable interface, many examples, multi-threading creation, problems, sleep and join uses, priorities, and synchronization.

Exam Guidance Summary

This lecture gave no separate mark distribution or count of exam questions and did not state what is excluded from the exam, nor any time-management hints for the paper. The exam-relevant guidance that was given is practical and centered on hands-on tracing.

Key Industry Applications

Everyday process picture: the music player, web browser, and Word or Excel document as separate processes illustrate multitasking on a single CPU. The operating system context-switches the whole process state, so each keeps private memory. This model scales to any desktop where you run several programs at once.

Inside one program the lecture's input–processing–printing split is the common template for responsiveness. A text editor uses one thread to handle typing, a second to format text and check spelling, and a third to write to disk. A browser uses threads to load multiple images into a page while you scroll. Efficient use of the shared memory area by threads saves memory and reduces context-switch time, which matters when the system handles many short tasks.

Java's main thread anchors every application. When a program starts, the JVM creates the main thread automatically, and any worker threads you create with the Thread class or the Runnable interface run alongside it. The JVM together with the underlying operating system decides thread ids and scheduling, so ids such as 14, 15, 16, 17, 18 observed in the lecture are JVM-assigned and vary across machines and runs — a reality visible in real deployments where the same build behaves slightly differently on two machines.

Web servers, background jobs, and interactive tools rely on sleep for timed waiting and join for waiting for completion to coordinate workers. A server sleeps poll threads between checks and joins workers before shutting down. An animation loop sleeps between frames while the user-interface thread stays responsive.

Finally, monitors with synchronized methods and synchronized(target) blocks protect shared resources wherever interleaving would corrupt output — from the lecture's bracket printer to production queues, caches, loggers, and counters that many threads update. The textbook BoundedQueue example shows the same idea: queue add and remove must be guarded so two producers do not overwrite the same tail slot. The pattern is to identify the mutually exclusive block, pick one lock object that all threads agree on, and hold that lock only for the critical steps.