Introduction

A thread blocked on socket I O is not actively checking your stop flag. It is waiting inside an operating-system call, which means the way to stop it is to make that blocking call return. In classic socket code, the standard approach is to close the socket from another thread and let the worker exit normally.

Why a Stop Flag Does Not Work by Itself

A shared boolean flag works only if the thread gets regular chances to read it. A blocking call such as read, readLine, or recv does not wake up just because your program changed a variable.

This means a loop like this looks plausible but will not stop promptly:

1class ReaderWorker extends Thread {
2    private volatile boolean running = true;
3
4    public void shutdown() {
5        running = false;
6    }
7
8    @Override
9    public void run() {
10        while (running) {
11            // blocked socket read here
12        }
13    }
14}

The logic is not wrong. It is just incomplete, because the blocked read never gets a chance to see the new flag value.

Close the Socket to Unblock the Read

For ordinary java.net.Socket code, the usual shutdown sequence is:

1. mark the worker as stopping
2. close the socket
3. wait for the thread to exit

1import java.io.BufferedReader;
2import java.io.IOException;
3import java.io.InputStreamReader;
4import java.net.Socket;
5import java.net.SocketException;
6
7public final class ReaderWorker extends Thread {
8    private final Socket socket;
9    private volatile boolean stopping;
10
11    public ReaderWorker(Socket socket) {
12        this.socket = socket;
13    }
14
15    public void shutdown() throws IOException {
16        stopping = true;
17        socket.close();
18    }
19
20    @Override
21    public void run() {
22        try (BufferedReader reader =
23                 new BufferedReader(new InputStreamReader(socket.getInputStream()))) {
24            while (!stopping) {
25                String line = reader.readLine();
26                if (line == null) {
27                    break;
28                }
29                System.out.println("received: " + line);
30            }
31        } catch (SocketException ex) {
32            if (!stopping) {
33                System.err.println("unexpected socket error: " + ex.getMessage());
34            }
35        } catch (IOException ex) {
36            System.err.println("I O failure: " + ex.getMessage());
37        }
38    }
39}

Controller code:

1Socket socket = new Socket("127.0.0.1", 9000);
2ReaderWorker worker = new ReaderWorker(socket);
3worker.start();
4
5worker.shutdown();
6worker.join();

Closing the socket causes the blocked read to return or throw, which gives the thread a clean path out.

Timeouts for Cooperative Shutdown

If you cannot close the socket immediately, a read timeout can make the worker wake periodically, check state, and then continue or exit.

socket.setSoTimeout(1000);

That is useful when the loop needs to handle more than one shutdown condition or perform periodic housekeeping. But it is not “instant” termination. It is cooperative polling with a bounded delay.

If the real requirement is immediate stop, closing the socket is still the direct mechanism.

interrupt() Is Not Enough in Classic Socket Code

A common assumption is that Thread.interrupt() should break any blocked call. That is not a safe assumption for classic stream-based socket I O. Some blocking APIs react to interruption cleanly, but ordinary socket reads are not guaranteed to stop just because the thread's interrupted status changed.

That is why the more reliable shutdown boundary is the socket resource, not just the thread object.

Design Shutdown Around the Resource

The cleanest pattern is not “kill the thread.” It is “close the connection and let the worker finish.” That matters because the thread may own parser state, metrics, buffers, and cleanup work that should not be abandoned mid-operation.

A robust shutdown path usually includes:

• a stopping flag to mark intent
• 'socket.close() to unblock the read'
• 'join() so the caller knows the worker is done'
• logging that distinguishes expected shutdown from real network failure

When those parts are present, the behavior becomes deterministic and testable.

NIO Is a Different Model

If you move to non-blocking NIO channels and selectors, shutdown behavior and interruption semantics are different. But the original question usually comes from classic blocking socket code, and in that model the close-the-socket approach is still the normal answer.

That distinction matters because many online discussions mix NIO and old blocking stream code as if they behaved the same way.

Common Pitfalls

• Setting a stop flag and assuming a blocked socket read will notice it.
• Calling forceful thread-kill mechanisms instead of ending the socket operation cleanly.
• Relying on interrupt() alone for classic blocking socket reads.
• Closing the socket but never waiting for the worker thread to finish.
• Logging expected shutdown exceptions as fatal production errors.

Summary

• A thread blocked on socket I O stops only when the blocked operation returns.
• In classic socket code, the normal way to make that happen is to close the socket from another thread.
• Timeouts help with cooperative shutdown but are not truly instant.
• 'interrupt() alone is not a reliable answer for ordinary blocking socket reads.'
• Build shutdown around the socket lifecycle and verify the worker thread actually exits.