Create a memory leak given an interface to conform to [duplicate]

Question

This question already has answers here:

How can I create a memory leak in Java? (61 answers)

Closed 12 years ago.

I was asked recently, the following

Given the following interface, write a class that will leak memory every time Processor#doSomething(String) is called and explain why it does so.

public interface Processor {
 void doSomething(String msg);
}

I am not sure there is memory leak in Java in the same sense as C/C++. What is the significance of an interface here.

Also, I have never seen a # used to call a method.

Can someone explain this to me? Thanks

• Code-Apprentice: You should start with the link given above by @Doorknob.
• Matt Ball: # is just a notation. You don't see that in actual Java source code. stackoverflow.com/q/11247793/139010
• rpat: I did see a couple references to memory leak. I was wondering about the interface. What is the significance of an interface?
• Code-Apprentice: # is used in javadocs, not Java source code.

Answer 1

A simple implementation would have a static list and when doSomething is called, just keep adding the input String to the list. The reason why is because you're storing a strong reference (via the static member) to the strings so the strings cannot be garbage collected.

• Polygnome: When you still hold a strong reference then it is not a memry leak. It is only a leak if you do nit longer have any reference but the object will still not get g/ced.
• rpat: That is not the same thing as a memory leak in a C/C++ sense, where your program has no access to the memory you have leaked. Here you do have access to the memory.
• Ernest Friedman-Hill: @polygnome, that's not really correct. Traditional Java usage is that an object that's referenced, but no longer needed, is a leak.
• Ernest Friedman-Hill: @rpat, yes, "leak" does mean something different in Java as compared to C/C++.
• Polygnome: @Ernest Friedman-Hill: I disagree. As long as you have a strong reference, the memory is not leaked. Your object is still reachable, therefore there is no leak. There is only a leak if your object is unreachable from your code but still not g/ced. There is plenty ways of creating such a real leak even in Java, especially, but not only, when native functions are involved.