Objekt 2x deserialisieren, aber nur 1x im Heap haben?

[tuxedo]

Hallo zusammen,

ich grüble gerade über der Frage: "Was passiert in der JVM wenn ich ein Objekt 2x deserialisiere? Hab ich's dann 2x im Heap liegen?"

Hintergrund der Frage: Wenn man als Client mit RPC Techniken vom Server ein Object a der Klasse A und Object b der Klasse B anfordert, beide Objekte aber eine gemeinsame Referenz auf Object c der Klasse C haben: Hat man dann "c" doppelt im Heap liegen?

Soweit bin ich schon:

Ich deserialisiere ein und dasselbe Objekt mit zwei verschiedenen ObjectInputStreams. Ergebnis: hashCode und equals sagen: Die zwei Instanzen sind verschieden.

Wenn ich jetzt in der Klasse C sowohl hashCode() als auch equals() überschreibe, dann sind die zwei Instanzen auf einmal gleich (ist ja auch klar, da hashCode und equals an den Eigenschaften des Objekts hängen, und die sind nunmal gleich). Aber hab ich dann das Objekt auch tatsächlich nur 1x im Speicher? Ich nehme an dass "ja", oder ???:L

- Alex

 

[SlaterB]

sowas fragst du mit jahrelanger SIMON-Programmierung?

>Soweit bin ich schon:
> Ich deserialisiere ein und dasselbe Objekt mit zwei verschiedenen ObjectInputStreams. [ohne Überschreiben]

wieso testet du dann nicht auch mit überschriebenen Methoden,
mit == siehst du doch ob es ein Objekt ist oder zwei?!
System.identityHashcode() gibts auch noch

ich kann mir aber nur eine Antwort dazu vorstellen, aber naja, wem nützt meine Vermutung,

also bleibt:
- Hinweis auf Entrüstung dass du das nicht eh weißt
- Hinweis auf Testen (bravo, Erstposter 😉 )
- Hinweis auf Enums, die werden schon nicht verdoppelt

 

[tuxedo]

sowas fragst du mit jahrelanger SIMON-Programmierung?

... und deshalb bin ich automatisch der Spezialist was heap-Speicher und Objekt-Identität abgeht? Aha. Okay. Danke für die Blumen ;-)

>Soweit bin ich schon:
> Ich deserialisiere ein und dasselbe Objekt mit zwei verschiedenen ObjectInputStreams. [ohne Überschreiben]

wieso testet du dann nicht auch mit überschriebenen Methoden,
mit == siehst du doch ob es ein Objekt ist oder zwei?!

Stimmt, da gabs ja noch == ... Manchmal sieht man den Wald vor lauter Bäumen nicht mehr...

System.identityHashcode() gibts auch noch

Danke für den Tipp. Hab von der methode schon gehört, sie aber noch nicht eingesetzt. Aber danke dass du mich dran erinnerst.

ich kann mir aber nur eine Antwort dazu vorstellen, aber naja, wem nützt meine Vermutung,

also bleibt:
- Hinweis auf Entrüstung dass du das nicht eh weißt

Hey, irgendwann ist's immer das erste mal. Es wird dich jetzt noch mehr Entrüsten wenn ich dir sage dass auch ich nicht perfekt bin ;-)

- Hinweis auf Testen (bravo, Erstposter 😉 )

Ja, mit == probier ich's gleich nochmal. Aber ich geh mal davon aus dass das meine Vermutung nur bestätigt (hoffe ich...).

- Hinweis auf Enums, die werden schon nicht verdoppelt

[/quote]

Hmm, wie soll mir hier bei dieser Prinzip-Frage Enum weiterhelfen?

 

[SlaterB]

du sollst kein Experte für Heap sein sondern bei ObjectStreams alles ausprobiert haben, allein schon im Vergleich zum Verhalten dann deiner API,
los, gib es zu 😉

wenn deine Klasse C ein Enum ist, kann sie eine ziemlich komplexe Klasse sein,
von A und B in verschiedenen Streams referenziert werden und wird dann als ein und dasselbe Objekt entpackt, weil es von Enums eben nur je eines gibt,
vielleicht hilft es dir, vielleicht nicht, in jedem Fall ein zum Thema passender interessanter Punkt 😉

'Singleton'
wobei ich gar nicht genau weiß, was passiert, wenn private Attribute zwischen den Übertragungen geändert wurden,
wäre auch auszuprobieren

 

[tuxedo]

So, aktuelles Ergebnis:

Auch wenn man hashCode und equals überschreibt: Mit == sind die beiden, eigenltich identischen Objekte nicht gleich. Ergo: 2x im Heap

Zur Enum-Sache: Ach so, sorum meinst du das.. Hmm, wäre ne Idee und sollte funktionieren.

Singletons übertragen .. puuh, ist so auf den ersten Blick keine gute Idee. Wüsste auch spontan nicht warum man sowas machen sollte. Aber gut, irgend ein mehr oder weniger plausiblen Grund gibt's immer.

...sondern bei ObjectStreams alles ausprobiert haben, allein schon im Vergleich zum Verhalten dann deiner API,

Jein ... Klar macht's Sinn das alles auszuprobieren, aber nur dann wenn Bedarf und Zeit da ist. Und das ist eben jetzt erst der Fall. Aber auch nur zum Teil: Früher hab ich tatsächlich mit durchgängigen Streams agearbeitet. Da hat einem der ObjectStream unterstützt und Übertragungen gecached. Aber mit NIO gibt's keine Streams als solches mehr und die ObjectStream Objekte zum serialisieren und deserialisieren werden entsprechend neu erzeugt und können nix mehr cachen. Ist, abgesehen von NIO, bei RMI übrigens genauso: Da wird auch nix gecached. Die ObjectStreams werden alle entsprechend neu erzeugt.

Mal schauen ob ich da noch was optimieren kann.

- Alex