Emmanuel Bourg wrote:
Le 30/06/2010 09:20, Andrew Kennedy a écrit :
So, what do people think would be the best and simplest way to test this
leak is fixed? Or am I over complicating this for myself before I've had
enough coffee?
I admit I don't remember seeing a unit test for a memory leak. This is
usually verified once by a profiler. I see two approaches to write such
a test:
- generate a heap dump and inspect it
- if the test can get a reference on the object that leaks, the garbage
collection can be verified by a WeakReference combined with a
ReferenceQueue
public void testMemoryLeak() {
Object leakingObject = getLeakingObject();
ReferenceQueue queue = new ReferenceQueue();
WeakReference reference = new WeakReference(leakingObject, queue);
leakingObject = null;
// so some operations supposed to dereference the object
System.gc();
assertTrue(reference.isEnqueued());
}
FWIW, I don't know how portable a test like this would be. According to
the doc, System.gc() only "suggests" that the JVM runs the garbage
collector.
It's probably also not that robust since you wouldn't detect leakage of
any ancillary objects.
I think a targeted stress test is likely to be way more robust for this
sort of thing than a unit test. Of course that's the sort of thing you
don't really want to run once per checkin, more like once (hopefully)
per release.
Perhaps it would be useful to start a suite/category of longer running
"release" tests.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
