in the first example the array is cleared but not deleted.in the second it is deleted faster but it also has to be created again everytime the object is recycled.should i use the first method or the second?

Like I said above, the GC only kicks in when it needs to. Java doesn't let you specify (technically) when the GC kicks in. What you're trying to do cannot be done reliably because Java takes control of collection. Sure, the array might be deleted quicker in some rare cases, but its not reliable. If you need manual GC, look into a C language.

I have no idea what you need this for, so I cannot recommend either. Both are "sketchy", and you really do not need to worry about deleting objects. If you simply want to clear the object (assuming the array is taking in strings), then setting every element to "" would conceivably be ok, but that's more of a personal coding style than anything.

I want a cleared string array when the object is recycled.and btw the objects are never truly deleted. they are only active or inactive in the game.when they become inactive I call the deleteactor method to clear/reset all their properties.the recycleobject method reactivates the objects and put them back in the game.

The second way is better and makes more sense. It is more obvious if you have some knowledge of pointers, but whenever you use new (even in java) it creates objects on the heap (a part of memory). The GC works by checking if there is a pointer to all objects in heap. The heap is unorganized and needs pointers to access elements. The second nothing points to an element in the heap, that element can not practically be used again, so the garbage collector deletes this object. Both ways will invoke the garbage collector to delete the old objects; however, the string "" is actually "\0" and takes up some memory and simply isn't as logical as setting the array to null since you don't want it to point at a ton of strings of "" you want it to point at nothing (null), and if you want to recycle it you just want to set a new array.

edit:If you are setting the "Recycled" array back to the original array eventually. Why delete it? just leave it in memory? For example have a couple listOfTags arrays or even a multidimensional one if you want, and have 1 activeListOfTags array that you set to whever listOfTags is active at the time.

"You have to want it more than you want to breath, then you will be successful"

Ugh, this sounds exactly like an Object Pool to me. But, then you wouldn't need to delete the Objects, instead, you would just set them to a value that you wouldn't use so they can be used again. Below is an implementation for objects (not written by me but borrowed...)

/** * Acquires an object from the pool, if a recycled one is available, then * the pool will return the recycled one rather than creating a new one. * * @return object instance */publicfinalTacquireObject() {if( collectedTrash.size() > 0 )returncollectedTrash.remove(0);elsereturncreateInstance(); }

/** * Recycles an used object back to a clean state, called by object pool * if a used object will released back to the pool. * * @param obj object instance * @return recycled instance of the object */protectedabstractTrecycleInstance( Tobj );

/** * Creates a new instance of that object class, called by the object pool * if no recycled instance is available in the collected released objects. * * @return clean object instance */protectedabstractTcreateInstance();}

As far as I know, this only works if you are trying to keep your memory under tight control. In most applications, this is just useless. There may be an ounce of speed to gain, but all-in-all uses for a pool is very limited and partial. Whatever you would need this system for is beyond me. The only time I used it was to keep too much particles from generating on the screen.

The instances were garbage collection happens the most is when Java is getting close to reaching its memory limit (high FPS), or in between long sleep cycles. With Java, your best bet is to not even worry about it and let Java do its job. I did a lot of playing around with particles and Java2D. This is an implementation of snow particles (literally the third time I used this example).

It uses the two methods I stated. If you look at your profiler, you can also see exactly when Java uses the garbage collector. In simple programs, it isn't worth it though. I usually only do it to put a cap on memory usage for objects, but I never worry about the garbage collector. Java knows when best to use it.

Well, now you have two implementations of an Object Pool. One in my snow code and one used with an ArrayList. To be honest, there is very minimal advantage for using an ObjectPool. What you gain in speed, you lose in space as these objects will need to have a fast live & die rate to take full advantage of it (like my snow particles). Anything else that has a slow live & die rate will just waste valuable space on your RAM.

In my case, particles work well with ObjectPool. However, I would have NPC objects be a basic ArrayList. My suggestion, just know what implementation is right for the job and use your best judgement.

I would reiterate what ctomni231 said, but my word isn't all that important. Instead I think a good source is Joshua Bloch's 'Effective Java' handbook.

"avoiding object creation by maintaining your own object pool is a bad idea unless the objects in the pool are extremely heavyweight"Bloch goes on to explain that extremely heavyweight is something like a reusable database connection or network socket. Generally, "object pools clutters your code, increases memory footprint, and harms performance. Modern JVM implementations have highly optimized garbage collectors that easily outperform such object pools for lightweight objects." -Item 5Arrays of strings are about as lightweight as it gets, except for primitives such as byte, int, etc.

The book further mentions that "It is a very bad idea to warp an API to achieve good performance." -Item 55 The type of warped API the book is talking about is a class, package, set of methods, etc. which include methods or classes aimed to improve performance but that reduce code readability. Adding a recycleObject() or deleteObject() method to an object shouldn't be necessary unless the object uses a system resource such as a video card, sound input/output device, network socket, hard drive file, etc.

Programming tends to be a trade off between time, performance, quality, and half a dozen other factors. Your time is important and adding performance optimizations too early wastes time.

Write a well structures program and if performance issues come up, do some profiling and discover which parts of your code are slow, only then should you start trying to optimize. DON'T WORRY ABOUT PERFORMANCE UNTIL YOU HAVE SOMETHING MOSTLY DONE. I try to never shouting, but I've wasted weeks of my life prematurely optimizing code and it's useless; don't do it, you'll be a happier, more productive developer for it.

P.S. I know the feeling though, I still worry about optimization too early, even though I know I shouldn't.

So basically Rakiayn, don't worry about clearing or 'deleting' your list of Strings, the JVM knows what it's doing better than you do, and the only time appropriate for a String pool is if you are generating millions of new strings all the time, which I doubt.

Also, is your program using too much memory? If not, don't fix it if it's not broken!

Object pooling in Java has become completely useless and inefficient in most cases since Java 1.4. Rather avoid keeping references on useless objects so that the garbage collector can make a good job and implement some kind of management only for partially unmanaged objects allocated on the native heap which is the case of direct NIO buffers or objects depending on system resources (TeamworkGuy2 gave some examples).

I concur with these findings too; use pooling only when it is actually relatively expensive to construct an object (ie. large number of c'tor parameters, lots of validation, native call, large amount of memory consumed etc).

Hmm it never seems to work for me. My heap was generating tens of thousands of $Itr classes (from foreach constructs) every frame. Unfortunately with all the other tiny objects I was making every frame that pushed GC over the edge of acceptable and started giving me the Dreaded Regular Pause, so I had to regress all my foreaches into ordinary for loops Still, pauses gone, wahey.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org