Calling of finalize() for garbage collection

Garbage collector will call the �finalize()� only once for an object. If any exception thrown while executing the finalize() that causes not to complete the execution of this method.
If this is the case, will the JVM assure that finalize() be called once again on this object.

Finalize is pretty obsolete. The danger is that a finalize method might export a reference to a defunct object, thus making it "reachable" again.
There's no guaranteed way of automatically doing special cleanup in Java, but if you want to do tidying up (e.g. releasing external resources) you should use a PhantomReference with a ReferenceQueue, and dedicate a thread to doing the cleanup.

Similar Messages

API for Garbage Collection

We are using WLS 6.1 SP3 on a Solaris machine. Is there any API we can use to
automate garbage collection instead of manually doing through the Admin Console.
Thanks in advance.

I can't answer or help with all of those… Here are my thoughts… The dollar object properties and functions can be called on by script from AI, BR, ID & PS… They are NOT restricted for use in the ESTK tookit. Yeah $.writeln() would write to the console if the toolkit were open if NOT then it will probably launch it… So remove or comment these out. As you can see from $.sleep() it does what it says when run in the host app. #targetengine is exclusive to ID this app can have multi-instances ( or something like that ). The other apps have 1 engine and thats it. AI's engine is persistent so wrapping your code is good practice I do this for BR & PS too… See…
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/illustrator/scrip ting/readme_cs5.txt
As for garbage collection I've never fould the need to use it… I see some like to set variables back to null but again I don't do this…
You would have been better off asking this question in the ID scripting forum… There are several people there who are better qualified to answer some of this…

Elligible for Garbage Collection

If an object is unreferenced, but it does not declare a finalize() method, then is this object elligible to be finalized and freed by Gc?
Regards
JS

Thanks for the prompt reply.
JVM Specification says an object can be garbage collected when it is unreferenced.Thus that mean that setting an object to null can not make it elligible since some other objects may still refer the object in question?
JS

High cpu usage for garbage collection (uptime vs total gc time)

Hi Team,
We have a very high cpu usage issue in the production.
When we restart the server, the cpu idle time would be around 95% and it comes down as days goes by. Today idle cpu is 30% and it is just 6th day after the server restart.
Environemnt details:
Jrockit version:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-linux-ia32, Native Threads, GC strategy: parallel)
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep
Number Of Processors: 4
Max Heap Size: 1073741824
Total Garbage Collection Time: 21:43:56.5
Uptime: 114:33:4.1
Total Garbage Collection Count: 420872
Total Number Of Threads: 198
Number Of Daemon Threads: 191
Can you guys please tell me what would be problem in the server which causing the high cpu usage?
One more thing I would like to know is that why the total number of threads is 198 when we specified the Executor pool size as 25? I agree that weblogic would create some threads for its maintenance but around 160 threads!!! something is wrong I guess.
Santhosh.
[email protected]

Hi,
I'm having a similar problem, but haven't been able to resolve it yet. Troubleshooting is made even harder by the fact that this is only happening on our production server, and I've been unable to reproduce it in the lab.
I'll post whatever findings I have and hopefully we'll be able to find a solution with the help of BEA engineers.
In my case, I have a stand-alone Tomcat server that runs fine for about 1-2 days, and then the JVM suddenly starts using more CPU, and as a result, the server load shoots up (normal CPU utilization is ~5% but eventually goes up to ~95%; load goes from 0.1 to 4+).
What I have found so far is that this corresponds to increased GC activity.
Let me list my environment specs before I proceed, though:
CPU: Dual Xeon 3.06GHz
RAM: 2GB
OS: RHEL4.4 (2.6.9-42.0.2.ELsmp)
JVM build 1.5.0_03-b07 (BEA JRockit(R) (build dra-45238-20050523-2008-linux-ia32, R25.2.0-28))
Tomcat version 5.5.12
JAVA_OPTS="-Xms768m -Xmx768m -XXtlasize16k -XXlargeobjectlimit16k -Xverbose:memory,cpuinfo -Xverboselog:/var/log/tomcat5/jvm.log -Xverbosetimestamp"
Here are excerpts from my verbose log (I'm getting some HT warning, not sure if that's a problem):
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Detected SMP with 2 CPUs that support HT.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to determine if HT is enabled.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] HT is: supported by the CPU, not enabled by the OS, enabled in JRockit.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: HT enabled even though OS does not seem to support it.
[Fri Oct 20 15:54:55 2006][22855][memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
[Fri Oct 20 15:54:55 2006][22855][memory ] heap size: 786432K, maximal heap size: 786432K
[Fri Oct 20 16:07:30 2006][22855][memory ] Changing GC strategy to generational, parallel mark and parallel sweep
[Fri Oct 20 16:07:30 2006][22855][memory ] 791.642-791.874: GC 786432K->266892K (786432K), 232.000 ms
[Fri Oct 20 16:08:02 2006][22855][memory ] 824.122: nursery GC 291998K->274164K (786432K), 175.873 ms
[Fri Oct 20 16:09:51 2006][22855][memory ] 932.526: nursery GC 299321K->281775K (786432K), 110.879 ms
[Fri Oct 20 16:10:24 2006][22855][memory ] 965.844: nursery GC 308151K->292222K (786432K), 174.609 ms
[Fri Oct 20 16:11:54 2006][22855][memory ] 1056.368: nursery GC 314718K->300068K (786432K), 66.032 ms
[Sat Oct 21 23:21:09 2006][22855][memory ] 113210.427: nursery GC 734274K->676137K (786432K), 188.985 ms
[Sat Oct 21 23:30:41 2006][22855][memory ] 113783.140: nursery GC 766601K->708592K (786432K), 96.007 ms
[Sat Oct 21 23:36:15 2006][22855][memory ] 114116.332-114116.576: GC 756832K->86835K (786432K), 243.333 ms
[Sat Oct 21 23:48:20 2006][22855][memory ] 114841.653: nursery GC 182299K->122396K (786432K), 175.252 ms
[Sat Oct 21 23:48:52 2006][22855][memory ] 114873.851: nursery GC 195060K->130483K (786432K), 142.122 ms
[Sun Oct 22 00:01:31 2006][22855][memory ] 115632.706: nursery GC 224096K->166618K (786432K), 327.264 ms
[Sun Oct 22 00:16:37 2006][22855][memory ] 116539.368: nursery GC 246564K->186328K (786432K), 173.888 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117122.577: nursery GC 279056K->221543K (786432K), 170.367 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117123.041: nursery GC 290439K->225833K (786432K), 69.170 ms
[Sun Oct 22 00:29:10 2006][22855][memory ] 117291.795: nursery GC 298947K->238083K (786432K), 207.200 ms
[Sun Oct 22 00:39:05 2006][22855][memory ] 117886.478: nursery GC 326956K->263441K (786432K), 87.009 ms
[Sun Oct 22 00:55:22 2006][22855][memory ] 118863.947: nursery GC 357229K->298971K (786432K), 246.643 ms
[Sun Oct 22 01:08:17 2006][22855][memory ] 119638.750: nursery GC 381744K->322332K (786432K), 147.996 ms
[Sun Oct 22 01:11:22 2006][22855][memory ] 119824.249: nursery GC 398678K->336478K (786432K), 93.046 ms
[Sun Oct 22 01:21:35 2006][22855][memory ] 120436.740: nursery GC 409150K->345186K (786432K), 81.304 ms
[Sun Oct 22 01:21:38 2006][22855][memory ] 120439.582: nursery GC 409986K->345832K (786432K), 153.534 ms
[Sun Oct 22 01:21:42 2006][22855][memory ] 120443.544: nursery GC 410632K->346473K (786432K), 121.371 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.508: nursery GC 411273K->347591K (786432K), 60.688 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.623: nursery GC 412391K->347785K (786432K), 68.935 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.576: nursery GC 412585K->348897K (786432K), 152.333 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.783: nursery GC 413697K->349080K (786432K), 70.456 ms
[Sun Oct 22 01:34:16 2006][22855][memory ] 121197.612: nursery GC 437378K->383392K (786432K), 165.771 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.496: nursery GC 469709K->409076K (786432K), 78.257 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.730: nursery GC 502490K->437713K (786432K), 65.747 ms
[Sun Oct 22 01:44:03 2006][22855][memory ] 121785.259: nursery GC 536605K->478156K (786432K), 132.293 ms
[Sun Oct 22 01:44:04 2006][22855][memory ] 121785.603: nursery GC 568408K->503635K (786432K), 71.751 ms
[Sun Oct 22 01:50:39 2006][22855][memory ] 122180.985: nursery GC 591332K->530811K (786432K), 131.831 ms
[Sun Oct 22 02:13:52 2006][22855][memory ] 123573.719: nursery GC 655566K->595257K (786432K), 117.311 ms
[Sun Oct 22 02:36:04 2006][22855][memory ] 124905.507: nursery GC 688896K->632129K (786432K), 346.990 ms
[Sun Oct 22 02:50:24 2006][22855][memory ] 125765.715-125765.904: GC 786032K->143954K (786432K), 189.000 ms
[Sun Oct 22 02:50:26 2006][22855][memory ] 125767.535-125767.761: GC 723232K->70948K (786432K), 225.000 ms
vvvvv
[Sun Oct 22 02:50:27 2006][22855][memory ] 125768.751-125768.817: GC 712032K->71390K (786432K), 64.919 ms
[Sun Oct 22 02:50:28 2006][22855][memory ] 125769.516-125769.698: GC 711632K->61175K (786432K), 182.000 ms
[Sun Oct 22 02:50:29 2006][22855][memory ] 125770.753-125770.880: GC 709632K->81558K (786432K), 126.000 ms
[Sun Oct 22 02:50:30 2006][22855][memory ] 125771.699-125771.878: GC 708432K->61368K (786432K), 179.000 ms
So, I'm running with the default GC strategy which lets the GC pick the most suitable approach (single space or generational). It seems to switch to generational almost immediately and runs well - most GC runs are in the nursery, and only once in a while it goes through the older space.
Now, if you look at [Sun Oct 22 02:50:27 2006], that's when everything changes. GC starts running every second (later on it's running 3 times a second) doing huge sweeps. It never goes through the nursery again, although the strategy is still generational.
It's all downhill from this point on, and it's a matter of hours (maybe a day) before we restart the server.
I guess my only question is: What would cause such GC behavior?
I would appreciate your ideas/comments!
Thanks,
Tenyo

Which algirithm is being used by java runtime for garbage collection??

On what basis does java reclaim objects using Garbage Collection ??
and explain the method i.e the step by step basis on how it is being done??

There are various whitepapers and the like on this.
As far as which objects may be collected, it's just any object that isn't referred to - directly or indirectly - by one of the root set of threads in the JVM.
Collecting algorithms vary from jvm to jvm. You'd do better to search the web for a whitepaper on the subject.
~Cheers

When will the demo object be eleigible for garbage collection?

class Test {
     private Demo d;
     void start() {
     d = new Demo();
     this.takeDemo(d);
     void takeDemo(Demo demo) {
     demo = null;
     demo = new Demo();
     }

Hey flounder, I am myself confused about garbage collection and assertions (yesterday)... Anyway because of ur interest in answering my query, I'll give one more try... But, if it's wrong, Please help me out.
The Demo (not demo) object created at line 4 has one 'this' reference on the next line. And as soon as this reference is eleigible, I guess even Demo d will be eligible. Correct?

Need for garbage collection using Webdynpro Binary Cache?

Dear Sirs,
I am using the Wiki guide, Exporting Table Data Using On-Demand Streams to export table data to Excel. (this is using Webdynpro binary cache)
Everything is working fine, however I would like to check prior to transport to production, if i need to do any garbage collection using this solution.
My biggest fear is if the all the excel files generated are stored forever, thus filling up the disk space or memory and crashing the production server.
Can anyone give me advice ?
best regards,
Jørgen Ruud

<b>Hi
Check This URL
Memory Usage
http://help.sap.com/saphelp_nw04/helpdata/en/98/f73c41325fa831e10000000a1550b0/frameset.htm
Resource Management
http://help.sap.com/saphelp_nw04/helpdata/en/15/d73f41d900db2be10000000a1550b0/frameset.htm
Regards
Chandran S</b>

Is this object available for garbage collection

public class MyClass {
public static void main(String args []){
new MyClass().myFunc();
//Because I don't assign this reference to a variable, is it available for collection at this point?
public void myFunc(){ }
Thanks ..... Jimmy

What do you mean "in most cases"? I assume you don't
mean that most methods in any java program should be
static, Of course not... please actually read the context of my post. "in most cases" where the code is similar to what the OP posted, a static method would probably be appropriate. In code where you are creating a new instance of a class for the sole purpose of calling a method and not retaining a reference to it, it should probably be a static method. Look at the OP's code:
public class MyClass {
public static void main(String args []){
new MyClass().myFunc();
public void myFunc(){
}Notice that the OP does not keep a reference to the object, simply calling a method and leaving it at that. I am saying that in this situation, it would probably be more appropriate to do the following:
public class MyClass {
public static void main(String args []){
MyClass().myFunc();
public static void myFunc(){
}I imagine that there are situations where the OP's original design may be useful, but in most situations, a static method is appropriate.
This isn't that complicated... I see no need to get into an argument over it. Please don't just attempt to make me look like a fool (I do a fine job of that on my own).

Local ref garbage collection within "nested" JNI calls

I am using a JVM started in C++ to make calls to java classes. The C++ code makes JNI call into the JVM which instantiates a java class. The java class, in the course of execution, makes other JNI calls. All this happens on one thread of execution.
What I am seeing is that local references from the native methods being called by the java class are not being released until the initial C++ native call exits. The JNI spec (text included below) seems to indicate there is registry of "nonmovable local references to Java objects" which "keeps the objects from being garbage collected". Is there only one such registry which does not get deleted until the initial C++ native call exits? If so, this would explain what I am seeing. How do I get around it?
Thanks,
Iztok
From the JNI spec:
"To implement local references, the Java VM creates a registry for each
transition of control from Java to a native method. A registry maps nonmovable local references to Java objects, and keeps the objects from being garbage collected. All Java objects passed to the native method (including those that are returned as the results of JNI function calls) are automatically added to the registry. The registry is deleted after the native method returns, allowing all of its entries to be garbage collected."

When I say "initial" I mean the initial C++ JNI call into a JVM running in a C++ process as shown in the pseudo code below. initNativeFunc() makes a call to Foo.doSomething() function which calls nativeFunc2 (another native function). Only a local reference to Retval was created in nativeFunct2, so when nativeFunct2 returns and the Retval is no longer used in Foo it should be a candidate for garbage collection. But this is not what happens. The Retval from nativeFunc2 is not being cleaned up until Foo.doSomething() returns. If I make the loop in Foo.doSomething() long enough, NewDoubleArray() returns a NULL when it runs out of memory.
void initNativeFunc() {
jclass clazz = env->FindClass("Foo");
jmethodID mid = env->GetMethodID(clazz, "doSomething", "()V");
env->CallVoidMethod(clazz, mid, ...);
JNIEXPORT jobject JNICALL nativeFunc2() {
jclass clazz = env->FindClass("Retval");
jmethodID mid = env->GetMethodID("Retval, "<init>", "()V");
jobject retval= env->NewObject(clazz, mid);
jdoubleArray da = env->NewDoubleArray(100000);
jfieldID fid = ...
env->SetObjectField(retval, fid, da);
return retval;
public class Foo {
public native void nativeFunc2();
public void doSomething() {
for (int i = 0; i < 100; i++) {
Retval retval = nativeFunc2();
}

Garbage Collection: how many objects are created after for loop?

Please see the fallowing java code
1 public class Test1 {
2
3     public static void main(String[] args) {
4
5          MyObj obj = null;
6          for(int i=0;i<5;i++){
7               obj = new MyObj();
8          }
9 // do something
10
11     }
12 }
so my question is How may objects are eligible for garbage collection at line no: 9 (// do something)?

so my question is How may objects are eligible for
garbage collection at line no: 9 (// do something)?It's impossible to answer that question since we don't know how MyObj is implemented.
Kaj

A question about JNI references, persistence, and garbage collection

I am writing a library to allow our Java developers to access C functions in our product. I want people on the Java side to be able to instantiate instances of a new object (on the C side), say "Map", and I want those objects to persist until they are destroyed on the Java side. I am thinking of creating a wrapper for the native methods, which stores an identifier for the instance of an object. When the C object is accessed, the identifier is passed to the C code which looks up the correct object in a table. I understand that if I use the NewGlobalReference call in JNI I can get objects to persist.
When it is time for garbage collection I plan to override finalize() to call the C code and tell it to remove the Global Reference.
Here's what I have in mind
public class JMap() {
     private static int id;
     static {
          System.loadLibrary("libMap");
          /*Call C method which instantiates object and creates a GlobalReference
          which is stored in table. Returns ID for reference*/
          id = _init();
     public void setSize(int x, int y) {
          _setSize(id, x, y);
     public void finalize() {
          _finalize(id);
          super.finalize();
     private native int _init();
     /*calls DeleteGlobalReference for the reference matching this id*/
     private native void _finalize(int id);
     private native void _setSize(int id, int x, int y);
}Is this the right thing to do? Have I understood the way JNI works with regard to GlobalReferences?
Any comments, tips or pointers would be appreciated :)

This probably should have been posted in the Native Methods sub-forum, I have reposted there:
http://forum.java.sun.com/thread.jspa?threadID=657667
Mods please delete this post :)

"finally" how effective is it for garbage collector ?

I am a Java Developer and a SCJP2 with 99% score. Recently, I was in a debate with one of my colleague over the use of }try { //code } finally{}" for helping in the garbage collection of method level objects. For e.g. consider the following code.
////// code starts //////////
public class TestFinallyGC {
public void aMethod() {
java.util.ArrayList myList = null ;
try {
myList = new java.util.ArrayList();
// do something with the list
} finally {
myList = null;
////// code ends //////////
Now, my question is : How effective is or useful is the above finally block in above code for the garbage collection of the ArrayList object ? Because if the "finally" block is always going to be at the end of the method then by the time the method finishes (and the finally block also executes at around same time) the variable "myList" will also go out-of-scope and the object it was representing becomes eligible for garbage collection, no matter whether we explicitly set it to "null" or not.
Is the above conslusion correct ?
--Vinod.

How did you decide that references on the stackwere
not reachable?Personally I decided it because after I exit a block
or return from a function, the variables defined there
go irreversibly out of scope, so there is no way for
me to ever interact with them again. And since those
where the only references to the large arrays, they
were unreachable and eligible for garbage collection.
Ok. But something owns the stack. At the something is not going out of scope. It still owns the stack.
Given that reachable does not just
mean user threads but JVM threads as well.I did not create any threads, so there is just the
"Main" thread.
As far as I know there are no JVM threads. That is to
say, I read the JLS and did not find their existence
defined there. It does say that finalizers may be run
on "any thread" but does not say that there must be a
separate finalizer thread. Yes as far as you know. However, none of the specs disallow the JVM from creating JVM threads. The spec is specific that it unreachable from a thread, but it does not specify how those threads come into existence.
Basically since the jls
does not say there are JVM threads, we must assume
that if they exist then the behavior would be the same
as if they did not.
No. That is not the way one should approach a spec. Anything that the spec does not specify must be considered to be undefined. It can have any possible behavior.
So the stack might belong to a java object/thread or it might not. Either is possible. If it doesn't then it is unreachable and thus collectible. If it does then it is not.
So both suppositions are equally valid. So presumably the answer to my question would have been that you are assuming that it does not belong to a java object.
(Naturally we are both aware that the stack is always reachable by the system. It is not a temporary. Thus the question is only if it belongs to a java object or not. Or possibly if it does belong to a java object then whether references on it are cleared after a method exit.)
And as far
as I know there is no reason to think that thestack
might not be in the java domain space (althoughthat
might suggest a chicken and egg problem.)??
What are you talking about? What is the "java domain
space"? I don't know what that means.
JVMs always consist of C/C++ code with some mixture of Java. There is always C/C++ and there is always java. The first is true because the OS will not run java byte codes. The second is true because the JVM must always load java.lang.String.
Given this, it means that in any JVM there will be a domain space that consists of java entities and a domain space that consists of something else (C/C++.)
The question here is whether the stack is part of the C/C++ space or part of the java space.
The only stack I know about is the one that starts at
Thread.run() and goes up through all the methods that
have been called, ending at the method currently
executing. There is nothing above or below the stack.
When you call a method, its size increases by one,
and when a method returns, the size decreases by
one.
Doubt it. The stack pointer might move but I doubt the stack size increases and decreases. There are performance reasons for not doing that along with system management problems.
Of course if you have a reference that states otherwise then I would be glad to read it.
I think the whole point of this discussion is "what
happens to the stack frames that are lost when methods
return". My answer: They cease to exist, any
references they may have contained are lost and if
they were the only references to a given object it
would be immediately available for garbage
collection.

BufferedWriter I/O Garbage Collection!?

Ack! I cannot come up with an I/O solution that doesn't produce a lot of objects for collection. I'm sure there has to be a way, but at this point I'm at a loss. I recently noticed after downloading Optimizeit and watching object creation, that everytime I write to an output stream (in my case it's BufferedWriter going out to a socket), it creates new byte[] objects in large quantities, which are then available for garbage collection. This normally wouldn't be an issue, but if I wrap my code around a for loop that outputs a lot of data, I've generated quite a lot of instances. (I have a memory leak somewhere in my code, looking at object creation is about all I can do to find it)
For example, assume I have a StringBuffer _Buffmessage.
I also have a character array out_message.
os is my outputStream.
os = new BufferedWriter(new OutputStreamWriter(clientSocket.getOutputStream()));
//loop through StringBuffer and copy into a character array to prevent creation of String object
//(alternative to using toString() method of StringBuffer
for(int i = 0 ; i < _Bufmessage.length(); i ++)
out_message[i] = _Bufmessage.charAt(i);
//write out character array to client
os.write(out_message, 0, _Bufmessage.length());
os.newLine();
os.flush();If I run this code around 2000 times, I end up generating thousands of instances of byte[] ready for collection after running os.flush(); There HAS to be a way around this, or should I even be concerned about this? Am I somehow creating an object for each byte in the stream?

Here's a follow up and the solution I found. The two suggestions I recieved were:
Suggestion 1:
StringBuffer input;
OutputStream out;
out.write( input.toString().getBytes());
out.close();and Suggestion 2:
StringBuffer input;
OutputStream out;
byte[] outArray = input.toString().getBytes();
out.write(outArray,0,outArray.length );
out.close();However a combination of my original solution as well as the suggested solutions resulted in the fix. In Suggestion 1, every call to write would create an instance of string (bad) and then write the byte array. In Suggestion 2, every call would result in the creation of a string (bad), creation of a byte array(bad), and a dupe of that array into write (ick). This was really an issue since I was outputting around 3-4 thousand times. My final solution is as follows; creates no new instances and is able to write out to my outputstream:
byte[] outArray = new byte[2000]; //byte array for output
OutputStream os = clientSocket.getOutputStream(); //this is the socket outputstream to write to
//for loop here, processing data......
try
//fill the byte array with chars from StringBuffer - reuse the existing array to
//avoid multiple instances being created
for(count = 0 ; count < _Bufmessage.length(); count ++)
   outArray[count] = (byte)_Bufmessage.charAt(count);
//cast a new line byte to the output
outArray[count] = (byte)'\n';
//write out the length of the string
os.write(outArray,0,_Bufmessage.length());
}viola my memory leak was plugged - data is written to output, no char[] or byte[], nor String instances are generated, and I can sleep! As a sidenote, I did end up converting to NIO, and the new I/O classes eliminate these problems. I thought I'd share the solution anyway. Thanks to you three who gave me suggestions and didn't give me a hard time being a first time poster ;)

At which line , Object is Garbage collected.

1. public class GC {
2. private Object o;
3.   private void doSomethingElse(Object obj) { o = obj; }
4.   public void doSomething() {
5. Object o = new Object();
6. doSomethingElse(o);
7.   o = new Object();
8.   doSomethingElse(null);
9 o = null; 10. }
} When the doSomething method is called, after which line does the Object created in line 5 become available for garbage collection?
A. Line 5
B. Line 6
C. Line 7
D. Line 8
E. Line 9
F. Line 10
I think it should be line 9.but answer is 8....
How is it line 8?
Edited by: user12203354 on Nov 4, 2012 9:38 PM

You've already ask a similar question in your other thread where I ask you to answer some questions.
Question on Garbage collection
You may want to work on one question like this at a time until you understand the difference between an object and a variable that references an object.

Froce garbage collection

Is there any other way to force garbage collection besides
system.gc()
Runtime.ExcuteFinalization()
I know thoes still does not guranteen garbage collection.
How to improve performace to maximize the possibility for garbage collection?
Thanks

How to improve performace to maximize the possibility
for garbage collection?As soon as you are done using the object references, get them out of scope :) That would help. Calling System.gc() wouldn't.

Calling of finalize() for garbage collection

Similar Messages

Maybe you are looking for