I have a very simple project . It jush have one controller, use org.springframework.web.client.RestTemplate.postForObject to get info. But head is bigger and bigger, old gen is bigger and bigger。
Comment From: wilkinsona
It sounds like you have a memory leak. We're not aware of one in RestTemplate (which is part of Spring Framework rather than Spring Boot) but it could also be in your application's code or in the underlying HTTP client that you are using.
You should be able to identify the source of the leak using a profiler or heap dump analyser. For example, here's a tutorial on heapdump analysis with Eclipse's memory analyser tool. If this analysis reveals that the problem is in Spring Boot, please comment again explaining why and we can re-open this issue and take another look.
Comment From: shihu19860215
old gen max 1G, if full gc , old gen 100m . It can be full gc, but can't be young gc。 I dump heap. char[] have 444k+ . one kind of char[] has 100k-200k it is be reference by java.net.URL. watch 'jmap -histo 20213 |grep java.net.URL' and gc info young gc can destroy part java.net.URL，but it is bigger and bigger.
Comment From: shihu19860215
springboot versoin updated.from 1.5.4 to 2.1.11. but it still exists
Comment From: philwebb
@shihu19860215 I'm afraid the additional information doesn't help much. It's not clear if you've identified a memory leak in Spring Boot, Spring Framework, A third-party library or your own code. Are you able to recreate the problem in a sample application that you can share?
Comment From: shihu19860215
my project git url:https://github.com/shihu19860215/qding-hk-rest-patrol.git I dump heap. if you need,please left mail.
Comment From: wilkinsona
Thanks for the link to your app. How can we use it to reproduce the problem?
Comment From: shihu19860215
my problem is online with other project. it has many different request online. I don't know how to reproduce offline. but I have dump the heap file. I can email to you. it has quite detailed for java object. please left you email。
Comment From: wilkinsona
My email is awilkinson at pivotal dot io.
Comment From: shihu19860215
the email has bee sent.please check.
Comment From: wilkinsona
I haven't received it, unfortunately. I've checked my junk mail too.
Comment From: shihu19860215
is this email？
Comment From: markbigler
I think the correct email address ends with @pivotal.io instead of @pivotal.dot.io.
Comment From: shihu19860215
I have sent it to the correct email, please check.
Comment From: wilkinsona
Thanks, I've got it. I'm downloading the heap dump now (at 60KB/s…).
Comment From: wilkinsona
I've downloaded the heap dump and looked at it in YourKit. I can't see a problem with java.net.URL. There are 23518 instances in the heap but 98% of them (23031) of them are unreachable from GC roots and, therefore, eligible for garbage collection. Of the whole 669MB heap, over 600MB of it is unreachable and eligible for garbage collection.
Comment From: shihu19860215
It can be full gc,but not be young gc. old generation are bigger and bigger until full, then execute full gc. old generation will be left 100m used. I watch count of java.net.URL Object . it is declined when young gc . on the whole, it is bigger and bigger . if unreachable from GC roots and not be yong gc, it is in old generation. In my submission, such a simple code should not be put into the old generation so quickly
Comment From: wilkinsona
The behaviour of the garbage collector is out of Spring Boot's control. We have no say over when an object is moved from young generation to old generation. It depends on your configuration of the garbage collector and how many collection attempts each instance survives.
At this point I think we've spent as much time on this as we can afford as I can't see any sign of a problem in Spring Boot. I would recommend reviewing your heap and garbage collector configuration. You may find running with -verbose:gc also helps with understanding what is happening and why.