1

I am new to Java so go easy on me if this is a silly question.

I just got started with Java a few days ago and the first thing I did was build a helper class for MySQL. I am using DriverManager to connect to MySQL and it does so without issue. I also have a helper class to close the ResultSet, Statement and Connection. Here is a snippet of it.

this.result.close();
this.statement.close();
this.connection.close();

I close each object individually as well as setting them to null once finished.

My concern is that in testing, I use Runtime to test memory use throughout my application and closing the above objects and setting them to null seem to have no bearing whatsoever on the memory usage displayed by Runtime. Here is my code for determining memory usage.

System.out.println("Memory Used: " + (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()));

My question is: Why, when I display the memory used while the objects are still in scope as well as at the end of the program the memory appears to never be freed? Is this an issue with the way my objects are being closed, or is the actual memory used not being reflected correctly the way I think it is by Runtime

Kirk Logan
  • 733
  • 2
  • 8
  • 23
  • 1
    It might be as simple as objects in Java are not garbage collected until the jvm deems it necessary, even if you call system.gc(). You might try calling gc() as part of your tests, but that may not do it as well. You might res research when jvm does garbage collection. IIRC there are many factors influencing this. – Joe Oct 22 '16 at 15:31

1 Answers1

1

Setting them to null is unnecessary. The garbage collector knows the scope better than you.

You did well to close them all, but they should be done in individually wrapped try/catch blocks. If the first one throws an exception, you'll never close the others that follow.

You are worrying too much about something isn't likely to matter. It's not certain that the JVM will return the freed memory to the OS, when it will happen, or that your tools will detect it. The important thing is that the garbage collector is doing its job properly.

This method won't kill memory on its own. You're more likely to find problems elsewhere in your code. Keep profiling with Visual VM to find them.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • 'You are worrying too much about something isn't likely to matter.' You really dont think that the memory never being freed by the end of the program is an issue? Like I said, i'm new to Java but I just want to be thorough and start off with good practices. Also thanks for the advice on the individual try/catch blocks, i'll implement that right away! – Kirk Logan Oct 22 '16 at 15:33
  • You don't know that it's not being freed. There's a difference between seeing the used memory go up according to the OS and the freed memory appearing back on the heap. You're new to Java. You're thinking - that's good. I'm telling you that your fears are misplaced. Learn Visual VM - it's bundled with the Oracle/Sun JVM in the /bin folder. You'll learn a lot about your applications by running it. – duffymo Oct 22 '16 at 15:35
  • Sounds like good advice to me, thanks! I'll look into getting started Visual VM today. – Kirk Logan Oct 22 '16 at 15:40
  • 1
    Thanks again for the advice, already gotten some really cool results from VisualVM! I can already see that the objects were indeed eligible for garbage collection, the application simply did not run for enough time for Java to act on it. Trust in the GC I guess. – Kirk Logan Oct 22 '16 at 16:41