I agree with Rafi. Memory leaks are not the sort that could be verified with a unit test that runs under a min. You need to run for a reasonably long time to detect trends.
I used to have a nightly cron tasks that runs a producer consumer pair with transactions etc for 10 hours and records memory usage. We also ran a similar test for over a week before to do wrap around testing, but I also recorded memory usage and graphed it. If there is a memory leak it will be visible and we did infact find one issue where we were stuffing stuff into a map that grew very very slowly over time. However this wasn't even visible during the 10 hour run, but was only detected during the week long test. I don't think it's unreasonable run such a test once a release cycle. Once you identify an issue then maybe you could try and write a test that could reproduce it in a short time frame and then analyse using a profiler etc.. But again in order to verify I would still recommend running for at least 10 hrs plus. Just my 2 cents and hope it helps. Rajith On Wed, Jun 30, 2010 at 8:00 AM, Rafael Schloming <[email protected]> wrote: > 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] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
