-
Bug
-
Resolution: Duplicate
-
P4
-
8u131
-
x86
-
other
FULL PRODUCT VERSION :
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.14393]
A DESCRIPTION OF THE PROBLEM :
When a custom subclass of FileSystemView is created and instantiated, the constructor of FileSystemView creates an anonymous inner class of type PropertyChangeListener. This listener is registered in the UIManager.
Since the PropertyChangeListener is an anonymous inner class, it has a synthetic field this$0 referring to the FileSystemView instance. As a result, the FileSystemView cannot be garbage collected.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Create subclass of FileSystemView
- Create a number of FileSystemView instances.
- These FileSystemView instances will never become garbage
ACTUAL -
When creating a custom FileSystemView instance each time a user opens a JFileChooser, eventually the VM runs out of memory.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class WebDAVFileSystemView extends FileSystemView
{
}
public static final void main(String... aParams)
{
int numberOfListeners = UIManager.getPropertyChangeListeners().length;
for (int i = 0; i < 1000; i++)
{
new WebDAVFileSystemView();
}
System.gc();
System.out.println("Leaked " + (UIManager.getPropertyChangeListeners().length - numberOfListeners));
}
---------- END SOURCE ----------
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.14393]
A DESCRIPTION OF THE PROBLEM :
When a custom subclass of FileSystemView is created and instantiated, the constructor of FileSystemView creates an anonymous inner class of type PropertyChangeListener. This listener is registered in the UIManager.
Since the PropertyChangeListener is an anonymous inner class, it has a synthetic field this$0 referring to the FileSystemView instance. As a result, the FileSystemView cannot be garbage collected.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Create subclass of FileSystemView
- Create a number of FileSystemView instances.
- These FileSystemView instances will never become garbage
ACTUAL -
When creating a custom FileSystemView instance each time a user opens a JFileChooser, eventually the VM runs out of memory.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class WebDAVFileSystemView extends FileSystemView
{
}
public static final void main(String... aParams)
{
int numberOfListeners = UIManager.getPropertyChangeListeners().length;
for (int i = 0; i < 1000; i++)
{
new WebDAVFileSystemView();
}
System.gc();
System.out.println("Leaked " + (UIManager.getPropertyChangeListeners().length - numberOfListeners));
}
---------- END SOURCE ----------
- duplicates
-
JDK-8175968 The javax.swing.filechooser.FileSystemView constructor consumes memory by adding a PropertyChangeListener that is never removed
-
- Resolved
-