91

Here are the facts:

  • the language Go has a garbage collector.

  • Java has a garbage collection

  • a lot of Java programs have (subtle or not) memory leaks

As an example of a Java program that has memory leaks (not for the faint of heart, the question may shake your beliefs), see here about a little Java program called Tomcat that even has a "find leaks" button: Is there a way to avoid undeployment memory leaks in Tomcat?

So I am wondering: will programs written in Go exhibit the same kind of (subtle or not) memory leaks that some programs written in Java exhibit?

Community
  • 1
  • 1
SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • 29
    "a lot of Java programs have (subtle or not) memory leaks" do you have any evidence of this "fact" or is it just a talking point. – Peter Lawrey Dec 09 '10 at 16:11
  • 2
    There is some question about whether failing to release memory that is still reachable constitutes a memory leak. That said, is there *any* OO language that prevents code from accumulating more and more reachable memory? – Andy Thomas Dec 09 '10 at 16:44
  • 3
    Also, your question could be read to suggest that garbage collection is a cause for memory leaks, rather than a curative. – Andy Thomas Dec 09 '10 at 16:46
  • 17
    @Webinator: I think you need to give an example of one of these "subtle memory leaks" that "a lot of" Java programs have. Unless you are claiming a bug in the garbage collector, the only way to leak memory in pure Java is to hold on to references that you are no longer using e.g. by putting objects in a collection and never removing them from that collection. If this is the kind of leak you are referring to, then no language in the world will protect against them, including Go. – JeremyP Dec 09 '10 at 17:05
  • 3
    @Webinator, all the tools prove is there are lot of applications in *development* which have memory leaks. In complex applications, memory leaks are more common but I can say that memory leaks are very rarely an issue in any of the applications I have worked on. (And I have worked on some rubbish applications ;) – Peter Lawrey Dec 09 '10 at 17:06
  • 1
    Voted to close for more or less @Nate's reasoning; question is built on some pretty shaky assertions. – user229044 Dec 10 '10 at 16:24
  • Oh wow, you sneakily manage your memory to get some performance. Welcome to the 70s. No wait, why is this an achievement in 2010? – Matt Joiner Dec 13 '10 at 03:39
  • 14
    Here are the memory leaks I was talking about (+200 upvotes, answers with +150 upvotes, lots of actual Java memory leaks explained): http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java – SyntaxT3rr0r Jul 22 '11 at 11:39
  • 6
    Of course JAVA programs do have memory leaks, just forget to set some reference to null when you dot longer need them. Occurs frequently in large persistant collections (like caches), with observer design pattern or thread local variables. This is not theoretical, I corrected several memory leak myself in production. And this is not anti Java. I'am a full time JAVA dev for moren than 5 years, have been working on lot of different projects. Don't recognising you can have memory leak in JAVA (or all other existing language) is not fanboyism, is more lack of understanding how things really work. – Nicolas Bousquet Jul 22 '11 at 13:50
  • 7
    This question could do without the drama and comments about "fanboyism", "shaking somebody's beliefs" and the like. Esp. since the whole discussion boils down to "my definition of `memory leak` is better than yours". – LAFK 4Monica_banAI_modStrike Oct 04 '17 at 18:49
  • @LAFKsaysReinstateMonica My definition of a memory leak is that the application consume more and more memory over time until at some point it throw an OutOfMemoryException. The same types of actions are done repeatly and work well on a newly started process but consume more or more memory as the application has been running longer. Regardless of the technical specifics, you may still have to correct it anyway. And forgetting to release a pointer or free a collection is the same: you don't free up memory. – Nicolas Bousquet Nov 12 '20 at 19:53

5 Answers5

46

You are confusing different types of memory leaks here.

The heinous, explicit-memory-management based memory leaks are gone in Java (or any other GC based language). These leaks are caused by completely losing access to chunks of memory without marking them as unused.

The "memory leaks" still present in Java and every other language on the face of the planet until the computer can read our minds are still with us, and will be for the foreseeable future. These leaks are caused by the code/programmer keeping references to objects which are technically no longer needed. These are fundamentally logic bugs, and cannot be prevented in any language using current technologies.

james
  • 1,230
  • 9
  • 4
  • 25
    Memory leak is simply when you forget to free up memory. In Java this occurs when you forget to set references to null. In C++ it happen if you forget to call free. Both are valid memory leak cases. And the fundamental problem is the same, you program consume more and more memory until it eventually crash with an OutOfMemory error. – Nicolas Bousquet Jul 22 '11 at 12:03
  • 1
    While it is true that no language can prevent the programmer making such logic errors, it is also true that some such errors exist in the Java SDK itself (see, for example, `java.util.logging.Level` which contains a private static `ArrayList` into which all such objects that are constructed are placed on construction, and from which they are never removed), which makes it harder to avoid them when programming Java than in some other language that does not contain such flaws – Jules Feb 23 '14 at 14:22
  • 7
    I think the OP was asking about memory leaks of objects that really are unreachable like in the accepted answer of the linked question. The memory leak that is cause by class loading from threads. -1 – qbt937 Dec 02 '14 at 20:35
  • 1
    It's also conceivable that static analysis could determine whether references continue to exist past their useful lifespan--no mind-reading required. – Kyle Strand Nov 10 '15 at 22:38
  • "These leaks are caused by the code/programmer keeping references to objects which are technically no longer needed." - Isn't garbage collector created for the same purpose? – Amrit Jan 30 '18 at 13:03
  • 1
    @Amrit No, the garbage collector collects memory you do _not_ have references to anymore. It has no way of knowing if it's OK to remove something which you still have a reference to. – Raphael Schmitz Apr 24 '19 at 09:10
19

It's very possible that Go programs will exhibit memory leaks. The current implementation of Go has a simple mark-and-sweep garbage collector. This is only intended as a temporary solution and is not intended as the long term garbage collector. See this page for more info. Look under the header Go Garbage Collector. That page even has a link to code for the current version if you are so inclined.

Poindexter
  • 2,396
  • 16
  • 19
  • 1
    One of the problems of the mark and sweep collector in Java is memory fragementation. While not technically a memory it can be a loss of memory available to the application. – Peter Lawrey Dec 09 '10 at 17:23
9

A 'memory leak' is when a piece of memory that the programmer thought would be freed isn't freed. This can happen in any language, garbage collected or not. The usual cause in GC languages is retaining an additional reference to the memory.

"Languages don't cause memory leaks, programmers cause memory leaks".

DJClayworth
  • 26,349
  • 9
  • 53
  • 79
8

Garbage collection or not, you can write a program that has memory-leaks in Java, Go, or any other language for the most part.

Garbage Collection does take some of the burden off the programmer but it does not prevent leaks entirely.

jzd
  • 23,473
  • 9
  • 54
  • 76
  • 4
    I know, I know. I'm talking specifically about the kinda subtle memory-leaks that exist in Java even tough Java was, at its beginning, marketed as a *language where memory leaks don't exist thanks to the GC*. – SyntaxT3rr0r Dec 09 '10 at 16:28
  • 4
    Sorry that was not clear. You said "a lot of Java programs have (subtle or not) memory leaks". – jzd Dec 09 '10 at 16:31
3

You are mixing abstraction levels here: the memory leaks are due to bugs in the library (where objects reference each other though chains of 'a holds reference to b' as well as a trade-off in the implementation of the garbage collector between efficiency and accuracy. How much time do you want to spend on finding out such loops? If you spend twice as much, you'll be able to detect loops twice as long.

So the memory leak issue is not programming language specific, there is no reason that by itself GO should be better or worse than Java.

florin
  • 13,986
  • 6
  • 46
  • 47
  • 1
    I don't entirely agree. Memory leaks are due to the fact that Java makes it possible to shoot one-self in the foot and it is not necessarily related to libraries bug. A lot of programmer write programs that slowly but surely leak memory in Java and that is their own fault, not the libraries' fault. Also, if precisely the Java GC is making a time/possible-leak tradeoff, is Go making the same tradeoffs? – SyntaxT3rr0r Dec 09 '10 at 16:10
  • 1
    and the question is really not *"how much time do I want to spend on finding out such loops?"* The question is *"How much time do the specs mandates the Go GC spend on such loops"*, which IMHO is an interesting question. – SyntaxT3rr0r Dec 09 '10 at 16:11
  • 16
    Cyclic reference chains do not prevent garbage collection in Java. – Andy Thomas Dec 09 '10 at 16:31