Your program doesn't run long enough to adequately profile. You could solve this by running it a lot of times in a loop. Or by putting a sleep at the end. The sleep approach would only check for a memory leak as proper memory could get returned by then.
You can still run jhat or visualvm or Eclipse Memory Analyzer against a standalone program. You "just" need to get the process id to take a heap dump or launch visualvm against it. THe "just" is in quotes because you need sufficient time to get the heap dump or look at a visual tool before your program ends. Which goes back to my suggestions above.
What do you mean by "the memory stabilizes"? Memory is consistently allocated in both cases, and every so often reclaimed. Naturally, if the code sleeps most of the time, the rate of increase is a lot slower. In fact, in the second case it's so slow that what you're seeing is not the objects that your code allocates, but the objects the JVM allocates in the course of its normal operation (which is so much more that it entirely obscures your data in the graph).
In the first case it's just a matter of time until the JVM exits with an OutOfMemoryException because its memory allocation is exhausted (because the objects your code allocates can't be reclaimed).