Are you saying that you didn’t have these problems with 4.x, or just that it took longer to consume all memory?
From your thread dump, it seems clear that the Chromecast binding was enabled and is at least part of the problem. We have a deadlock:
"OH-safeCall-1" #555 [2819525] prio=5 os_prio=0 cpu=4445,48ms elapsed=21369,30s tid=0x00007fba70014a30 nid=2819525 waiting for monitor entry [0x00007fbb8d6fa000]
java.lang.Thread.State: BLOCKED (on object monitor)
at su.litvak.chromecast.api.v2.ChromeCast.disconnect(ChromeCast.java:170)
- waiting to lock <0x00000000996d14d8> (a su.litvak.chromecast.api.v2.ChromeCast)
at org.openhab.binding.chromecast.internal.handler.ChromecastHandler$Coordinator.destroy(ChromecastHandler.java:264)
The Chromecast binding also uses jmdns internally, so it could potentially be the cause of all the jmdns objects. I haven’t read through all of the stack trace yet, I’ll give more comments if I find more “issues”. But, it would be very helpful if it was possible to capture something similar without the Chromecast binding running, if you still experience problems without it.
The Chromecast binding is a known problem, and myself and @lsiepel are currently trying to go through it and see if we can figure out what’s wrong with it. But, it has been like this for a long time, I concluded that I had to stop using it several years ago, because it made my OH unstable.
We recently did a similar job on the Network binding, which was merged September 7, so it should be in your snapshot version. I’m thus hoping that the Network binding isn’t in use by you, or part of your problem?