Java Reference
In-Depth Information
This example shows that analyzing heap dumps from
OSG
i applications is similar to
analyzing dumps from everyday Java applications. You've also seen that misbehaving
code can cause memory leaks in
OSG
i as with any other container. But are any leaks
specific to
OSG
i?
8.4
Dangling services
In addition to the everyday leaks Java developers have to be careful of, the
OSG
i frame-
work introduces a new form of memory leak to trap the unwary: dangling services. But
what exactly do we mean by
dangling
?
In section 4.3.1, we discussed why it's a bad idea to access a service instance once
and store it in a field: you don't know when this service is unregistered by the provid-
ing bundle. Your bundle continues to keep a strong reference to the original service
instance and its entire graph of references long after the providing bundle has been
updated or uninstalled (see figure 8.16). You're also keeping alive the class loaders of
any classes used by this instance. As with many memory leaks, you can end up with a
significant amount of space being kept alive by a single field. Clearing this field frees
everything and allows your application to continue running.
Service
registry
Service
object
Field
registerService
getService
Bundle A
Bundle B
Strong reference
Service
object
Field
Bundle A is uninstalled. Bundle B doesn't notice!
Bundle B
Figure 8.16
Classic dangling service
How do you find this one field in the metaphorical haystack that is your application?
8.4.1
Finding a dangling service
In an ideal world, your application won't resemble a haystack! Often, you'll have some
idea where the leak may be, because of the bundles involved. For example, if bundle A
leaks when it's updated, and you know that it's used only by bundles X and Y, you can