import java.util.concurrent.*;

/**
 * @author Denis Zhdanov
 */
public class CCC {

    private final ConcurrentHashMap<String, Future<Void>> cache = new ConcurrentHashMap<String, Future<Void>>();

    public static void main(String[] args) throws Exception {
        final CCC ccc = new CCC();

        Thread impatientThread = new Thread() {
            public void run() {
                System.out.println("Impatient client requested for data");
                try {
                    ccc.compute();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };
        System.out.println("Starting impatient client. ThreadId=" + System.identityHashCode(impatientThread));
        impatientThread.start();

        for (final int i : new int[] {1, 2}) {
            new Thread() {
                public void run() {
                    System.out.println("Starting client " + i + ". ThreadId=" + System.identityHashCode(this));
                    System.out.println("Client " + i + " requested for data");
                    try {
                        ccc.compute();
                        System.out.println("Client " + i + " received response");
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }.start();
        }

        Thread.sleep(1000);
        System.out.println("Impatient client cancels request for data");
        impatientThread.interrupt();
    }

    public Void compute() throws InterruptedException {
        while (true) {
            Future<Void> f = cache.get("1");
            if (f == null) {
                Callable<Void> eval = new Callable<Void>() {
                    public Void call() throws InterruptedException {
                        System.out.println("Computation started");
                        Thread.sleep(3000);
                        System.out.println("Computation ended");
                        return null;
                    }
                };
                FutureTask<Void> ft = new FutureTask<Void>(eval);
                f = cache.putIfAbsent("1", ft);
                if (f == null) {
                    f = ft;
                    ft.run();
                }
            }
            try {
                return f.get();
            } catch (CancellationException e) {
                System.out.println("CancellationException, threadId=" + System.identityHashCode(Thread.currentThread()));
                cache.remove("1", f);
            } catch (ExecutionException e) {
                // cache.remove("1", f); (1)
                System.out.println("ExecutionException, threadId=" + System.identityHashCode(Thread.currentThread()));
            }
        }
    }
}

Starting impatient client. ThreadId=22837328
Impatient client requested for data
Computation started
Starting client 2. ThreadId=8451275
Client 2 requested for data
Starting client 1. ThreadId=3374351
Client 1 requested for data
Impatient client cancels request for data
ExecutionException, threadId=8451275
ExecutionException, threadId=22837328
ExecutionException, threadId=3374351
ExecutionException, threadId=8451275
ExecutionException, threadId=22837328
ExecutionException, threadId=3374351
ExecutionException, threadId=8451275
ExecutionException, threadId=3374351
ExecutionException, threadId=8451275
ExecutionException, threadId=22837328
etc

Starting impatient client. ThreadId=22837328
Impatient client requested for data
Starting client 2. ThreadId=8451275
Client 2 requested for data
Computation started
Starting client 1. ThreadId=3374351
Client 1 requested for data
Impatient client cancels request for data
ExecutionException, threadId=8451275
ExecutionException, threadId=3374351
ExecutionException, threadId=22837328
Computation started
Computation ended
Client 1 received response
Client 2 received response

Java 5.0 is a huge step forward for the development of concurrent applications in Java, providing new higher-level components and additional low-level mechanisms that make it easier for novices and experts alike to build concurrent applications. The authors are primary members of the JCP Expert Group that created these facilities; in addition to describing their behavior and features, we present the underlying design patterns and anticipated usage scenarios that motivated their inclusion in the platform libraries.

 
class Test
{
   private int a;
   private boolean b;

   public Test() {a = 0; b = false;}

   public void setter() { a = 1; b = true;}

   public boolean test() { 
      if ((a == 0) && (b)) return true;
      return false;
   }
}

Caching a Future instead of a value creates the possibility of cache pollution: if a computation is cancelled or fails, future attempts to compute the result will also indicate cancellation or failure. To avoid this, Memoizer removes the Future from the cache if it detects that the computation was cancelled; it might also be desirable to remove the Future upon detecting a RuntimeException if the computation might succeed on a future attempt. Memoizer also does not address cache expiration, but this could be accomplished by using a subclass of FutureTask that associates an expiration time with each result and periodically scanning the cache for expired entries. (Similarly, it does not address cache eviction, where old entries are removed to make room for new ones so that the cache does not consume too much memory.)

B>Это, конечно, хорошо, но не так уж и много Мне не нравится сама идея с тем, что вычисления производятся в клиентских потоках, а не в worker thread.

class CCC {

    private final ConcurrentHashMap<String, Future<Void>> cache = new ConcurrentHashMap<String, Future<Void>>();
    private static final ExecutorService exec = Executors.newFixedThreadPool(2);

    public static void main2() throws Exception {
        final CCC ccc = new CCC();

        Thread impatientThread = new Thread() {
            public void run() {
                System.out.println("Impatient client requested for data");
                try {
                    ccc.compute();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };
        System.out.println("Starting impatient client. ThreadId=" + System.identityHashCode(impatientThread));
        impatientThread.start();

        for (final int i : new int[] {1, 2}) {
            new Thread() {
                public void run() {
                    System.out.println("Starting client " + i + ". ThreadId=" + System.identityHashCode(this));
                    System.out.println("Client " + i + " requested for data");
                    try {
                        ccc.compute();
                        System.out.println("Client " + i + " received response");
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }.start();
        }

        Thread.sleep(1000);
//        System.out.println("Impatient client cancels request for data");
//        impatientThread.interrupt();
        exec.shutdown();
    }

    public Void compute() throws InterruptedException {
        while (true) {
            Future<Void> f = cache.get("1");
            if (f == null) {
                Callable<Void> eval = new Callable<Void>() {
                    public Void call() throws InterruptedException {
                        System.out.println("Computation started");
                        Thread.sleep(3000);
                        System.out.println("Computation ended");
                        return null;
                    }
                };
                System.out.println("1");
                Future<Void> ft = exec.submit(eval);
                System.out.println("2");
                f = cache.putIfAbsent("1", ft);
                if (f == null) f = ft;
            }
            try {
                Thread.sleep(1000);
                System.out.println("Print 1000, threadId=" + System.identityHashCode(Thread.currentThread()));
                Thread.sleep(1000);
                System.out.println("Print 2000, threadId=" + System.identityHashCode(Thread.currentThread()));
                Thread.sleep(1000);
                System.out.println("Print 3000, threadId=" + System.identityHashCode(Thread.currentThread()));
                Thread.sleep(4000);
                System.out.println("Print 4000, threadId=" + System.identityHashCode(Thread.currentThread()));

                return f.get();
            } catch (CancellationException e) {
                System.out.println("CancellationException, threadId=" + System.identityHashCode(Thread.currentThread()));
                cache.remove("1", f);
            } catch (ExecutionException e) {
                cache.remove("1", f);
                System.out.println("ExecutionException, threadId=" + System.identityHashCode(Thread.currentThread()));
            }

        }
    }
}

Starting impatient client. ThreadId=5678233
Impatient client requested for data
1
2
Starting client 1. ThreadId=14746332
Client 1 requested for data
Computation started
Starting client 2. ThreadId=8568863
Client 2 requested for data
Print 1000, threadId=5678233
Print 1000, threadId=14746332
Print 1000, threadId=8568863
Print 2000, threadId=5678233
Print 2000, threadId=14746332
Print 2000, threadId=8568863
Print 3000, threadId=5678233
Computation ended
Print 3000, threadId=14746332
Print 3000, threadId=8568863
Print 4000, threadId=5678233
Print 4000, threadId=14746332
Client 1 received response
Print 4000, threadId=8568863
Client 2 received response

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        ExecutorService executor = Executors.newFixedThreadPool(1); // (1)
        Runnable task = new Runnable() {
            public void run() {
            }
        };
        executor.submit(task); // (2)
    }

AbstractExecutorService.submit(Runnable task)
                 |
ThreadPoolExecutor.execute(Runnable command)
                 |
ThreadPoolExecutor.addIfUnderCorePoolSize(Runnable firstTask)
                 |
ThreadPoolExecutor.addThread(Runnable firstTask)
                 |
DefaultThreadFactory.newThread(Runnable r)

        public Thread newThread(Runnable r) {
            Thread t = new Thread(group, r, 
                                  namePrefix + threadNumber.getAndIncrement(),
                                  0);
            if (t.isDaemon())
                t.setDaemon(false);
            if (t.getPriority() != Thread.NORM_PRIORITY)
                t.setPriority(Thread.NORM_PRIORITY);
            return t;
        }

SZ>Сорри, поторопился слегка На самом деле предыдущие виртуальные машины могли реордерить volatile и non-volatile (т.е. если int не volatile, а bool — volatile, тогда код не работает). Две volatile переменные запрещалось реордерить и раньше. В новых VM (5.0), грубо говоря, запрещен также реордеринг volatile и non-volatile переменных. Т.е. после до присваивания чего-либо volatile переменной компилятор обязан сделать все присвоения non-volatile переменных. В новых VM (5.0), грубо говоря, запрещен также реордеринг volatile и non-volatile переменных.

"The main JMM rules for volatiles and monitors can be viewed as a matrix with cells indicating that 
you cannot reorder instructions associated with particular sequences of bytecodes. This table is not
 itself the JMM specification; it is just a useful way of viewing its main consequences for compilers
 and runtime systems.



------------------------------------------------------------------------------------------------
         Can Reorder          |                         2nd operation                           |
------------------------------------------------------------------------------------------------
        1st operation         |Normal Load/Store    |Vol Load/MonitorEnter|Vol Store/MonitorExit|
------------------------------------------------------------------------------------------------
Normal Load/Store             |                     |                     |         No          |
------------------------------------------------------------------------------------------------
Vol Load/MonitorEnter         |        No           |        No           |         No          |
------------------------------------------------------------------------------------------------
Vol Store/MonitorExit         |                     |        No           |         No          |
------------------------------------------------------------------------------------------------

Where:
    * Normal Loads are getfield, getstatic, array load of non-volatile fields
    * Normal Stores are putfield, putstatic, array store of non-volatile fields
    * Volatile Loads are getfield, getstatic of volatile fields that are accessible by multiple threads
    * Volatile Stores are putfield, putstatic of volatile fields that are accessible by multiple threads
    * MonitorEnters (including entry to synchronized methods) are for lock objects accessible by multiple threads.
    * MonitorExits (including exit from synchronized methods) are for lock objects accessible by multiple threads. 

The cells for Normal Loads are the same as for Normal Stores, those for Volatile Loads are the 
same as MonitorEnter, and those for Volatile Stores are same as MonitorExit, so they are collapsed 
together here (but are expanded out as needed in subsequent tables).

Any number of other operations might be present between the indicated 1st and 2nd operations in 
the table. So, for example, the "No" in cell [Normal Store, Volatile Store] says that a
 non-volatile store cannot be reordered with ANY subsequent volatile store; at least any that
can make a difference in multithreaded program semantics."

SZ>>Сорри, поторопился слегка На самом деле предыдущие виртуальные машины могли реордерить volatile и non-volatile (т.е. если int не volatile, а bool — volatile, тогда код не работает). Две volatile переменные запрещалось реордерить и раньше. В новых VM (5.0), грубо говоря, запрещен также реордеринг volatile и non-volatile переменных. Т.е. после до присваивания чего-либо volatile переменной компилятор обязан сделать все присвоения non-volatile переменных. В новых VM (5.0), грубо говоря, запрещен также реордеринг volatile и non-volatile переменных.

This table is not itself the JMM specification; it is just a useful way of viewing its main consequences for compilers and runtime systems.

So, for example, the "No" in cell [Normal Store, Volatile Store] says that a non-volatile store cannot be reordered with ANY subsequent volatile store; at least any that can make a difference in multithreaded program semantics.

class Shared {
    public volatile int vol = 0;
    public int nonvol = 0;
    public void doIt() {
        vol = 1;
        nonvol = 1;
    }
}

Shared shared = ... 
if (shared.vol == 0 && shared.nonvol == 1) {...}

GI>class Shared {
GI>    public volatile int vol = 0;
GI>    public int nonvol = 0;
GI>    public void doIt() {
GI>        vol = 1;
GI>        nonvol = 1;
GI>    }
GI>}
GI>

GI>Shared shared = ... 
GI>if (shared.vol == 0 && shared.nonvol == 1) {...}
GI>

GI>Вполне допускаю, что я не прав. Но тогда я заблуждаюсь искренне.

1. Thread t1 calls doIt();
   
2. Thread t2 checks 'shared.vol == 0 (true)';
   
3. t1 executes 'vol = 1; nonvol = 1';
   
4. t2 checks 'shared.nonvol ==1 (true)';

GI>Вполне допускаю, что я не прав. Но тогда я заблуждаюсь искренне.

    public void doIt() {
        vol = 1;
        nonvol = 1;
    }

    public void check() {
        if (shared.nonvol == 1 && shared.vol == 0)
        {...}
    }

17.4.3 Programs and Program Order
If a program has no data races, then all executions of the program will appear to be sequentially consistent.

17.4.5 Happens-before Order
Programmers do not need to reason about reorderings to determine that their code contains data races. Therefore they do not need to reason about reorderings when determining whether their code is correctly
synchronized. Once the determination that the code is correctly synchronized is made, the programmer does not need to worry that reorderings will affect his or her code.

17.4.5 Happens-before Order
It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results consistent with a legal execution, it is not illegal.

12.6.8 Other memory model issues
A conforming implementation of the CLI shall ensure that, even in a multi-threaded environment and without
proper user synchronization, objects are allocated in a manner that prevents unauthorized memory access and
prevents invalid operations from occurring. In particular, on multiprocessor memory systems where explicit
synchronization is required to ensure that all relevant data structures are visible (for example, vtable pointers)
the Execution Engine shall be responsible for either enforcing this synchronization automatically or for
converting errors due to lack of synchronization into non-fatal, non-corrupting, user-visible exceptions.

1. У класса С1 есть non-final, non-volatile поле с инициализатором;
   
2. В потоке t1 создается объект О1 класса С1;
   
3. В потоке t2 считывается О1.field, упоминавшееся в первом пункте;
   
4. t2 видит в качестве значения О1.field значение, отличное от инициализатора, заданного в классе С1;

class ReorderingTest {
    static Shared shared = new Shared();
    public static void main(String[] args) {
        new Thread() {
            public void run() {
                shared.doIt();
            }
        }.start();
        new Thread() {
            public void run() {
                shared.check();
            }
        }.start();
    }
}

class Shared {
    private volatile int vol;
    private int nonvol;

    public void doIt() {
        this.vol = 1;
        this.nonvol = 1;
    }

    public void check() {
        if (this.nonvol == 1 && this.vol == 0) {
            System.out.println("Hello from Kharkov!");
        }
    }
}

GI>remark уже согласился, хотя и обозвал такую программу not correctly synchronized. Но! Я и не утверждал, что программа будет без дата рейсов, меня интересовала только согласованность со спекой. Т.е. перебор всех допустимых спецификацией сценариев. Если я ошибаюсь, могли бы Вы привести цитаты из спеки запрещающие привет из Харькова ?

1. GI>Вот программа, показывает то-то и то-то;
   
2. DZ>Такая ситуация возможна только в том случае, если приложение выполняется под таким окружением...фишка в том, что формально спецификация языка не запрещает такого поведения;
   
3. GI>Я утвеждаю, что следующая программа МОЖЕТ передать "привет из Харькова"..., если я ошибаюсь, могли бы Вы привести цитаты из спеки запрещающие привет из Харькова;

java.lang.String.java:

public final class String ... {
    ...    
    /** Cache the hash code for the string */
    private int hash; // Default to 0
    ...
    /**
     * Returns a hash code for this string. The hash code for a
     * String object is computed as
     * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
     * using int arithmetic, where s[i] is the
     * ith character of the string, n is the length of
     * the string, and ^ indicates exponentiation.
     * (The hash value of the empty string is zero.)
     *
     * @return  a hash code value for this object.
     */
    public int hashCode() {
    int h = hash;
    if (h == 0) {
        int off = offset;
        char val[] = value;
        int len = count;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
    }
    ...
}

"However, it should be noted that this code is improperly synchronized:
    * there is a write in one thread,
    * a read of the same variable by another thread,
    * and the write and read are not ordered by synchronization. 
This situation is an example of a data race (§17.4.5). When code contains a data race, counterintuitive results are often possible."