El siguiente fragmento de código es del bloqueo de doble control de la 2da edición de Effective Java

// Vuelva a comprobar el idioma para la inicialización perezosa de los campos de instancia

private volatile FieldType field;

FieldType getField() {
    FieldType result = field;
    if (result == null) {  // First check (no locking)
        synchronized(this) {
            result = field;
            if (result == null)// Second check (with locking)  
                field = result = computeFieldValue();
        }
    }
    return result;
}

Por lo que sé, el problema principal con el bloqueo de doble comprobación es el reordenamiento dentro del segundo bloqueo de verificación, de modo que la otra hebra pueda ver los valores de campo / resultado como se establece que pueden estar en ejecución. Para evitar esto, hacemos la referencia de campo como volátil para garantizar la visibilidad y el reordenamiento.

Pero esto puede lograrse mediante el siguiente código también

private FieldType field; // non volatile
private volatile boolean fence = false;

FieldType getField() {
    if (field == null) {  // First check (no locking) // no volatile read
        synchronized(this) {   //  inside synch block no problem of visibilty will latest           //value  of field 
            if (field == null) {// Second check (with locking)  
                Object obj =  computeFieldValue();
             fence = true; // any volatile write will take. this will make sure statements are //not reorder with setting field as non null.
            field = (FieldType)obj; // this will be only set after computeFieldValue has been //completed fully
           }
        }
    }
    return field;
}

Por lo tanto, una vez que se haya realizado la inicialización, no habrá subprocesos para la lectura volátil o la sobrecarga de sincronización. Por favor, ver si mis suposiciones son correctas o no?