Should I create Java Null objects?

Let's say I iterate over an array of objects i.e.

for (int r = 0; r < rows; r++) { for (int c = 0; c < columns; c++) { if (bricks[r][c] != null) { bricks[r][c].draw(gl) 

If at some point I want to destroy the brick, should my remove () method hide the object as follows:

 private void remove(GameBrick obj) { for (int r = 0; r < rows; r++) { for (int c = 0; c < columns; c++) { if (bricks[r][c] != null){ if (bricks[r][c] == obj) { bricks[r][c] = null; } 

Or should I set the boolean exists flag to false, and when repeating the objects, add a return or continue return if bricks[r][c].exists == false ?

I currently have my code based on nulling object and null checks, but later I read about the garbage collector and that setting the object to null makes it work more often.

I want to know if this is true, and what I should do best to remove objects (if I should even).

+4
source share
7 answers

but later I read about the garbage collector and setting object to null makes it work more often.

No, that would be a pure rumor. The best approach is to assume that the GC has been optimized to work as often as necessary to provide the best balance between performance and memory usage.

Setting references to zero is how you signal to the GC that you no longer need an object. GC should not do anything about it.

Update

To tune application performance, you must measure the behavior of the entire application - this means that you must first write the entire application (or a very realistic end-to-end model). Micro optimization does not work.

Thus, the best approach is to let the GC do what it is designed to - to make it easier for you to write clear, simple, and easy-to-use code thanks to automatic memory management. This way, when you tested your application on the target machine / device, and you can see where you need to tune performance, it will be easy to make the necessary changes without breaking anything.

Performance optimization should be determined by measurement. Measurement should be carried out on a realistic prototype of the complete product. So, in your implementation of the first step, concentrate on writing simple code. Then measure and place dirty hacks in those places where they are really necessary.

Keep in mind that they can be in different places depending on the device you are working on! On some devices, a hack used in a certain place can slow down work, while on another device it speeds up work. Therefore, you cannot simply blindly follow the rules in your code. You have to measure.

+4
source

Later I read about the garbage collector and found that an object with a zero value makes it work more often.

This is not true. The garbage collector runs on a regular schedule and when the JVM runs out of memory. By setting the link to null , you can increase the amount of memory that the GC frees up and reduce the amount of work done, since the type of GC used in java is O (| non-garbage-memory |).

Increasing the amount of freed memory reduces the value of O (| non-garbage-memory |), which can cause the JVM to not work often enough and not affect regular scheduled runs.

What should I do best to delete objects (if I should even)?

If the object reference is no longer needed, set it to null . Structure your functions so that function calls that take a lot of time take as few parameters as possible. Structure your classes so that they are loosely coupled - one of the results of this is that long-lived objects have few members. Do it consistently and you will find yourself in a sweet place for which JVM optimizers are optimized.

+3
source

You want to prevent as much GC time in the game as possible. Do not let them go, create a pool, mark the dead, and instead of creating new ones, select the dead from the pool and revive it.

+2
source

Yes, set the references to zero. This will force the garbage collector to free up more memory for your application. Setting references to zero does not cause the garbage collector to work more often, but this will certainly help it free up more memory.

+1
source

The answer will depend on your specific code, but in general, for playing Android you want to avoid as much garbage collection and object creation as possible (see here for some details).

Do you know the maximum number of rows and columns of bricks that you have? Will you very often destroy and create bricks? If so, it might be best for you to highlight all of your bricks in front and use a boolean value to indicate if the brick is alive or not.

+1
source

Consider storing the r / c position inside the brick when you attach it to the bricks container. Then you do not need to look, just look into the brick. This assumes that you can add a brick no more than once to a container.

Set the reference to null in all cases when the contained object lives longer than the area of ​​your code. It is not necessary to set zero local variables, this will be implicit at the end of the region (end of the block "}").

0
source

First of all, to answer your question directly: there is nothing wrong with setting this link to zero. Note that you do not actually set the object to null, you set the object reference to null (or if you want to be pedantic, the value of the object reference)

A good idea or not in your particular case is a different story. Of course, you can minimize garbage collection by not highlighting or releasing objects (see this Google I / O presentation ). I would be interested to see evidence of the opposite from others who do not seem to agree. If your 2D array is the only reference to bricks, then setting it to zero will result in dereferencing the object. While dereferencing an object may not do the GC more often (I'm not sure about this, although all the literature I read recommends avoiding dereferencing and distribution in the game loop on Android), the highlight will certainly be.

If your bricks are always in the same position and they just collapse (like Breakout / Arkanoid), then your idea of ​​a Boolean flag is probably good. In this case, your 2D array looks like a fixed-size pool.

If your bricks can change positions, you can do the same and exchange bricks around when you move, but sometimes it would be more natural to just add / remove normally. In this case, you must highlight your bricks in the pool in front, and then you can reset the link in your 2D array without worrying about garbage collection, because your pool still contains the link (but you will need to return it to the pool first) .

0
source

Source: https://habr.com/ru/post/1399441/


All Articles