There are several steps you can use to identify a memory leak.
Start by changing the web service startup options. Add the line -XX:+HeapDumpOnOutOfMemoryError , which will capture a heap dump for you whenever jvm encounters an OOM exception. You can use this information to get a good idea of which objects in memory occupy all available memory. Expecting OOM to replicate, you can see the second set of parameters that you need to add to the launch, the following GC activity logs, -XX:+PrintGCDetails -verbose:gc -Xloggc:/log/path/gc.log . Using this data, you can see if OOM is happening gradually or if it is happening fast.
Another way is to use a program such as VisualVM, which you can use to profile your web service. This will connect to your JVM (preferably in a development environment) and then try to emphasize the test to find where the problem is, try JMeter to help in the stress test. VisualVM is in your JAVA_HOME / bin folder (v6 and above)
This may also be the case when it is not a memory leak, but then expecting more load on the client side is expected. Take a look at setting startup options to provide more memory ( -Xms and -Xmx )
If your client cannot tell you about the parameters that they passed before the problems occurred, you will have to investigate yourself a bit until you find more information.
Daniel already covered jmap in his answer, so I won’t go into this detail