Is there any way to find that a specific object is still in the memory or not? For example I have a JFrame called GuiSearch. When I called some method it will be disposed. I want to find is it still in the memory or disposed. I am new to java. Please help me.
Edit: What I want to do is find that the specific object is still in the memory or not and if it is in the memory, I want to call a method and if it is not, call another method.
I assume disposed cleans up resources hidden by the object.
As long as you have a reference to it, the object is still in memory. Depending on what disposed does, you could have an object which is "disposed" and still in be memory as you still have a reference to it.
I am assuming you want to do this for debugging and not via the code. If that's the case, what you want to is dump the heap memory and check it via tools such as Eclipse Memory Analyzer.
This is a bad programming practice and you never do it. To see objects in memory you can use jvisualvm - which comes Sun JDK it self. This provides a visual interface for viewing detailed information about Java application while they are running on a Java Virtual Machine.
Related
I am creating a java program in which my class suppose A has it's some predefined behavior. But user can over-ride my class to change its behavior. So my script will check if there is some subclass than I will call it's behavior but what if he has written some blocking code or memory leak in his code.
This may harm my process. Is there is any way in java to monitor memory allocated by some method.
Please suggest.
but what if he has written some blocking code or memory leek in his
code
First of all i suggest you document your class well. Describe what the user is allowed to do and what not. Give use cases what to do(if possible).
For the blocking code part, if you have some timing issues, you could wrap the execution of the method in say a Future and let a ExecutorService execute the code. That way you will be able to cancel the execution if the execution takes too much time.
For the memory leak issue, well i guess you are not talking about memory leaks but increased memory consumption caused by calling the overridden method. Memory leaks in java are rare after all.
You will not be able to detect the memory consumption of a method, that's not how java works. Memory is global. What will you do if for example an external library is loaded(JNI), or some library in the classpath is called that will use more memory now? You just can not tell.
Other then monitoring the overall memory consumption, there is no other way(someone please tell me if i am wrong).
Oracle has quite a good document about solving memory leaks. It suggests that one should use NetBeans Profiler as a tool.
http://www.oracle.com/technetwork/java/javase/memleaks-137499.html
I believe you can use the same debugging API for checking against misbehaving code while it is running, but that will come with a performance penalty and is probably akin to killing a fly with a sledgehammer. I personally would not let anything like that to run in production. Instead I would rely on rigorous testing and peer review.
For external monitoring, you can use VisualVM or JConsole (part of JDK), for internal you can use the Runtime class:
Runtime rt = Runtime.getRuntime();
long totalMem = rt.totalMemory();
long maxMem = rt.maxMemory();
long freeMem = rt.freeMemory();
Via the Thread class, you can check the status of all threads. Never used it directly, because application servers or batch processing APIs doing their job... So, I don't need to reinvent the wheel. And I suggest to use tools like VisualVM...
EDIT: Watch also this thread: Why do threads share the heap space?
You cannot analyze the heap usage of a single thread. If you have problems with the execution of foreign code, you should sepearate it as good as you can from other threads and analyze the thread or heap dumps. This could be done as mentioned with VisualVM or JConsole which was also added by Oracle (or SUN).
Depending on what sort of behavior that the subclass can do, then we might think of options. For example, if it's a database related operation, we can force them to do connection clean ups, if it's file based, we can force them to read the file through your class and check for how big the file is, if it's any http call or some other streaming functionality, we can look at enforcing constraints accordingly.
If you're just worried about the heap size utilization and memory leaks there, you might want to look at http://java.dzone.com/tips/getting-jvm-heap-size-used which explains how to get runtime memory programatically. But then you'll have to do periodic checks and you can never be sure of whether a memory usage is caused by the subclass behavior.
I just found this while i was trying to build up an agent that records memory allocations:
In the post How to track any object creation in Java since freeMemory() only reports long-lived objects? it is specified that there is an open source project Java Allocation Instrumenter that you could use to register your own callback (it has examples too) and using that you are able to obtain what you need.
I started few days ago to work on a similar project and while researching i found your question and the below post.
I personally needed this kind of code in some unit tests to check if one allocates too many objects inside critical methods and found that using Runtime class was not appropiate because Garbage collector may interfere and the test recorded negative numbers for allocated memory.
How to load existing class objects in JVM from another JVM?
I am analyzing a rare scenario in my server. I do not have proper logs in my sever to help me solve the situation and I believe that it can be a problem with a particular class object (user defined).
Say for example below is the class:
public class MyRequest
{
public byte[] getData()
{
return somdata;
}
}
Currently in my server's JVM, 100's of the above class object is in my JVM's memory. I want to know if there is a possibility to load all the 100 objects and access their data/method (getData()).
I do not want to create an new instance of the MyRequest class (that I know is pretty easy). I want to load the existing objects from my JVM through another Java process.
P.S : I can not kill my server for any reason.
P.S : And I can not install any tools like visualvm etc and more over tools tell us the objects type,memory but not the exact data.
Basically, it won't work.
If you can't attach a debugger, you can't do anything.
If you could attach a debugger, you should be able find and look at those instances, but you won't be able to get them to do something they weren't designed to do. In particular, if they are not designed to be serializable, you won't be able to serialize them.
I think your best bet is to change your server code to improve the logging, and then restart it with a debugger agent ... and wait for the problem to recur.
And of course, if you have a debugger attached, you don't need to move objects to another JVM. You can just look at their state directly.
However, there's a catch. Many "amazingly rare" scenarios are actually related to threading, thread-safety and timing problems. And many things you can do to observe the effects of a such a bug are liable to alter the program's behaviour.
FOLLOWUP
So if we know the starting address of the Virtual memory for that JVM...can we not know the data? assuming all objects are within the JVM memory space.
It is not as simple as that:
Locations of objects on the Java heap are not predictable.
Locations of thread stacks are not predictable.
and so on.
It may be theoretically possible to dump the memory of any process, and reconstruct the execution state of the JVM, and "read" the state of the objects. But you'd need specialized tools and/or a great deal of knowledge of JVM internals to do this. I'm not even sure if the tools exist ...
In short, it is not practical, AFAIK.
Objects and their references (aliases) are bound to the current running JVM. There is no possibility to share them between several JVMs.
If you want to "share" data between two JVMs, you must serialize this data, which means sending them from on JVM to the other. This also requires the classes, whose instances shall be serialized, to implement the interface Serializable. Note, that arrays automatically implement Serializable.
You can either stream those serializable objects yourself using sockets, output and input streams (which is much effort) or you can use RMI for calling remote methods and just stream your data. In either case, all objects are copied and built up again in the other JVM. There is no chance to have them shared.
In case of application servers, RMI calls are typically invoked by just using EJBs. But you need an application server; just using a web server is not enough.
Load existing class objects in JVM from another JVM
Its not possible
Note that you can tell the JVM to dump its state - with a kill signal or similar - to disk so you can use post-Mortem tools to analyze the state of your program.
Keywords are "core" and "hprof" and I have not done this myself yet.
I am using Matlab 2012b to connect to another program (Imaris) from which I import data. The communication actually happens via java as interface. The problem I have is that the data is not deleted from the Java memory and piles up over time until Matlab ultimately crashes.
"clear Java" does not work and produces the following warning: "Objects of Ice/ConnectionRefusedException class exist - not clearing"
The only solution I found to really clear the Java memory is to restart Matlab, which is not an option in my case.
When searching through the web I found that quite a few people have encoutered the same problem. (http://www.mathworks.de/matlabcentral/newsreader/view_thread/283708)
However I did not find an answer how to solve the issue. Does anybody know a solution?
if you are getting messages back from clear java that there are objects of a class that exist, and clear all isn't removing them, then something somewhere has a reference to the object. this can often happen with callbacks, listeners etc, or when you add a reference to an object into an anonymous function handle or the like.
the clear commands remove the reference to the object from the workspace(s), but as the anonymous (or otherwise) reference exists in a callback the object can't be garbage collected so remains in memory (and potentially orphaned)
i see this a lot when i am lazy about writing good destructors
clear java seems to reset the complete Java virtual machine. As a protection to you as a developer, Matlab will not perform this action when you have Java objects in memory which would be destroyed by this action.
Ideally, you can figure out when Matlab item (usually a variable, either in the workspace or some persistent scope) which is an instance of the class Ice/ConnectionRefusedException, and clear it. For variables that you have access to (e.g. in the workspace) you can just run clear variablename, or for variables held as persistents in some other function, you can run clear functionname.
Then try calling clear java again, as you have been doing.
That said, sometimes it is hard to track down the location where the offending object is located. I have been known to restart Matlab as a failsafe restart; of course that doesn't work if you want to work with some recently acquired data.
You can try to call the garbage collector, however there is no guarantee his will actually be executed as you do not call the collector, but raise a request.
Run from matlab command line, or from your m-code (Corrected thanks to comments)
java.lang.System.gc()
You need to set static java. As you do not close matlab. You can only process a dozen of file because permgen space is only 4 MB. Loading ten times of imarislib.jar.
You should add the path to javaaddpath.txt and copy it to prefdir.
Then delete all the lines with javaaddpath in all extensions whether imaris embedded it or you wrote it.
I'm using Tomcat and after stopping my web application there's still a reference to the classloader instance of my web application.
With the consequence that a notable amount of memory (mostly related to static data) will not be freed. Sooner or later this results in an OutOfMemoryError.
I took a heap dump and I realized that its held by a JNI global reference which prevents that the classloader will be garbage collected.
My application does not use JNI. I am also not using the Apache Tomcat Native Library. I am using a Sun/Oracle JDK.
I'd like to track down the cause/origin of this global reference.
(My guess is that the JVM internally references the classloader - but why/where?).
Question:
Which approaches/toolsets exists to achieve this?
UPDATE
It seems that bestsss is right and the JNI global references has been introduced by the jvm debug mode. This helped me out but it does not answer the question so I am still curious to get an answer to the question which might be helpful in the future.
Besides the obvious case: Threads, there is one more:
Are you using your application in debug mode?
The JVM does not hold references to any classloader besides the system one, but it doesn't concern you. The rest of JNI references are either Threads or just debug held objects (provided you don't use JNI and lock the objects down yourself).
JNI references are just roots, edit your answer and post what exactly objects are held by those references.
The first thing i'd do is run with -Xcheck:jni on and see if it comes up with anything. I wouldn't expect it to; it doesn't sound there's anything weird happening with JNI, just incorrect use being made of it. However, it's good to make sure of that.
If you're on a Sun JVM, i think you can do -XX:TraceJNICalls to get an overwhelming listing of JNI calls as they happen. That should let you get an idea of what calls are being made, and from there work towards what is making them, and why this is causing a problem.
JRockit mission control: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/tools/index.html
A nice GUI tool that should help you find it pretty quick.
You could try jstack.
Maybe one of the listed stacktraces will show you the origin of the global reference.
Given a Java Object, how can I get a list of Objects that referring to it?
There must be extension mechanisms in the GC for doing this kind of thing, just can't seem to find them.
I'm not sure if exactly what you're after is simply accessible.
The JPDA (Java Platform Debugger Architecture) enables construction of debuggers, so is a good starting point if you want to delve into the internals. There's a blog on the JPDA that you may also find useful. Check out the Sun Developer Network JPDA page for links to documentation, FAQs, sample code and forums.
Two interfaces that may be good starting points are:
com.sun.jdi.ObjectReference: An instance of java.lang.Class from the target VM
com.sun.jdi.VirtualMachine: A virtual machine targeted for debugging
If you're looking for a memory leak, I find analyzing heap dumps with Eclipse MAT to be very helpful. You can select an object and ask for paths to "GC roots", i.e. show me all chains of references that are keeping this object from being garbage collected.
I don't think there is such a mechanism, and there is no real reason the GC would need one.
It depends a little bit on how you want to use it but if you need it to analyze your memory usage, taking a heapdump and open it in MemoryAnalyzer or JHat will probably give you the information you need. Different ways of taking a heapdump can be found here.
The GC does not support this, though the JDPA APIs do. But I'd be very cautious about doing this kind of thing in a Java application. It is likely to be prohibitively expensive in both time and memory.