Dlaczego blokady są Serializable w java?

Question

Jedno pytanie pojawiło się w moim umyśle podczas rozważania implementacji klasy ReentrantLock. ReentrantLock można przekształcić do postaci szeregowej, aw dokumentacji mówi się, że każda zserializowana blokada jest zawsze odblokowywana niezależnie od stanu, w którym była serializowana. Ma to sens, ponieważ stan Zablokuj i odblokuj jest zasadniczo oparty na wątkach w środowisku wykonawczym (którzy posiadają blokadę) i podczas dekompilacji te wątki mogą być niedostępne.

Pytanie brzmi: Dlaczego potrzebujemy blokady, aby przetrwać, ponieważ nie przechowuje jej podstawowego stanu (zablokowany/odblokowany)? W tej chwili mogę założyć, że może to być właściwość fair zamka. Ale uczciwość jest znowu zależna od systemu operacyjnego, więc jeśli utrzymamy blokadę na jednej platformie i zserializujemy na innej, ponieważ (napisz raz i uciekaj gdziekolwiek) to może nie działać, więc nie ma sensu utrzymywać się tylko dla uczciwości.

Mam nadzieję, że wyraźnie wprowadziłem zamieszanie związane z serializacją zabezpieczeń w Javie.

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

chciałbym powiedzieć, że powód blokady powtarzał jest tak, że jesteś w stanie serializacji obiektów, które zależą od samego Lock. Jeśli Lock nie był możliwy do serializacji, to wszystko zależne od niego nie mogłoby być również serializowane.

Będziesz także mógł przechowywać właściciela, holdCount, queuedThreads i wszystkie inne rzeczy, które możesz zobaczyć na stronie API, którą podałem powyżej dla ReentrantLock.