Perché i blocchi sono serializzabili in java?

Question

Una domanda è sorta nella mia mente mentre esaminavo l'implementazione della classe ReentrantLock. ReentrantLock è serializzabile e nella documentazione indica che qualsiasi blocco deserializzato è sempre sbloccato a prescindere dallo stato in cui è stato serializzato. Questo ha senso perché lo stato Lock e unlock è fondamentalmente basato sui thread al runtime (che detengono il lock) e mentre noi de-serializziamo quei thread potrebbero non essere disponibili.

La domanda è: Perché abbiamo bisogno del blocco per persistere perché non memorizza lo stato di base (bloccato/sbloccato)? In questo momento posso supporre che possa essere per la proprietà equità della serratura. Ma l'equità è di nuovo dipendente dal sistema operativo sottostante, quindi se persiste il blocco su una piattaforma e deserializzato su un'altra perché (scrivi una volta ed esegui ovunque) potrebbe non funzionare, quindi è inutile insistere solo sull'equità.

Spero di aver messo chiaramente la mia confusione sulla serializzazione di blocco in java.

Answer 1

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html http://download.java.net/jdk7/archive/b123/docs/api/java/util/concurrent/locks/ReentrantLock.html

direi che il motivo per cui persiste blocco è così che siete in grado di serializzare oggetti che dipendono blocco stesso. Se Lock non fosse serializzabile, qualsiasi cosa che dipende da esso non potrebbe essere serializzata.

Si potrebbe anche essere in grado di memorizzare il proprietario, holdCount, queuedThreads e tutte le altre cose che è possibile vedere nella pagina API che ho collegato sopra per ReentrantLock.