Preventing Memory Leak when using HashMap

Discussion in 'Java' started by Krist, Feb 11, 2010.

  1. Krist

    Krist Guest

    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;
    }
    }
    Krist, Feb 11, 2010
    #1
    1. Advertising

  2. Krist

    Krist Guest

    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
    Krist, Feb 11, 2010
    #2
    1. Advertising

  3. In article
    <>,
    Krist <> 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>
    John B. Matthews, Feb 11, 2010
    #3
  4. Krist

    markspace Guest

    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.
    markspace, Feb 11, 2010
    #4
  5. Krist

    Lew Guest

    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
    Lew, Feb 11, 2010
    #5
  6. Krist

    Roedy Green Guest

    On Thu, 11 Feb 2010 04:01:08 -0800 (PST), Krist <>
    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.
    Roedy Green, Feb 11, 2010
    #6
  7. Krist

    Daniel Pitts Guest

    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/>
    Daniel Pitts, Feb 12, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vince Darley
    Replies:
    4
    Views:
    4,386
    emilchacko
    Mar 2, 2010
  2. s.subbarayan

    Dynamic memory allocation and memory leak...

    s.subbarayan, Mar 18, 2005, in forum: C Programming
    Replies:
    10
    Views:
    679
    Eric Sosman
    Mar 22, 2005
  3. Rakesh
    Replies:
    10
    Views:
    12,146
    Mike Schilling
    Apr 8, 2008
  4. cham
    Replies:
    5
    Views:
    756
  5. Mark Probert
    Replies:
    4
    Views:
    317
    Mark Probert
    Feb 9, 2005
Loading...

Share This Page