[java] perché questa implementazione?

[mad_hhatter]

nell'implementazione della classe java.util.concurrent.CopyOnWriteArrayList

esiste un ReentrantLock globale alla classe.

l'implementazione di un modificatore è fatta così:

public boolean add(E e) {
final ReentrantLock lock = this.lock;
lock.lock();
...
}

domanda: perché viene creato un nuovo riferimento al lock global e non si è scritto semplicemente "this.lock.lock();" ?

grazie in anticipo per le risposte

[PGI-Bis]

E perchè non:

lock.lock();

mi domando io.

Il sospetto cade sul metodo resetLock, che cambia il valore di "lock" tramite un'oscuro Unsafe. Suppongo che lo faccia riflessivamente (tramite setAccessible) o tramite alchimie native.

Crea una copia di quel lock che non dovrebbe mai cambiare perchè in verità può essere cambiato. La copia evita che il blocco avvenga sul monitor A e lo sblocco sul monitor B.

Trattasi comunque di "gran porcata" e il fatto che sia codice di Sun è un'aggravante.

ps.: il metodo resetLock è in fondo a CopyOnWriteArrayList, proprio l'ultimo, ben nascosto.

[andbin]

Il sospetto cade sul metodo resetLock, che cambia il valore di "lock" tramite un'oscuro Unsafe. Suppongo che lo faccia riflessivamente (tramite setAccessible) o tramite alchimie native.Già però guardando bene ho visto che resetLock() viene chiamato solo nel clone() e nel readObject() (deserializzazione).
Quindi a parte la creazione di un CopyOnWriteArrayList tramite clonazione/deserializzazione, potrei dedurre che quella variabile di istanza 'lock' non viene mai più alterata dopo la creazione dell'oggetto.

Cosa poi sia quella classe sun.misc.Unsafe, beh, lo ignoro.

La copia evita che il blocco avvenga sul monitor A e lo sblocco sul monitor B.Mi sembra la spiegazione più logica e plausibile.
Questo però sembrerebbe un controsenso con quanto ho detto sopra: non vedo come sia possibile chiamare uno dei vari metodi (add, ecc...) prima di ottenere un oggetto dalla clonazione/serializzazione.

[PGI-Bis]

Forse un barlume di speranza si può ravvisare nel fatto che "lock" ha accesso package. Allora potremmo pensare che chi ha scritto quella classe abbia pensato al caso in cui un'eventuale sottoclasse nello stesso package voglia accedere a quel lock e ne faccia immondizia tramite lo stesso "Unsafe".

Resta comunque un pessimo modo di usare la lingua. La semantica di final grida "questo non cambierà mai". Là si suppone che possa cambiare. Un qualcosina che non va c'è.