There are usually a number of tests which you would like to run for each build to make sure what your code does make sense. Typically, such tests would be focusing on business function of your code.
Though, on a rare occasion, you would really like to test certain non-functional aspects. A memory/resource would be a good example.
How would you test memory leak?
This is quite a challenge, right?
You can use debugger or profiler to inspect internal state of your system. Though, that approach assumes manual testing.
You can write test which would stress your system provoking OutOfMemoryError which would fail your test if code has defect. That generally works, though adding a stress test to mostly functional automatic test pack may not be a best idea. That approach may not work for other kind of resource leaks.
You can exploit weak or phantom reference to trace garbage collector work. This approach makes test more lightweight compared to fully fledged stress testing, but it is not applicable in many cases. E.g. you may not have a reference to leak suspected objects.
For some time I was actively practising automated inspection of JVM heap dumps for diagnostic purposes. JVM could easily produce its own heap dump (using JVM attach interface) and that dump can be inspected via API to assert certain invariants (e.g. number of live instances of particular type). Why not use it for resource leak testing and similar cases?
Resurrecting object from dump
Heap dump API allows you to inspect fields of dumped objects; there is also heap path notation for writing sophisticated selectors. Though, you cannot invoke methods, not even toString() or equals(), on objects from dump. For quantitative analysis of, this is ok. But for asserting complex conditions typical to test scenario, dealing with Java objects may be much more convenient, though.
Heap dump doesn?t contain full class information. But if dump is produced from JVM we are running in we can relay on class metedata available through reflection.
Objenesis library and Java reflection is used to convert instance data from heap dump back to normal Java objects.
At the end, usage of HeapUnit is fairly simple. Using API you can
- take heap dump
- select certain types of instance from dump by class or heap path notation
- inspect instance?s fields using symbolic names
- or rehydrate instance into Java object
Example
Below is a simple example listing Socket objects in JVM
@Test
public void printSockets() throws IOException {
ServerSocket ss = new ServerSocket();
ss.bind(sock(5000));
Socket s1 = new Socket();
Socket s2 = new Socket();
s1.connect(sock(5000));
s2.connect(sock(5000));
ss.close();
s1.close();
// s2 remains unclosed
HeapImage hi = HeapUnit.captureHeap();
for(HeapInstance i: hi.instances(SocketImpl.class)) {
// fd field in SocketImpl class is nullified when socket gets closed
boolean open = i.value("fd") != null;
System.out.println(i.rehydrate() + (open ? " - open" : " - closed"));
}
}
HeapUnit library is available in Maven Central repo. You can bring it to your project using Maven coordinates below.
<dependency>
<groupId>org.gridkit.heapunit</groupId>
<artifactId>heapunit</artifactId>
<version>0.2</version>
</dependency>
Posts
