From: Krist on
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: Peter Duniho on
Krist wrote:
> 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 ?

What memory leak? Java has garbage collection. If an object isn't
reachable, its memory is reclaimed.

It's impossible to know for sure what's going on in your code. You
posted precious little of it. If the "CashInTable" field of each class
is to refer to the same object, that's probably a serious design
problem. But only because of data coherency and code maintenance
issues. It doesn't lead to memory leaks.

(In fact there are others like me who have a strict definition of
"memory leak" that precludes even the possibility of a leak in a GC
system. Your code can "pack-rat" data � that is, retain references to
objects that are actually no longer needed � but a true memory leak,
where some block of memory remains allocated but completely outside of
the program's reach, just isn't possible).

Pete
From: Krist on
Hi Sir,

CashInTable is HashMap object created in CashLookUp class, this is a
JSF backing bean. part of JSF framework.

This code
AdfFacesContext.getCurrentInstance().returnFromDialog(CashInTable,null);
In that class will pass the the HashMap object into the calling page
(then its backing bean take action)

Than the backing bean of the calling page (FormInv) take action.
this.CashInTable =(HashMap)returnEvent.getReturnValue();

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.

Thanks,
Krist



From: John B. Matthews on
In article
<4de22427-62d2-4b3b-8562-be0f3963cbc5(a)t17g2000prg.googlegroups.com>,
Krist <krislioe(a)gmail.com> wrote:

> CashInTable is HashMap object created in CashLookUp class, this is a
> JSF backing bean. part of JSF framework.
>
> This code
> AdfFacesContext.getCurrentInstance().returnFromDialog(CashInTable,null);
> In that class will pass the the HashMap object into the calling page
> (then its backing bean take action)
>
> Than the backing bean of the calling page (FormInv) take action.
> this.CashInTable =(HashMap)returnEvent.getReturnValue();
>
> 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.

I can't tell if your HashMap is retaining references inappropriately, as
Pete outlined above, but this article discusses the problem:

<http://www.ibm.com/developerworks/java/library/j-jtp11225/>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: markspace on
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.

If you are using a local variable, then you are fine. The hash map will
be eligible for garbage collection as soon as the local variable goes
out of scope.