Немного вопросов о многопоточности

Важно, что volatile гарантирует видимость. Изменения volatile-поля в одном потоке будут сразу видны в другом. Если вам нужно потокобезопасно выполнить более сложную процедуру, чем присвоение - воспользуйтесь synchronized или j.u.c.Atomic*-типами, чтобы избежать возникновения гонок (race condition).

Пример: любой многопоточный счетчик

// Плохо 
private volatile long counter;
public long getId() { 
    counter += 1;
    return counter;
}
// Хорошо
private volatile AtomicLong counter = new AtomicLong(0);
public long getId() { 
    return counter.incrementAndGet();
}
// Тоже хорошо
private volatile long counter;
public synchronized long getId() { 
    counter += 1;
    return counter;
}

Помните, что synchronized - это всегда явная блокировка (но она довольно дёшева при низкой конкуренции), а Atomic-примитивы используют бесконечный цикл с CAS-инструкциями и могут хорошо оптимизироваться.

Объекты с неизменяемым состоянием (например, все поля такого объекта final) назвают immutable объектами, и с ними безопасно работать из разных потоков. Но если внутреннее состояние объекта содержит изменяемый какой-то компонент и он как-то может быть доступен снаружи - придется дополнительно думать о потокобезопасности. Пример:

// потокобезопасный класс 
public final class SafeFoo { 
    private final Date date = new Date();
}

// не потокобезопасный класс 
public final class UnsafeFoo { 
    private final Date date = new Date();
    public Date getDate() { return date; }
}

Первый класс полностью потокобезопасен. Второй - нет. Метод getDate() осуществляет публикацию внутреннего состояния внешнему коду (unsafe publication). И где-то снаружи можно сделать так, изменив внутренне состояние:

unsafeFoo.getDate().setHours(0);

Защититься от этого можно, например созданием копии:

// потокобезопасный класс 
public final class SafeAgainFoo { 
    private final Date date = new Date();
    public Date getDate() { return date.clone(); }
}