Estoy leyendo "concurrencia de Java en la práctica", en un primer momento, que dice:
estado de un objeto comienza con sus campos. Si todos ellos son de tipo primitivo, los campos comprenden todo el estado.
Si el objeto tiene campos que son referencias a otros objetos, su estado abarcará los campos de los objetos referenciados así.
Entonces dice:
estado de un objeto podría ser un subconjunto de los campos en el gráfico de objetos con raíz en ese objeto. ¿Por qué podría ser un subconjunto? ¿En qué condiciones son campos accesible desde un objeto dado que no forma parte del estado de ese objeto?
No puedo encontrar las respuestas a las dos preguntas en el libro.
- ¿Por qué podría ser un subconjunto?
- ¿En qué condiciones son campos accesible desde un objeto dado que no forma parte del estado de ese objeto?
Y estoy totalmente confundido con las dos citas anteriores. Parece contradictorio para mí. ¿Puede alguien dar un ejemplo que puede mostrar "estado de un objeto es un subconjunto de los campos en el gráfico de objetos arraigados en ese objeto" y responder a estas dos preguntas?
Respuesta rápida
A partir de los comentarios, su confusión parece ser:
Creo que el significado es "todos los campos accesible desde la mañana objeto son parte del estado del objeto". No lo es?
No, ese no es el significado. Esto se expresa mediante la pregunta que el autor se pregunta:
¿En qué condiciones son campos accesible desde un objeto dado que no forma parte del estado de ese objeto?
¿Qué es respondida poco después:
Clases de colección a menudo presentan una forma de “propiedad dividida”, en el que la colección posee el estado de la infraestructura de recogida, pero el código de cliente es dueño de los objetos almacenados en la colección
Propietario de la comprensión
Para mayor claridad, la propiedad determina quién puede poner en práctica una política de sincronización para ese estado.
En muchos casos, la propiedad y la encapsulación van de la mano en el objeto encapsula el estado de su propiedad y posee el estado en que encapsula. Es propietario de una variable de estado ya que puede decidir sobre el protocolo de bloqueo utiliza para mantener la integridad del estado de esa variable
Cuando se encapsula estado, los clientes se ven obligados a interactuar con el Estado a través de lo que encapsula. Por lo tanto, el encapsulador es el propietario exclusivo, y el hilo de la seguridad está determinada por el propietario exclusivo.
una vez que se publique una referencia a un objeto mutable, ya no tiene el control exclusivo; en el mejor, es posible que tenga “propiedad compartida”.
Si se expone el objeto (posiblemente a través de un captador), el encapsulador pierde exclusiva propiedad, ya que el cliente puede ahora by-pass cualquier políticas establecidas por el encapsulador.
Sin embargo, esto no cambia el hecho de que el objeto está siendo parcialmente propiedad del encapsulador - el encapsulador puede todavía hacerla cumplir de la política cuando los clientes modifican el estado del objeto a través del encapsulador.
Respuesta para..
¿Por qué puede ser un subconjunto?
Del libro:
Si asigna y rellenar una
HashMap, que está creando múltiples objetos: elHashMapobjeto, una serie deMap.Entryobjetos utilizados por la aplicación deHashMap, y tal vez otros objetos internos así.
A HashMapse compone de potencialmente muchos Map.Entryobjetos, en forma de HashMap#Node.
Desde HashMaptiene control sobre cómo los clientes interactúan con Node(clientes no pueden crear nuevos Nodecasos, sólo a través de métodos tales como HashMap#putValel que determina el estado tal como Node#hash), el estado de Nodeque se considera que es un subconjunto de HashMap.
Respuesta para...
¿En qué condiciones son campos accesible desde un objeto dado que no forma parte del estado de ese objeto?
Del libro:
clases de colección a menudo presentan una forma de “propiedad dividida”, en el que la colección posee el estado de la infraestructura de recogida, pero el código de cliente es dueño de los objetos almacenados en la colección.
Servlets no necesitan utilizar la sincronización al llamar Atributo conjunto- y getAttribute, pero puede tener que utilizar la sincronización cuando se utilizan los objetos almacenados en la ServletContext
Colecciones no tienen control sobre la seguridad de los subprocesos de la misma de los elementos - los clientes pueden tener que poner en práctica su propia sincronización cuando se utilizan elementos recibidos de la colección.
Dado que la colección no tiene control sobre el hilo de seguridad de TI de los elementos, que no posee el estado de la misma de elememts; Estado elementos no es un subconjunto del estado de la colección, sólo la infraestructura es.