difference between peak memory and allocated memory?

Thanks, dear for your clarification.
Basically, the root cause of our issue is due to the low memory log generated by our application.

Actually, the current heap size reaches the max heap size which is 4GB.
Our current heap size is similar to the allocated mem size and not equal to the after GC mem size which is 3 GB.
This is the reason why I am asking about the difference between allocated mem and after GC mem knowing that the current heap is always equal to allocated mem and therefore there is no free space that affects our current hep size.

Adding the below screenshot of the scenario I explained above -->

Hello Mohammad!

 Can you share the GCeasy report? on the left top corner of the report, you will see 'Share Report' hyperlink. When you click on it, you will see a URL. Can you paste that URL here? We can diagnose the problem better, when we see the full report. Thanks.

Dear,

Please find it below.

To be noted 4 GB is shown in our was console with 4GB although heap after GC is around 3 GB and we are not sure why the application is not considering that there is free memory although used memory after GC is 3 GB.

https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMDUvMTgvLS1nY19zdGRsb2dnYzAwOC5sb2ctLTctMzctNTU=&channel=WEB

Hello Mohamad!

 Above is your applicaion Heap usage graph. If you notice from Apr' 15 - Apr' 23, heap usage was around 1g. However after that heap usage has been continuing to grow. It never came back to the 1gb size despited Full GC running multiple times. It's a clear indication your application is suffering from an accute memory leak. If it would have been agressive memory leak, your application would have experience OutOfMemoryError very quickly. Since memory leak is very slow, you are facing the current problem. 

 Below is the heap usage graph of an healthy application. You can notice a perfect saw-tooth pattern. When full GC runs, heap usage drops all the way to the bottom. We clearly don't see this pattern in your application.

So  you need to diagnose your memory. 

You can diagnose Memory problem either through a manual or automated approach. 

Manual approach

In the manual approach, you need to capture heap dump as the first step. Heap dump is a snapshot of memory, which shows all the objects in memory, values contained by those objects, and their references. You can capture heap dump using one of the 7 approaches given here. But an important criteria is: You need to capture the heap dump right before OutOfMemoryError is thrown. If you are going to capture a heap dump, after OutOfMemoryError has occurred, then leaking objects can get garbage collected, and it will become hard (or even impossible) to diagnose the problem. Once heap dumps are captured, you need to import the heap dumps from your production servers to your local machine. From your local machine you can use heap dump analysis tools like jHat, HeapHero, Eclipse MAT to analyze the heap dumps. Here is a video tutorial, which may assist you with it.

Automated approach

You can use root cause analysis tools like yCrash - which automatically captures application-level data (thread dump, heap dump, Garbage Collection log) and system-level data (netstat, vmstat, iostat, top, top -H, dmesg,…). Besides capturing the data automatically, it marries these two datasets and generates an instant root cause analysis report. Below is the report generated by the yCrash tool when the above sample program is executed:

Fig: yCrash tool pointing out the root cause of OutOfMemoryError

You can notice the yCrash tool precisely pointing out the root cause of memory leak. You can register here to get a 14 day trial of yCrash.