Replies: 3 comments 1 reply
-
|
This is my personal solution |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @kkkkkhhhh ! Ok, I can see potential problem in unplanned case where for some reason same buffer type is allocated more than once before being returned. I'll create an issue for proper repo ( |
Beta Was this translation helpful? Give feedback.
-
|
Improvement for FasterXML/jackson-core#1186 added. I don't think this alone will resolve the challenge for some usage, as there is no guarantee the oldest buffer is retained (for that more references would need to be retained and that quickly becomes problem of its own). Better approach longer term is for users to configure different to make this happen. |
Beta Was this translation helpful? Give feedback.
-
|
I am very glad to receive your reply and see that the suggestion has been adopted. I will also upgrade to the latest version to experience the changes |
Beta Was this translation helpful? Give feedback.
-
This method BufferRecycler.releaseCharBuffer at the time of release of the buffer not to determine whether a buffer to achieve the maximum length, which leads to even if the buffer to the maximum length will be a new buffer replacement, old buffer into garbage objects.
In projects with high traffic, the old memory grows too fast, causing frequent ogc. Whether this can be considered for optimization
Beta Was this translation helpful? Give feedback.
All reactions