Avatar of royjayd
royjayd
 asked on

memory leak: which is better?

hi guys

which is better? case1 or case2. will any of them cause memory leaks?

case1
public class ManagerBusinessService extends BaseBusinessService{//defined globally
//defined globally
private Workflow workflow;
private WorkflowDTO worflowDTO = null;

private WorkflowDao workflowDao;
public void setWorkflowDao(WorkflowDao workflowDao) {
this.workflowDao = workflowDao;
}

public WorkflowDTO fetchDetailsTx(String Id){                   
int workflowId = 0;            
flexworkfloId = getWorkflowNumbers(Id);                  
workflow = workflowDao.loadWorkflowDetailsTx(flexworkfloId);      
worflowDTO = WorkflowDetailAdapter.getInstance().transformDbModelToDTO(workflow);            }
return worflowDTO;
}
...

case2
public class ManagerBusinessService extends BaseBusinessService{
private WorkflowDao workflowDao;
public void setWorkflowDao(WorkflowDao workflowDao) {
this.workflowDao = workflowDao;
      }

      
public WorkflowDTO fetchDetailsTx(String Id){
//defined locally
Workflow workflow;
WorkflowDTO worflowDTO = null;                   
int workflowId = 0;            
flexworkfloId = getWorkflowNumbers(Id);                  
workflow = workflowDao.loadWorkflowDetailsTx(flexworkfloId);      
worflowDTO = WorkflowDetailAdapter.getInstance().transformDbModelToDTO(workflow);      
}
return worflowDTO;
}
...
Java

Avatar of undefined
Last Comment
__geof__

8/22/2022 - Mon
for_yan

If you need some fields only within one method it is better to keep them local to that method.

For many years doing Java programming never encountered any memory leak
in a pure java program.

So I would not worry about it.
Ajay-Singh

To my reading, memory consumption-wise both are same, in case #1, you
are creating "workflow" instance anyway, which is a local variable. case
#2, you have defined a local variable and created anyway.

Now, case #1, might lead to thread-safety issues as workflow variable
is shared.

On memory leak, there is no *object* leak here.
Ajay-Singh

> On memory leak, there is no *object* leak here.

Sorry, just want to correct myself, the first implementation has object
leak, as ManagerBusinessService is global reference which keeps a
instance of workflow. So, there will be one extra object that will not
be reclaimed by GC
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
for_yan

But this is not a memory leak - it will take memory as long as it is needed.
And then memory will be released when it is not needed.
It is not like some C programs which with ceratin bad code or bugs
 may consume more memory with time.
With Java it never happens, so there is no reason to worry about it.
royjayd

ASKER
>>So, there will be one extra object that will not be reclaimed by GC
are you saying
private Workflow workflow;  --this will not be claimed by GC?
private WorkflowDTO worflowDTO = null;  --this will be claimed by GC?

thx
Ajay-Singh

> With Java it never happens, so there is no reason to worry about it.
If that is the case, there should not be any java memory profiler. Java
doesn't have malloc/de-alloc issues, however references are retained if
GC thinks so.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Ajay-Singh

> private Workflow workflow;  --this will not be claimed by GC?
> private WorkflowDTO worflowDTO = null;  --this will be claimed by GC?
Not true. If you set reference to a value, and forget to set it to null,
it will not reclaimed by GC
royjayd

ASKER
Ajay- you said
>>ManagerBusinessService is global reference which keeps a instance of workflow. So, there will be one extra object that will not be reclaimed by GC.

can you elaborate little more and tell me which object will NOT be reclaimed by GC?

thx
royjayd

ASKER
is it the workflow object or the worflowDTO object which will not be collected by GC?
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
SOLUTION
Ajay-Singh

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
SOLUTION
for_yan

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
ASKER CERTIFIED SOLUTION
Mick Barry

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Mick Barry

actually just reread your code and your loading the workflow the same in both.

In which case (based on what you have posted) the second method is better. There is no need for them to be member vars in that code
Mick Barry

On the surface neither would create a memory leak but the first has potential to. for example if WorkflowDao kept a reference to things it had loaded
SOLUTION
msk_apk

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
SOLUTION
__geof__

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.