Memory leak caused by de-serialization

Question

i have a memory leak.
i am "pretty" sure it is related to serialization .
for(;;) {
  sok.receive(dgPak);
  ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(dgPak.getData()));
  MyInterface x = (MyInterface) ois.readObject();
  x.go();
  x = null;
  System.gc();
}after the above code loops for 100-200 times, i always get OutOfMemoryError .
important :
public class MyClass implements MyInterface {
  public void go() {
  public void finalize() {
    System.out.println("object disposed. memory released. but, what might be leaking here??");
}in my testing: " *public void go();* " and " *public void finalize();* " execute the same number of times.
so... my guess is allocating memory via " *new* " and de-serialization is different, right?
this must be related to the problem?

Answer 1

i forgot to include one line, but i didn't see why it made a difference:
ConcurrentMap<Connection, Boolean> connPool = this.createConnPool();
for(;;) {
  sok.receive(dgPak);
  ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(dgPak.getData()));
  MyInterface foo = (MyInterface) ois.readObject();
  foo.assignSharedMap(connPool);  // <-- forgot to include this one line.
  foo.doStuff();
  foo = null;
  System.gc();
}the number of de-serializations still equals the number of " +public void finalize();+ " invocations.
note: i never add new connections to the pool. it "looks" like a ConcurrentMap
does not allow objects that reference it to compleley die. (if this behaviour is as to be expected , my apologies, and could you explain a safe way for multiple objects to share a common Collection ?)
this code works fine:
for(;;) {
  sok.receive(dgPak);
  ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(dgPak.getData()));
  MyInterface foo = (MyInterface) ois.readObject();
  foo.doStuff();
  foo = null;
  System.gc();
}at this stage of de-bugging i could have tested with just a regular java.util.Map<Connection, Boolean> but forgot. i am using a
completely different approach now, so i'm not going back to test, though i bet it is related to java.util.concurrent. .