7

update: looks like it's not a memory leak, would someone create on based on an extension of this example?
Original question: Suppose I create and starts a thread that does not terminate, the thread creates an object and references as long as it's alive. See the following code. Would the JVM garbage collect x? would this be considered a memory leak?

public class MyRunnable implements Runnable{

    public void run(){
      X x = new X();
      while(true){}
   }
}

Thread t = new Thread(new MyRunnable());
t.start();
user121196
  • 30,032
  • 57
  • 148
  • 198
  • The object `x` is staying alive, and the GC should not destroy it. – Basile Starynkevitch Jan 24 '13 at 10:28
  • 5
    It's not really a memory leak, you've assigned a variable to a thread and have left the thread running, whilst it may be pointless as it does nothing, it is functioning as designed. – codeghost Jan 24 '13 at 10:29
  • I would say no. Because whatever the logic, the object is still in scope and hence not eligible for collection. Leak is when the object is no longer accessible but the memory is held on. In your case, you could have code after your while which could use x. Actually in your case x is just an unused variable. – Ravi Y Jan 24 '13 at 10:31
  • 1
    It is not a memory leak, only a misuse of the language. – assylias Jan 24 '13 at 10:31
  • I tried this code in eclipse... How to kill this thread? – codeMan Jan 24 '13 at 10:32
  • @codeMan, you can't. You will have to kill the process. – Buhake Sindi Jan 24 '13 at 10:33
  • so... close the eclipse? – codeMan Jan 24 '13 at 10:33
  • @codeMan, Pretty much! Kill it through Task Manager (for Windows) or `kill` command in Unix flavour OS. – Buhake Sindi Jan 24 '13 at 10:34
  • yeah thanks! did it through `kill -9` – codeMan Jan 24 '13 at 10:35
  • @codeghost: if memory leak is defined as "objects inaccessible by running code but still stored in memory", so from my main thread I can no longer access object x, and x is never de-allocated, how is this not memory leak? – user121196 Jan 24 '13 at 10:55
  • You could join the thread from main and shut it down, x would be GC'd. – codeghost Jan 24 '13 at 11:01
  • Take a look here http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java. The point everyone answering here has is that in your contrived example, you mean to do what you have done and it can indeed be salvaged. What the linked post describes is a scenario where you're effectively losing track of something unintentionally, but still retaining a reference to prevent deallocation. Memory leaks in Java are actually pretty hard to engineer when you're deliberately trying to, as managed memory comes into it's own. – codeghost Jan 24 '13 at 11:08
  • This is a good, potentially simpler answer as well http://stackoverflow.com/questions/4948529/easiest-way-to-cause-memory-leak-in-java – codeghost Jan 24 '13 at 11:10
  • This is not a memory leak because in this case the object x will stay in memory. A least in this part of code, the memory is not increasing and will not throw OOM error. – UVM May 31 '13 at 04:12

4 Answers4

5

The thread never terminates so the garbage collector will never free x. However if you never really use x it it might be optimized out. If you do use x this can not be a memory leak - you use the memory.

Ivaylo Strandjev
  • 69,226
  • 18
  • 123
  • 176
0

x has method scope and will not be garbage collected until method returns or you explicitly do x = null. And no this will not be considered as leak.

Narendra Pathai
  • 41,187
  • 18
  • 82
  • 120
0

Would jvm garbage collect x?

Nope, Cause thread is still maintains refrence to it.

would this be considered a memory leak?

Not really a leak, but wastage of memory.

Azodious
  • 13,752
  • 1
  • 36
  • 71
0

From Wiki

A memory leak may happen when an object is stored in memory but cannot be accessed by the running code. So

would this be considered a memory leak?

NO this is not a memory leak.

Would jvm garbage collect x ?

NO because thread will never end.

Sumit Singh
  • 15,743
  • 6
  • 59
  • 89