Howdy,
Sure, here's one example:
void someMethod() {
// MyJob implements Runnable
Thread myJobThread = new Thread(new MyJob());
boolean goAhead = evaluateSomeCondition();
if(goAhead) {
myJobThread.start();
} else {
System.out.println("Not running job.");
}
}
Because creating a thread allocates some resources and adds a reference
to the thread in its parent ThreadGroup, when the method is done the
Thread cannot be garbage-collected even though the myJobThread reference
is gone. A simple fix might be to do the thread creation inside the
goAhead clause.
This is only to show it's possible. Obviously this is not an example of
good practice, but it's an easy enough mistake to make ;) The above is
an implementation of an example mentioned on this thread:
http://forum.java.sun.com/thread.jsp?forum=4&thread=456545&message=20839
57. There are others...
Yoav Shapira
Millennium ChemInformatics
>-----Original Message-----
>From: Oscar Carrillo [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, December 17, 2003 2:38 PM
>To: Tomcat Users List
>Subject: RE: Need some Tomcat Configuration help badly
>
>Thanks.
>
>I'm still not sure what kind of code would produce a memory leak. Any
>chance you could give a brief description or example of this?
>
>Thanks,
>Oscar
>http://daydream.stanford.edu/tomcat/install_web_services.html
>
>On Wed, 17 Dec 2003, Shapira, Yoav wrote:
>
>>
>> Howdy,
>>
>> >If I understand this correctly, there are references lying around
that
>> >point to objects that no longer are needed. Is this something the
>> >developer does or something tomcat does in compiling the servlets?
>>
>> This is something the developer does.
>>
>> >In other words, is there something the developer or administrator
can
>> do
>> >to avoid this? Does pre-compiling the jsp files avoid this?
>>
>> Pre-compiling JSP files helps avoid the javac memory leak previously
>> described. The memory leak is just inside the JSPC process, not
inside
>> the tomcat running server.
>>
>> The developer can employ good coding practices as well as good QA
>> practices such as the use of a profiler throughout the lifecycle of
the
>> project to detect and prevent memory leaks.
>>
>> >If you don't change the JSP pages, or class files, then the memory
leak
>> >that is created just happens once. In this scenario, the memory
>> >leak wouldn't keep growing until eventually tomcat does. Is that
>> correct?
>>
>> This is true. In this scenario (one compilation of each JSP in a
>> running tomcat server) you'd have a limited memory leak per JSP. If
you
>> have thousands of JSPs, this can still be a serious leak.
>>
>> Yoav Shapira
>>
>> >
>> >Thanks,
>> >Oscar
>> >http://daydream.stanford.edu/tomcat/install_web_services.html
>> >
>> >On Wed, 17 Dec 2003, Shapira, Yoav wrote:
>> >
>> >>
>> >> Howdy,
>> >> Actually, the popularity and usage of Jikes has been decreasing
(at
>> >> least as measured by downloads). Javac's memory-handling behavior
>> has
>> >> been improved significantly.
>> >>
>> >> The memory leaks described earlier in this thread are not
>> >> compiler-related and simply swapping compilers would not help.
They
>> are
>> >> problems of reference scope.
>> >>
>> >> Yoav Shapira
>> >> Millennium ChemInformatics
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]
>> >> >Sent: Monday, December 15, 2003 1:16 AM
>> >> >To: Tomcat Users List
>> >> >Subject: Re: Need some Tomcat Configuration help badly
>> >> >
>> >> >Dick Steflik wrote:
>> >> >
>> >> >> I had the same question. In all of the years I've worked with
Java
>> >> I've
>> >> >> always thought it was free of memory leaks. If you use a
>> different
>> >> >> compiler does the problem go away. Is that how people like JRun
>> >> >> (Macromedia) and WebSphere (IBM) avoid the problem?
>> >> >
>> >> >It could be. Someone here mentioned using Jikes for Tomcat as a
>> >> workaround
>> >> >(solution). I know that Jikes has bugs, here and there, but it
can
>> be
>> >> made
>> >> >to
>> >> >work and it comes with Tomcat. Considering that "javac" has an
all
>> >> present
>> >> >bug
>> >> >(this memory leak), Jikes is better. I guess commercial solutions
>> use
>> >> their
>> >> >own
>> >> >implementations or fork off to get rid of memory leak.
>> >> >
>> >> >Why does JavaC have that memory leak?
>> >> >
>> >> >Nix.
>> >> >
>> >> >
>> >>
>>
>---------------------------------------------------------------------
>> >> >To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> >> >For additional commands, e-mail:
[EMAIL PROTECTED]
>> >>
>> >>
>> >>
>> >>
>> >> This e-mail, including any attachments, is a confidential business
>> >communication, and may contain information that is confidential,
>> >proprietary and/or privileged. This e-mail is intended only for the
>> >individual(s) to whom it is addressed, and may not be saved, copied,
>> >printed, disclosed or used by anyone else. If you are not the(an)
>> intended
>> >recipient, please immediately delete this e-mail from your computer
>> system
>> >and notify the sender. Thank you.
>> >>
>> >>
>> >>
---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail:
[EMAIL PROTECTED]
>> >>
>> >
>> >
>>
>---------------------------------------------------------------------
>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>> This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged. This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else. If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender. Thank you.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
