Using synchronized blocks and volatile variables to ask a Java thread to terminate gracefully

Find a copy of Java Concurrency in Practice, it's got very good chapter on Cancellation and Shutdown.

You've made cancelProcess() private, so your outside threads aren't going to do anything to prevent process.waitForResponse() from blocking. That's no good - let's make it public.

In addition to that, trying to cancel a running process by setting a volatile variable is an anti-pattern. For your specific example, consider what happens if the external thread tries to cancel while process.waitForResponse() is running. It doesn't do much good, does it -- ExecuteProcess can't check processKilled until the waitForReponse returns, and by then there is no point, you've already been forced to wait.

Interruption is usually the most sensible way to implement cancellation.

As noted above, you can write an entire chapter on that problem; I'll spare us all that. What that quotation does mean, though, is that task cancellation is a lousy example for learning about volatile variables.

Code Review

There's already a standard interface called Runnable; it's appropriate to use it here. The runnable method returns a void though, so you should consider other ways to signal success and failure. An alternative to Runnable would be a Callable<T>, which supports returning values.

The Callable interface is similar to Runnable, in that both are designed for classes whose instances are potentially executed by another thread. A Runnable, however, does not return a result and cannot throw a checked exception.

Creating a process is a separate responsibility from running a process. You should probably inject the process to be run, via the constructor. The class might then look like:

public class ExecuteProcess implements Callable<Boolean> {
    private final Process process;

    public ExecuteProcess(Process process) {
        this.process = process;
    }

    Boolean call () {
        ...
    }
}

Also, it's really poor form to return null in a function that promises a boolean.

In Java, Locking, Synchronization, and volatility all relate to the state of the Java memory model at a specific point in the code.

Normally, in Java, you cannot really tell what the memory model looks like for each thread. Volatile, synchronization, and other locks change the memory model so that you can make guarantees about it's state at specific code points.

There are books written about this... Java Concurrency in Practice is the most recommended (and I recommend it too).

What is generally accepted is that for any code, you should choose only one of these three tools to manage your code. You should not mix volatile statements with synchronization, and with java.util.concurrent.lock.* structures.

Volatile

volatile is essentially only useful for ensuring that a change in one thread is propagated quickly to another thread. It is not particularly useful for operations that require multiple 'steps' because you still have race conditions between the steps.

In fact, compound operations like x++ are not safe even. Volatile ensures that, at the immediate point the volatile is used, that it is the same in all threads. It does not mean it is the same at the end of the operation in each thread.

In my experience, non-boolean volatile variables are inevitably broken in some way, and boolean volatiles are misused at least half the time.

Admittedly my understanding of the full implications of volatile is incomplete, and is harder to quantify because I first learned Java at a time when volatile often simply did not work. volatile has maybe changed a bit, but, in general, don't use it unless you know what you are doing.

Double-checked locking

        if (!processKilled)
            cancelProcess();

and then cancelProcess contains:

    synchronized (processLock) {
        if (process != null && !processKilled) {
            boolean killed = process.kill();

            if (killed)
                processKilled = true;
        }
    }

What you have here is double-checked locking. Read this paper by Bill Pugh on it.

......

VoiceOfUnreason has also answerd here. My answer is incomplete, but what I would have said is covered well over there