0

Quite recently i went thru the interview process of Adobe Systems. There is one question they asked to me is :- "there is a J2EE application and there is memory leakage in the that application,and we don't have the source code of application, hereby how could you find the memory leakage"

i was clueless at that time so i said :- "there are many third party tools i.e. there is one which is integrated with eclipse and many more. i don't know the mechanics of those tools."

Still i am searching for answer. Thank You

user0946076422
  • 85
  • 1
  • 12
  • 2
    Having the source code is rarely very useful in finding resource leaks. At least until you've narrowed the location down a lot. – Kayaman Oct 27 '15 at 19:32
  • Possible duplicate of http://stackoverflow.com/questions/40119/how-to-find-a-java-memory-leak – Gaël J Oct 27 '15 at 19:48
  • The J2EE container in question likely has some MBeans that you can access via `jconsole` (or the container console) -- in addition to the suggestions by @Gaël – mustaccio Oct 27 '15 at 20:31

2 Answers2

1

You are right there are many tools like visualvm, jmeter. what they simply do is to hook to running jvm and collect data just like you simply get the Threaddumps with jstat or a heapdump, the tools are just fancy data analyser and provides visualisation, under the hood everything resides on heapdump and threaddump which can tell you the memory leak.

Amey Jadiye
  • 3,066
  • 3
  • 25
  • 38
1

In your JDK folder, look in /bin and find "jvisualvm.exe" (Java VisualVM) and double-click. It will scan the machine processes for anything Java that is currently running and allow you to start monitoring its memory usage (including itself!). The interface is pretty intuitive so you ought to figure out how to use it fast enough.

Nice to see a free utility ship with a free app dev't kit that isn't all but useless... in fact, this one helped me a lot in tracking down places in one large, data-intensive project codebase where I really needed to execute System.gc() at particular times to keep me needing >1 GB of memory. (Contrary to religious belief, running System.gc() is in fact a perfectly reasonable thing to do when you need to free up memory that is needed sooner rather than later.) Previously, I was blowing the heap space at all the wrong times (and there's no right time to do that), but this utility helped me locate the places in my code most guilty of memory-holding so I could stop that from happening.

EDIT: Over 2 years later I want to add as follows. I have not used the cited JVM switches myself for the purpose of tracking down memory leaks but I want to share this info b/c it may help someone else.

At: http://javarevisited.blogspot.com/2011/11/hotspot-jvm-options-java-examples.html

Quote: '8) JVM parameters to trace classloading and unloading -XX:+TraceClassLoading and -XX:+TraceClassUnloading are two JVM options which we use to print logging information whenever classes loads into JVM or unloads from JVM. These JVM flags are extremely useful if you have any memory leak related to classloader and or suspecting that classes are not unloading or garbage collected.'

Matt Campbell
  • 1,967
  • 1
  • 22
  • 34