The call scenario of jetty is: in order to support the annotation mode in the Servlet specification (so that it is no longer necessary to describe the deployment of the Servlet in the web.xml file and simplify the development process), jetty will scan the class and lib packages when it starts, register the Servlet and Listener declared in the annotation mode to the jetty container, call inflate when it scans the jar package, and allocate a lot of memory, At this time, search by keyword Memory leak while scanning annotations , this article gives two solutions. One is to disable caching (i.e. jdk1.8):
Here's a link to the java bugs database issue: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8156014
I'd like to be able to comment on it, but I can't seem to find a link to allow me to do that.
The comments I'd like to add are:
the problem is still reproduceable as of jdk8u112
the problem seems to be fixed in jdk9: I tested jdk9ea+149 and couldn't reproduce
I've tried some workarounds for jdk8: it seems the ServiceLoader impl uses the jarurlconnection caching, so it may be of some benefit to try to disable url caching (although not sure of the effects on performance).
Try creating an xml file (eg called "caches.xml") with the following contents:
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Set class="org.eclipse.jetty.util.resource.Resource" name="defaultUseCaches">false</Set>
<New class="java.io.File">
<Arg>
<SystemProperty name="java.io.tmpdir"/>
</Arg>
<Call name="toURI">
<Call id="url" name="toURL">
<Call name="openConnection">
<Set name="defaultUseCaches">false</Set>
</Call>
</Call>
</Call>
</New>
</Configure>
After the attempt, the physical memory occupied by java process has been reduced from 6.5G to 5.9G, which has certain effect, but the estimated java process should occupy about 4.5G, and who has occupied 1.4G memory?
Try another way:
We were investigating a Jetty application that used much more memory than it was supposed to do (near a Gb more than the max heap size plus the max metaspace size). We found out that the extra memory was Native memory, being allocated using malloc via some library (we don't have native code in our app). Then we used jemalloc ( http://www.canonware.com/jemalloc/) to find out which class was doing this allocation and we found out that it was java.util.zip.Inflater. Via jstack we were able to find calls to the library and the main caller was Jetty, while in the process of looking for annotations. We disable annotations for the application and the memory usage went back to normal.
Since the jetty call is to scan the annotations in the jar package and the servlets and listeners that are not declared through the annotations in our application, it is not necessary to scan this step. Therefore, the annotation scanning method is removed in jetty.xml:
<!-- <Item>org.eclipse.jetty.annotations.AnnotationConfiguration</Item> --> <!-- Item>com.xxx.boot.RJRAnnotationConfiguration</Item> -->
After restarting the application, it is found that the memory usage is reduced from 6.5G to 3.9G, and after the application runs stably, it no longer occupies swap,
Source:
http://www.longtask.net/2018/11/15/swap-used-full/#top