Understanding garbage collection in Java for objects managed by container

问题

Lets say I have a managed bean called A that is @RequestScoped Let's say A has a reference to another managed bean B and B is declared to be @SessionScoped. Will the fact that A has a reference to another bean with longer scope prevent A from getting garbage collected at the end of the HttpRequest?

Will the situation change the other way around ie if B contains a reference to A? if yes then why ?

回答1:

Will the fact that A has a reference to another bean with longer scope prevent A from getting garbage collected at the end of the HttpRequest?

No, an object instance is only eligible for GC if there are no references to it anymore.

A request scoped bean is by default only referenced in the current HTTP request (as a request attribute). So if the HTTP request is finished and get destroyed, then the request scoped bean becomes completely dereferenced and is thus eligible for GC. That the request scoped bean in turn contains a reference to a session scoped bean is totally irrelevant to the GC. Only when the session scoped bean is not referenced anywhere (i.e. when the session has expired, for example), then the session scoped bean becomes in turn also eliglible for GC.

---

Will the situation change the other way around ie if B contains a reference to A? if yes then why ?

Yes, it will change. A session scoped bean is by default only referenced in the HTTP session (as a session attribute), which lives longer than the HTTP request. So the request scoped bean will live as long as the established HTTP session. This will cause potential data integrity problems because you're referencing something which supposedly shouldn't live that long. That's one of the reasons why JSF doesn't allow you injecting a narrower scoped bean in a wider scoped bean by @ManagedProperty.

All with all, the managed bean scope shouldn't be chosen based on GC behavior, but on the data it holds. See also How to choose the right bean scope?

回答2:

No.GC depends only on how many live references are pointing to the object ,not the other way. JVM always maintains a set of references which are alive. Anything that is not reachable from this root set of references is eligible for garbage collection.So even if an object is A is pointing to another object B which is live, if no other object in memory is having reference to A, then A is availabe for GC.

in your case, A's scope is limited to single request.So when the server completes that request processing, A will be available for gc provided there is no memory leak.B will remain in memory since it is having session scope.

回答3:

In your example you have this situation: Request scope references object A, A and Session scope reference object B. When request is ended, it is removed so nothing references object A. It can be garbage collected. After that Session still references object B and it can't collected. According to Java specification:

An object becomes eligible for garbage collection when it becomes unreachable by any code.

This means simple when object is not reachable. In this case A will not be reachable, but B will be.

回答4:

In any case if there is a reference to you'r Object from one of the root Objects (doesnt matter how deep it gets as long as there's a way to get to it from Main() or any other static/singleton/bean what ever) it will not be collected by GC

来源：https://stackoverflow.com/questions/14321142/understanding-garbage-collection-in-java-for-objects-managed-by-container