Prev: Mismatch in Statement and PreparedStatement execution in OracleDB.
Next: keyboard hits in a console app
From: Lew on 11 Feb 2010 11:33
Krist wrote:
> Two classes below pass HashMap to each other, I want to avoid the
> memory leak, other than using HashMap.remove(key), how to avoid memory
> leak in my code below ?

Others answered your primary question, so I have just incidental remarks.

> public class FormInv extends PageController {
> private HashMap CashInTable;

Variables should be named with an initial lower-case letter by Java convention.

> public void CashIn_returnAction(ReturnEvent returnEvent) {

Methods should be named with an initial lower-case letter and contain no
underscores by Java convention.

> String vCode = null ;

Variables should be declared in the narrowest scope to which they apply. This
is important to prevent memory "leaks" in Java.

The initialization to 'null' here is useless and should not be done.

> String vNo = null ;
>
> if (returnEvent.getReturnValue()!=null){
> this.CashInTable =(HashMap)returnEvent.getReturnValue();

The only chance of a "leak" here is in the code you chose not to share.

> vCode = (String)this.CashInTable.get("vDocCode");
> vNo = (String)this.CashInTable.get("vDocNo");
>
> // Is this the only way to avoid memory leak with this HashMap ?
> // CashInTable.remove("vDocCode");
> // CashInTable.remove("vDocNo");
> }
> }
> }
>
> public class CashLookUp {
> private HashMap CashInTable;
> public String selectButton_action() {
> JUCtrlValueBindingRef
> tabelCheck=(JUCtrlValueBindingRef)this.getCashInLov_Table().getRowData();
> String docCode =
> (String)tabelCheck.getRow().getAttribute("DocCode");
> String docNo =
> (String)tabelCheck.getRow().getAttribute("DocNo");
> CashInTable= new HashMap();
> CashInTable.put("vDocCode",docCode);
>
> CashInTable.put("vDocNo",docNo);
>
> AdfFacesContext.getCurrentInstance().returnFromDialog(CashInTable,null);

The only chance of a "leak" here is in the code you chose not to share.

> return null;
> }
> }

--
Lew
From: Roedy Green on 11 Feb 2010 17:22
On Thu, 11 Feb 2010 04:01:08 -0800 (PST), Krist <krislioe(a)gmail.com>
wrote, quoted or indirectly quoted someone who said :

>
>This will not be GCed, isn't it ? I read anywhere that unremoved
>HashMap is one of the factor of Java memory leak.

A leak would be a bug in the JVM. I don't know of any outstanding
such bugs, but certainly using an ordinary HashMap will not cause one.

It is hard to understand what you are asking. All I can do is to point
you to some docs to help you understand how memory management works.

see http://mindprod.com/jgloss/garbagecollection.html
http://mindprod.com/jgloss/packratting.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

Every compilable program in a sense works. The problem is with your unrealistic expections on what it will do.
From: Christian on 12 Feb 2010 06:07
Hi!

Sometimes if you need a mapping but don't want to bother cleaning it up
after the Mapped Object becomes obsolete the WeakHashMap might help you.
Though that depends greatly on use...

Christian


Am 11.02.2010 09:32, schrieb Krist:
> Hi all,
>
> Two classes below pass HashMap to each other, I want to avoid the
> memory leak, other than using HashMap.remove(key), how to avoid memory
> leak in my code below ?
>
> FormInv class get return value from a lookup on class CashLookUp,
> these are simplified code.
>
> Thank you for your help,
> Krist
>
>
> public class FormInv extends PageController {
> private HashMap CashInTable;
> public void CashIn_returnAction(ReturnEvent returnEvent) {
> String vCode = null ;
> String vNo = null ;
>
> if (returnEvent.getReturnValue()!=null){
> this.CashInTable =(HashMap)returnEvent.getReturnValue();
> vCode = (String)this.CashInTable.get("vDocCode");
> vNo = (String)this.CashInTable.get("vDocNo");
>
> // Is this the only way to avoid memory leak with this HashMap ?
> // CashInTable.remove("vDocCode");
> // CashInTable.remove("vDocNo");
> }
> }
> }
>
> public class CashLookUp {
> private HashMap CashInTable;
> public String selectButton_action() {
> JUCtrlValueBindingRef
> tabelCheck=(JUCtrlValueBindingRef)this.getCashInLov_Table().getRowData();
> String docCode =
> (String)tabelCheck.getRow().getAttribute("DocCode");
> String docNo =
> (String)tabelCheck.getRow().getAttribute("DocNo");
> CashInTable= new HashMap();
> CashInTable.put("vDocCode",docCode);
>
> CashInTable.put("vDocNo",docNo);
>
> AdfFacesContext.getCurrentInstance().returnFromDialog(CashInTable,null);
> return null;
> }
> }

From: Daniel Pitts on 12 Feb 2010 18:10
On 2/11/2010 8:18 AM, markspace wrote:
> Krist wrote:
>
>> So, both class has local variable with (a coincidence) same name.
>>
>> This will not be GCed, isn't it ? I read anywhere that unremoved
>> HashMap is one of the factor of Java memory leak.
>
>
> If the HashMap becomes unreachable, it will be garbage collected. A
> HashMap only "leaks" when you have a reference to the HashMap you want
> to keep, and you want to remove a reference inside the hash map. In
> fact, I believe this problem only really occurs when you have a
> WeakHashMap, which can accidentally hold on to it's own references.
That makes no sense...
A WeakHashMap uses WeakReferences as entries, which allows the GC to
garbage collect the values referenced. Any object is free to hold a
reference to itself without affecting GC. The only requirement for GC
eligibility is that the object itself isn't accessible through any stack
(directly or indirectly). Reference count is not at all a test.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Steven Simpson on 13 Feb 2010 08:40
On 12/02/10 23:10, Daniel Pitts wrote:
> On 2/11/2010 8:18 AM, markspace wrote:
>> If the HashMap becomes unreachable, it will be garbage collected. A
>> HashMap only "leaks" when you have a reference to the HashMap you want
>> to keep, and you want to remove a reference inside the hash map. In
>> fact, I believe this problem only really occurs when you have a
>> WeakHashMap, which can accidentally hold on to it's own references.
> That makes no sense...

Perhaps he refers to the 'Implementation note' in that class's docs. It
warns that if the value refers to the key, the entry won't be discarded,
even though no-one else is using the key. It's as if the key and value
are keeping each other alive, even though the GC ought to cope with such
loops. But it's the map that's keeping both alive: it holds an entry,
which holds the value, which holds the key, which prevents the map from
discarding the entry.

It's not that the WeakHashMap is causing a 'leak' - a plain HashMap
would surely be at least as bad - but that the user's expectation of WHM
is not met because he hasn't noticed the loop that stops it doing its job.

> A WeakHashMap uses WeakReferences as entries, which allows the GC to
> garbage collect the values referenced.

Strictly speaking, it's only the keys that are held weakly. When they
are discarded, their corresponding entries are removed, which might
result in the values being GCed.

--
ss at comp dot lancs dot ac dot uk

First  |  Prev  | 
Pages: 1 2
Prev: Mismatch in Statement and PreparedStatement execution in OracleDB.
Next: keyboard hits in a console app