Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Memory Leak
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory Leak



JavaDoc lists which Swing functions are thread-safe. setText and
replaceSelection are thus marked.

http://java.sun.com/developer/technicalArticles/Threads/swing/

By Monica Pawlan
September 2001
Swing components are not inherently thread safe, and as a general rule,
after Swing components have been made visible on the screen, you can
only safely modify their data from the event thread. If you modify Swing
component data from any thread other than the event dispatching thread,
you must take precautions to ensure data integrity. An exception to this
rule is the setText method on a JTextComponent or any of its subclasses,
or any Swing component method whose documentation explicitly states it
is thread safe.





On 11/9/10 9:00 AM, Nikolas Nikou wrote:
> The proper way is to call swing methods through the event dispatch
> thread.
> so you either
>
> public static void main(String args[]) {
> java.awt.EventQueue.invokeLater(new Runnable() {
>
> public void run() {
> new Memory_Leak();
> }
> });
>
> }
>
> or
>
> for (long i=0; i<100000000; i++) {
> java.awt.EventQueue.invokeLater(new Runnable() {
>
> public void run() {
> label.setText(String.valueOf(i));
> }
> });
> }
> or
>
> java.awt.EventQueue.invokeLater(new Runnable() {
>
> public void run() {
> for (long i=0; i<100000000; i++) {
> label.setText(String.valueOf(i));
> }
> }
> });
>
> depending on how the rest of your application works.
> I would go for the B solution
>
> Στις 9/11/2010 2:36 πμ, ο/η Russ Calvert έγραψε:
>> I've got a strange memory leak that I'm trying to understand and find
>> a way to fix or get around. The problem was first reported by a
>> customer who found that after running for a very long time, my
>> software becomes very slow and unresponsive. This turned out to be
>> due to a slow increase in the amount of memory being used, as shown
>> in Activity Monitor. After much investigation, I've found a simple
>> test case that illustrates the problem. This consists of a JLabel
>> displayed in a JFrame, with the text of the JLabel being very
>> frequently updated:
>>
>>
>> import java.awt.*;
>> import javax.swing.*;
>>
>> public class Memory_Leak extends JFrame {
>>
>> public Memory_Leak() {
>> super("Memory_Leak");
>>
>> JLabel label = new JLabel();
>> label.setPreferredSize(new Dimension(200, 100));
>> getContentPane().add(label, BorderLayout.CENTER);
>> pack();
>> setVisible(true);
>>
>> for (long i=0; i<100000000; i++) {
>> label.setText(String.valueOf(i));
>> }
>> }
>>
>> public static void main(String args[]) {
>> new Memory_Leak();
>> }
>> }
>>
>>
>> When this little program is run (which typically takes several
>> minutes), the real memory consumption as displayed in Activity
>> Monitor slowly grows and grows and grows, by about 3MB in the test
>> I've just run. Monitoring with JConsole shows that both heap and
>> non-heap memory remain roughly constant, but the total number of
>> classes loaded grows linearly with time from about 1,700 to 14,000
>> during execution. This class loading looks odd to me, but maybe it's
>> normal - I don't understand what goes on in the depths of a JVM. I've
>> not bothered trying to analyse heap dumps, as the constant heap size
>> suggests that I would be wasting my time. One other thing I've
>> noticed is that the leak seems to be many times faster with OSX 10.4
>> than OSX 10.5/6.
>>
>> Does anyone understand what's going on here, and/or how I remove the
>> memory leak?
>>
>> Thanks in advance.
>>
>> Russ Calvert
>> AstroGrav Astronomy Software
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Java-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Java-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Memory Leak (From: Russ Calvert <email@hidden>)
 >Re: Memory Leak (From: Nikolas Nikou <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.