About the volatile keyword

Question

I am learning about the volatile keyword.
Does it depend on the VM whether the threads do cache its member variables into memory or not even if the volatile keyword is used? Because in my examlpe below the variable "b" is not volatile and it is beeing used in an infinite loop till some other thread change the variable to false. When it happens, the loop stops and I expected that the variable "b" would only be read once since it is not volatile and the loop would never stop.
Could somebody explain? :-)
public class VolatileExample {
    public VolatileExample(){
        T1 t1 = new T1();
        new Thread(t1, "T1").start();
        T2 t2 = new T2(t1);
        new Thread(t2, "T2").start();
    class T1 implements Runnable{
        public boolean b = true; // should be read once if not volatile?
        public T1(){
        public void run() {
            while(b){
                System.out.println("true");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException ex) {
            System.out.println("false");
    class T2 implements Runnable{
        private T1 r;
        public T2(T1 r){
            this.r = r;
        public void run() {
            try {
                Thread.sleep(5000);
                r.b = false; // Here is where I change the other thread´s variable to false
            } catch (InterruptedException ex) {
    public static void main(String[] args){
        new VolatileExample();
}

Answer 1

Roxxor wrote:
Thanks for your answer!
So a rule of thumb would be: "when sharing a variable among different threads, it should be declared volatile"?I wouldn't say that.
An absolute rule, however, is, "When sharing a variable among concurrently executing threads, if at least one of the threads will be writing that variable, and if at least one other thread needs to see the writer's update, then you *must* declare the variable volatile or synchronize all access to it."
That is a bare minimum, of course. By itself, it doesn't guarantee your data will be consistent in a multithreaded context.
I don't use volatile all that often, because all it does is make writes visible, provide a simple memory barrier, and provide atomicity for doubles and longs. Usually there are more complex requirements that lead to needing synchronization or the classes in java.util.concurrent, and then these end up giving me what volatile would have, plus more.