Develop Reference

JAVA : Why releasing Heap memory not reflecting in Task manager [duplicate]

When the garbage collector runs and releases memory does this memory go back to the OS or is it being kept as part of the process. I was under the strong impression that the memory is never actually released back to OS but kept as part of the memory area/pool to be reused by the same process.
As a result the actual memory of a process would never decrease. An article that reminded me was this and Java’s Runtime is written in C/C++ so I guess the same thing applies?
Update
My question is about Java. I am mentioning C/C++ since I assume the Java’s allocation/deallocation is done by JRE using some form of malloc/delete

The HotSpot JVM does release memory back to the OS, but does so reluctantly since resizing the heap is expensive and it is assumed that if you needed that heap once you'll need it again.
In general shrinking ability and behavior depends on the chosen garbage collector, the JVM version since shrinking capability was often introduced in later versions long after the GC itself was added. Some collectors may also require additional options to be passed to opt into shrinking. And some most likely never will support it, e.g. EpsilonGC.
So if heap shrinking is desired it should be tested for a particular JVM version and GC configuration.
JDK 8 and earlier
There are no explicit options for prompt memory reclamation in these versions but you can make the GC more aggressive in general by setting -XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 which will allow it to spend more CPU time on collecting and constrain the amount of allocated-but-unused heap memory after a GC cycle.
If you're using a concurrent collector you can also set -XX:InitiatingHeapOccupancyPercent=N with N to some low value to let the GC run concurrent collections almost continuously, which will consume even more CPU cycles but shrink the heap sooner. This generally is not a good idea, but on some types of machines with lots of spare CPU cores but short on memory it can make sense.
If you're using G1GC note that it only gained the ability to yield back unused chunks in the middle of the heap with jdk8u20, earlier versions were only able to return chunks at the end of the heap which put significant limits on how much could be reclaimed.
If you're using a collector with a default pause time goal (e.g. CMS or G1) you can also relax that goal to place fewer constraints on the collector, or you can switch go the parallel collector to prioritize footprint over pause times.
To verify that shrinking occurs or to diagnose why a GC decides not to shrink you can use GC Logging with -XX:+PrintAdaptiveSizePolicy may also provide insight, e.g. when the JVM tries to use more memory for the young generation to meet some goals.
JDK 9
Added the -XX:-ShrinkHeapInSteps option which can be be used to apply the shrinking caused by the options mentioned in the previous section more aggressively. Relevant OpenJDK bug.
For logging -XX:+PrintAdaptiveSizePolicy has been replaced with -Xlog:gc+ergo
JDK 12
Introduced the option to enable prompt memory release for G1GC via the G1PeriodicGCInterval (JEP 346), again at the expense of some additional CPU. The JEP also mentions similar features in Shenandoah and the OpenJ9 VM.
JDK 13
Adds similar behavior for ZGC, in this case it is enabled by default. Additionally XXSoftMaxHeapSize can be helpful for some workloads to keep the average heap size below some threshold while still allowing transient spikes.

The JVM does release back memory under some circumstances, but (for performance reasons) this does not happen whenever some memory is garbage collected. It also depends on the JVM, OS, garbage collector etc. You can watch the memory consumption of your app with JConsole, VisualVM or another profiler.
Also see this related bug report

If you use the G1 collector and call System.gc() occasionally (I do it once a minute), Java will reliably shrink the heap and give memory back to the OS.
Since Java 12, G1 does this automatically if the application is idle.
I recommend using these options combined with the above suggestion for a very compact resident process size:
-XX:+UseG1GC -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=10
Been using these options daily for months with a big application (a whole Java-based guest OS) with dynamically loading and unloading classes - and the Java process almost always stays between 400 and 800 MB.

this article here explains how the GC work in Java 7. In a nutshell, there are many different garbage collectors available. Usually the memory is kept for the Java process and only some GCs release it to the system (upon request I think). But, the memory used by the Java process will not grow indefinitely, as there is an upper limit defined by the Xmx option (which is 256m usually, but I think it is OS/machine dependant).

ZGC released in 13 java and it can return unused heap memory to the operating system
Please see the link

What is the use of garbage collector methods in java?

System.gc() or Runtime.gc() if you call there is no guarantee that there will be a garbage collection. Its up to the JVM to perform a GC. Then what is the point in having such methods?

The javadoc for System.gc() and Runtime.gc() is alluding to the fact that it is possible to configure a JVM to ignore calls to those methods; e.g. using the -XX:+DisableExplicitGC JVM option.
However, they are not configured that way by default (at least in current versions of Oracle and OpenJDK Java). So, the calls will do something by default.
Having said that, in most situations it is a bad idea to call the garbage collector directly. They few cases where it is reasonable are mostly covered by the following:
if you are trying to investigate or test behavior of GC sensitive code; e.g. finalizers
if you are trying to avoid a GC pause at an inconvenient point, by running the GC at a point where the user won't notice.
I don't understand what is wrong with giving a guaranteed GC when I request System.gc()?
When you are able to invoke the garbage collector via a gc() call, it typically does a full collection. That is expensive, especially when the amount of non-garbage data is large1. Unfortunately, a lot of Java programmers don't realize this. So, (as I understand it) the primary reason for the JVM option to ignore explicit gc() calls is to mitigate the potentially catastrophic performance effect of programmers abusing the method.
If you do want your System.gc() calls to trigger a GC, the best advice is to make sure that you don't include -XX:+DisableExplicitGC in your JVM options.
Read the Oracle manual entry for the java command for more information.
1 - Most of the runtime cost of a garbage collection is in tracing and copying the graph of objects that are still reachable. If you tell the collector to run before it needs to, you reduce its efficiency. By contrast, the JVM itself knows when the heap is full, or close enough that a collection is warranted. Indeed, it can optimize for two different requirements; maximizing throughput, or minimizing GC pause times.

From the Java 7 docs
public static void gc()
Runs the garbage collector.
Calling the gc
method suggests that the Java Virtual Machine expend effort toward
recycling unused objects in order to make the memory they currently
occupy available for quick reuse. When control returns from the method
call, the Java Virtual Machine has made a best effort to reclaim space
from all discarded objects.
The call System.gc() is effectively equivalent to the call:
Runtime.getRuntime().gc()
So, essentially, it's a suggestion to the GC heuristics that right now is a good time to free some memory. For example, say you're writing a game where the framerate is locked to 60FPS. Each frame has a budget of 16.6 (repeating, of course ;)) milliseconds. Say your frame only takes 5ms to run. Usually, you would wait the remaining time with Thread.sleep. However, you could instead opt to call System.gc() first, to tell the VM "hey, I have some extra time -- feel free to clean up while I wait". Of course, you have no guarantee that the garbage collection will take less than the 11.6MS you have remaining! But if done carefully it can help your memory usage and prevent garbage collection from happening at a bad time. Similar principles apply to other kinds of applications -- basically, if you know that your application will have some downtime, you can let the VM know with System.gc() and hopefully prevent the GC from instead deciding to run in the middle of something important.

These methods are provided if someone wants to take hold of garbage collection(which was valid for old JVMs) but its always wise to leave garbage part on JVM specially Modern JVM implementations have highly optimized garbage collectors. Our jobs has made easy by modren JVM implementations so we have to only focus on java code.

Basically you are right saying there is no guarantee that jvm will actually start gc right after your System.gc() call. However gc can take a note of your willing to make collection now and actually run it.
It depends from jvm, but as far as I know hotspot jvm actually runs gc after System.gc() or Runtime.gc(), at least most of the times.
So I would say that not having at least one way to suggest vm to run gc would have been a mistake. There can be different vm implementations, and what if there is a vm which wants to provide possibility to call gc with guarantee that it would actually run after such call, it wouldn't break specification and it might be usefull for some cases, and as I already mentioned hotspot vm most probably wouldn't ignore this call.

You are correct, gc() calls should not be provided in the first place when there is no use case. I can think of at least one positive and two negative points of using explicit GC calls:
If you are building an application where you have little control of JVM options and want to achieve some God level tuning from within the code, you may use an explicit call. But rest assured, that this is not a magic call to get GC done in scenarios where you suddenly expect low load for a few minutes. You may need to put in a lot of effort to achieve that like estimating responsiveness of GC, amount of memory to be collected, etc.
System.gc() or Runtime.getRuntime().gc() may serve as a reminder or suggestion, but it is completely a prerogative of JVM to do so or not. On the contrary, it might not do anything at all upon seeing such request. Reference: Oracle Java
Having said that, it's usually avoided because GC is something which can be controlled and handled via external JVM options rather than from code itself. For example: -XX:-DisableExplicitGC

Is there a way to schedule a Full Garbage Collection in Java? [duplicate]

This question already has answers here:
How to force garbage collection in Java?
(25 answers)
Closed 9 years ago.
I have an application that's running on a 24x6 schedule. Currently, after running for a few days, a Full GC is performed automatically - and usually during a busy part of the day, which negatively impacts user response times.
What I'd like to do is force a Full GC - perhaps at midnight each night, during very low usage times - to prevent it from happening during the day. I've tried System.gc(), but it doesn't seem to guarantee when a Full GC will happen, or even if it will. Is there some means of doing this?
Version info:
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode)
Additionally -
Minor GCs are running, about every 10-15 seconds. But these are are not freeing up enough RAM to get the app through a full week. When a Full GC does happen, nearly 50% of the heap is freed.
In relation to the above, calling System.gc() doesn't seem to mean that any of the next GCs, will be of the Full form needed to free those large chucks of memory. Yes, it is enabled (or not disabled, depending on how you read the -XX option).
I've already played around with several of the CMS GC settings, which has helped greatly, but not solved the problem. Originally it was throwing OOMs, two to three times a week.
I want to stop the endless loops of:
constantly adding to heap space - which can only go on for so long
constant tuning and testing of GC settings - it is long past the point of diminishing return
I don't want to treat this like an NT machine and bounce it nightly. There are active user sessions throughout the night, and bouncing the app would mean loosing session data.
To be more specific, I'm looking more for a technique to use to ensure that a Full GC is going to happen, rather than a simple method/function to call to run it.
At the moment I'm looking at the modification of the percentage threshold used by CMS to determine when a Full GC is required.
Thanks for any help.

jmap -histo:live <PID> will force Full GC as "side effect" of finding all live objects. You can schedule it to recycle your JVM processes on off-working hours.
Your JVM build 1.6.0_11-b03 is pretty ancient, but jmap should be supported on all 1.6 HotSpot JVMs.

No.
System.gc() suggests to the GC that you would like a collection.
Further, there is probably very little garbage generated during the quiet period and that is why calling System.gc() doesn't do much.
During peak time there is, presumably, more activity and therefore more garbage being generated - hence the need for a collection.
It should be obvious that you cannot defer collection in that simplistic manner. The JVM will collect when it needs to.
You need to look into tuning your GC - if you have stop the world collection happening then you have some issue. This shouldn't really happen on a modern server JVM.
You should look into tuning the CMS collector - this is a pretty good article on the basics of the GC system in Java. In Java 7 there is the new G1GC which may or may not be better.
You should find a way to simulate load conditions and try different GC parameters, the CMS GC has many tuning parameters and configuring it is somewhat of a dark art...
This is a somewhat more involved article on GC tuning and benchmarking.

I'd say yes - schedule a process for your quiet time that does something you believe will trigger a GC.
Eat some serious memory. Allocate a truckload of objects and use weak references to keep track of them - just do something at your quiet time that should trigger a GC.
Do make sure you have in place some logic that detects the GC and stops the process.

There is no way to force and immediate collection as the garbage collector is non-deterministic.

Force hotspot to make frequent GCs?

I am benchmarking a server process, in Java and it appears that Hotspot is not making many GCs, but when it does, its hitting performance massively.
Can I force hotspot to make frequent smaller GCs, rather than a few massive long GCs?

You can try changing the GC to parallel or concurrent.
Here's a link to the documentation.
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Interferring with when the GC is called, is usually a bad idea.
A better approach would be tuning the sizes of eden, survivor and old space if you have problems with performance of the gc.
If a full sweep has to be done it does not really matter how often it was called, the speed will always be relatively slow, the only fast gc calls are those in eden and survivor space.
So increasing eden and survivor space might solve your problem, but unfortunately a good memory profiling is rather time consuming and complex to perform.
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
(link stolen from other answer) also gives the options on how to configure that if necessary. -XX:NewRatio=2 or -XX:NewRatio=3 might increase your speed but it might also slow it up. Unfortunately that is very application dependant.

You can tell the JVM to do a garbage collection programatically by: System.gc(). Please note that the Javadoc says that this is only a suggestion. You can try calling this before getting into a critical section where you don't want the GC performance penalty.

You can increase how often the GC is performed by decreasing the young/new sizes or call gc more often. This doesn't mean you will pause for a less time, just that it will happen mroe often.
The best way to reduce the impact of GC is to memory profile your application and reduce the amount of garbage you are producing. This will not only make your code faster, but reduce how often and for how long each GC occurs.
In the more extreme case, you can reduce how often the GC occurs to less than once per day, removing it as an issue all together.

How can I disable Java garbage collector?

We have a PHP webapp that calls a Java binary to produce a PDF report (with JasperReports). The Java binary outputs the PDF to standard output and exits; the PHP then sends the PDF to browser. This Java command lasts about 3 to 6 seconds, and I think when it lasts 6 second it's because the GC kicks in. I would like to disable the GC because anyway when the command exits all memory is returned.
I would like to know how to disable it for Java 1.4.2 and for Java 1.6.0 because we are currently testing both JVM to see which performs faster..

It sounds like you are trying to save time, but going about it the wrong way. The time saved in disabling garbage collection would be trivial (for a single task) compared to the time taken to launch and shutdown the java process. You might want to consider having a java process launch that you can ask multiple times to do the work you require if run-time performance is your goal.

There is no way to disable garbage collection entirely. Garbage collection is only run when the JVM runs out of space, so you could give the program more memory. Add these command line options to the Java command
-Xmx256M -Xms256M
This gives the program 256Mb of ram (the default is 64Mb). Garbage collection will not take 3 seconds for a default size JVM though, so you might want to investigate more closely what the program is doing. Yourkit profiler is very useful for figuring out what is taking a long time.

GC only kicks in when JVM is short on memory, so you either GC or die. Try turning on verbose GC and see if it actually takes significant amount of time.
java -verbose:gc

Java 11 comes with an no-op garbage collector.
It can be enabled by the -XX:+UseEpsilonGC option at JVM start.
According to the JEP decription one of its goals is to make certain short-lived jobs more efficient, what might be you use case:
Extremely short lived jobs. A short-lived job might rely on exiting quickly to free the resources (e.g. heap memory). In this case, accepting the GC cycle to futilely clean up the heap is a waste of time, because the heap would be freed on exit anyway. Note that the GC cycle might take a while, because it would depend on the amount of live data in the heap, which can be a lot.

Java 11 gives you the binary option to either have Java GC on, or have Java GC turned off. To turn off Java GC you use the Epsilon Garbage Collector which must be turned off on the command line. On Java 11, use the following two JVM arguments:
-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC
Without the UnlockExperimentalVMOptions argument, the JVM will fail to start, so make sure it's included.
Can't Stop Java GC
Unfortunately, if you're not using Epsilon GC, there is no way to disable, stop or prevent garbage collection from happening. Just like not being able to trigger GC, you can't stop Java GC either. The algorithms are non-deterministic. Only the JVM can control when they occur.

You can use the -Xmx option to set the maximum heap size; using a larger heap should prevent the VM from runnning out of memory and, thereby, requiring garbage collection so soon.

Are you sure that it is garbage collection causing the slowdown? Have you run java with -verbose:gc to see what is happening?
You cannot disable garbage collection on the JVM. You could however look at tuning the garbage collector for better performance.

Contrary to what everyone else has said, there is a way to suspend GC, though it's very convoluted.
If you call a native function via JNI, in between the native code calling GetPrimitiveArrayCritical and ReleasePrimitiveArrayCritical, GC is suspended. It has to do this because it is the mechanism used for sharing memory between Java and native code, and GC may move objects around in memory.
So to utilise this you'd need to create a JNI function which calls the former, then polls a flag written to that critical array (which could just be a byte[1]) waiting till it sees the flag before calling the latter. When the Java code wishes to suspend GC it would call the JNI method and when it wishes to resume GC, set the aforementioned flag (I believe reads/writes to the critical array are volatile, so the native code would see the flag immediately).
Now I'm not saying this is a good idea, and certainly not the correct solution to the OP's problem. But if you absolutely had to temporarily suspend GC for some reason (perhaps you wish to manipulate raw memory via sun.misc.Unsafe and needed to ensure objects were not moved about by GC whilst doing so), that's how you could achieve it.

As everyone as said you can't disable GC in the JVM, which makes sense right, because if you could there'd be memory leaks due to java not having an explicit way for the developer to delete the heap data.
Do you have access to the source of this java binary? If so it might be worth analysing it and seeing if there's any bottle-necks which could be better written to cut down on GC activity. This could be done with most java profilers, like JProbe for example.

To avoid garbage collector release a variable or property from any object,
you must set this property (released by gc) as static in your class
it was my solution.
Example:
private static String myProperty;