Memory analysis tools won't tell you when and where an object was created. It will only tell you which objects are in heap. TO find the when and where, you will have to dig into the code and/or add logging yourself
Think of looking at a heap dump like being a detective at a crime scene. Let's say a guy is shot, and you are the detective. By looking at the crime scene, you can see exactly how the guy died, but you can't tell who did it. To find out who did it, you need to collect other pieces of information and put them together to find exactly what happened. Now, it would be very convenient if there was a camera recording the crime when it happened. You can go to the recording and see what happened. Boom. you have your culprit. But, when you don;t have a camera recording, that's whn you have to use your detective skills. You have to talk to people, and try to make a picture of what happened before the shooting.
ANalyzing a memory leak is just like that. By looking a heap dump, you can tell what exactly caused the heap to fill up. It won;t tell you how it happneed. Now, if you had detailed enough logs, then that would be like a camera pointed at the crime scene. You could go through the logs and find exactly where those objects that filled up the heap got created. Not as easy as watching a recording, but doable. If you don't have logs, then you need to piece together other information to find what happened.
You should look at the
pattern used to reproduce the problem, and look at the source code to find where the object is being created.
Fortunately, for us software engineers, finding how to reproduce a problem is like going back in time. If you can reproduce the problem consistently, and you have a good idea of which object is causing the problem, you can add logging and the reproduce the problem again. That's like going back in time, putting a camera on the crime scene and letting the crime happen.