Re: heap memory issue, related with garbage collection
On 11/21/2014 1:49 PM, John wrote:
Thank you for all your replies.
My original post missed some information which now is critical. My program has two buttons besides other buttons: one button is "Next" and one button is "ContinueouslyPlay". When clicking button "ContinueouslyPlay", a child thread is repeatedly calling displayPic() with incremented parameter. The code above works well since all the variables are local - so the thread 'see' the new objects without problem. The problem is out of heap memory when reaching picture 150.(If clicking "Next" button, it is the main thread displaying next picture only - very simple.)
Now, I have changed those variables to class instance variables. Now concurrent programming adds the complexity: in "ContinueouslyPlay" mode, very often the displayed one remain unchanged for quite a bit even though the title is showing the next, next etc picture file names. So the child thread does not 'see' the new stuff. I have added 'volatile' keyword to the instance variables. No help. There is no out of heap memory error any more. But such no displaying is more annoying. Here is the code(I think using a separate thread for "ContinueouslyPlay" mode is reasonable and I don't want to change it. Otherwise all other buttons are not responsive):
public class PictureDisplayer implements ActionListener {
private final JFrame _jFrame;
private final JPanel _jPanel;
private volatile JLabel _picLabel;
private volatile JPanel _picPanel;
There is no need for these to be `volatile', because nothing
ever changes them after the constructor finishes. Far from being
`volatile', they could perfectly well be `final'.
private volatile ImageIcon _imageIcon;
This one can't be `final', but there's also no need for it to
be `volatile'. In fact, there's no need for it to be an instance
variable; it would be better as a local inside displayPic().
..
public PictureDisplayer() throws Exception
{
_jFrame = new JFrame();
_jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
_jFrame.setSize(Constants.MONITOR_WIDTH, Constants.MONITOR_HEIGHT);
_jPanel = new JPanel(new BorderLayout());
//Create the toolbar.
final JToolBar toolBar = new JToolBar("Still draggable");
//Lay out the main panel.
_jPanel.setPreferredSize(new Dimension(Constants.MONITOR_WIDTH, Constants.MONITOR_HEIGHT));
_jPanel.add(toolBar, BorderLayout.PAGE_START);
_picLabel = new JLabel();
_picPanel = new JPanel();
_runThread = new Thread(new Runnable() {
public void run() {
while(true) {
displayPic(++_picCount);
try {
Thread.sleep(10000);
}
catch(final Exception e) {//hopefully never happen
}
}
}
});
If this thread ever executes, your program is thread-broken. As
the Javadoc for javax.swing says,
"All Swing components and related classes, unless otherwise
documented, must be accessed on the event dispatching thread."
Question 1: Is _runThread the event dispatching thread?
Answer 1: No, it is a completely different thread.
Question 2: Does _runThread access Swing components?
Answer 2: Yes, it accesses a JLabel, two JPanels, and a JFrame.
Question 3: Is your program thread-safe?
Answer 3: Not if _runThread runs.
It seems to me that your understanding of thread programming and
of thread-safety issues is not yet well-developed. Your claim that
"all the variables are local - so the thread 'see' the new objects
without problem" is nonsense, and serves as evidence that you don't
know what you're doing. Try studying (or re-studying)
https://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html
Based on what you've shown, I don't know why your program runs
out of memory. Yes, you keep adding the same JLabel to the same
JPanel, adding that JPanel to yet another JPanel, and adding that
second JPanel to the JFrame, over and over and over again. But
after the first time all this adding and re-adding should just be
complicated no-ops; it shouldn't cause memory exhaustion.
However, the fact that you're doing all this stuff on a thread
that is not the EDT means that all bets are off: You cannot count
on Swing to behave as advertised if you use it improperly, as you're
doing. Fix the threading problems, and come back afterwards if you
still have trouble.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM