I wa reading a post on linked in regarding heap space issues and out of memory issues with java Very well explained but the author missed the point how to actually fix them Increasing heap size is one But if the objects are getting created and java is not releasing them, so how we destroy the object after it’s usage so if it does keep in memory Or kii long a thread if it’s stuck for long I am seeking answers and hopefully someone can explain in good way how we can deal with this in lucee or coldfusion

Every time you create an object, it is created in the Heap. Instantiate 20 objects of the same class - it will use 20x the space in the heap. Let's assume you have created 2 objects : obj1 and obj2. You have 2 "*active references*" and 2 "*reachable*" objects. If you assign obj1 to obj2 (obj1 = obj2;) You now have 2 "*active references*" (still) - but you only have 1 "reachable" object on the heap (obj2) obj1 - no longer has an active reference pointing to it. The garbage collector - releases from the heap the memory consumed by the original obj1 object - as it is no longer required. All this "internal" monitoring and cleaning-up, is performed automatically for you within the JVM. There are command line arguments that you can use to alter the behaviour of the garbage collector. Eg. you can "force" it to do a clean-up more often than the default. SO if you find yourself running out of heap - you CAN make the garbage collector work really often. The gotchya is : The garbage collector is single threaded and causes all other JVM operations to idle - while it is cleaning up. So assume you're cleaning up 2 seconds - and it takes 1 second for the GC to start-up and finish it's work. Your application only has 50% of all available time - to actually do any real work. - so a 50% duty cycle is obviously way too often for GC operations and not nearly enough for your code / application. You CAN also have a machine with more physical memory and allocate more memory to the heap. So you could have a 64GB heap - and tell the garbage collector - my heap is huge - so you don't need to do a cleanup all that often now - in fact do it less often than the default. The potential problem in this scenario - is that if you're now cleanup up a LOT of resources - this takes a lot of time. And again the GC is single-threaded and so your application will "stall" while it is cleaning up many GBs of "unreachable" objects. So it can be "hit and miss" and takes some trial and error - to get the How often the GC clean up occurs and - how much JUNK we let accumulate before we do a clean-up. Each and every version of Java has it's own set of command-line switches. (They could be the same - but they could be quite different - there is no backwards compatibility "promise" about command line switches. I.e. : so when upgrading Check to see if the command line switches you used yesterday in Java 11- are still applicable / have changed any when you upgrade to (say) Java 17. Not withstanding all of that - I would "initially" say that "mostly" (since Java 8 ) : the defaults are pretty effective and "seemingly" get better with every release. Of course it still application dependant - and may well, regardless of the better defaults - still need some tweaking via the command-line arguments to suit your code / application. Sometimes - throwing more RAM at the problem IS the answer.

note: java 17 isn't fully supported yet. if you take a heap dump, you can dive in and try and figure out what objects are being left on the heap that said, it could be a bug in lucee, you didn't mention which version you are using, please always mention the version, if you aren't using the latest release try that, at the moment, I'd suggest trying the latest 5.3.10 snapshot, otherwise you maybe fighting already solved bugs running load testing is also a good way to narrow down what is causing the problem. i,e if you hit your local server with 10000 requests, do you see 10000 objects in the heap dump somewhere