Java input = "" does not match input = null?

Question

I am running a J2ME application and am facing serious memory issues.
So I built one more step to clear the huge input string and process its data and clear it. But this did not solve the problem until I set input = null , not input = "" .

Shouldn't it be the same in terms of memory management? Can someone please explain the difference to me?

Thanks,
Rayt

 for(int x = 0; x <= ChunksPartCount; x++) { _model.setLoading_bar_progress((x * ChunkSize)); input += web_service.FullCompanyListChunksGet(x, ChunkSize); if((x * ChunkSize) > 5000) { ReadXML(input); input = null; } } 

Edit:
I still want to mark the answer as a solution. I think Meyers comments are going in the right direction.

Answer 1

Each variable is actually a pointer to "Data" in memory.

input = "" assigns input to a string object. It has a length of (0) and an empty array, as well as several other pieces of data associated with it.

input.length () will return 0 at this point.

input = null makes the entry point "Invalid". Zero is a special case, which means that this pointer points to NOTHING, it is not assigned.

input.length () now throws an exception because you are not calling .length.

Answer 2

input = null deletes (allows the garbage collector to delete) the object in memory, and input = "" creates a String object containing the empty string "" . By setting the input to null, you make the input an empty object, so it will not take up any memory, and when you set the input = "" you set it to a new object that will definitely take some memory (obviously, this should be minimal).

You can see this IBM article about Java GC and performance, which hinders my previous recommendation. It says:

Explicit nulling is just the practice of setting reference objects to zero when you are done with them. The idea of ​​zeroing is that it helps the garbage collector by making objects unreachable before. Or at least that theory.

There is one case where the use of explicit nullification is not only useful, but practically necessary, and this is where the reference to the object scope is more widespread than it is used or are considered valid by specification. This includes cases such as using a static or instance to store a reference to a temporary buffer, rather than a local variable or using an array to store a reference, which may remain available at runtime, but not according to the intended semantics of the program.

Besides,

In the September issue of Java Developer Connect Technology Tips (see Resources), Sun warned of this risk and explained how to explicitly specify null in cases like the pop () example above. Unfortunately, programmers often take this advice too often, using explicit nullification in the hope of helping the garbage collector. But in most cases, this does not help the garbage collector at all, and in some cases it can hurt your program performance.

Answer 3

Using StringBuffer may be a better approach

This has already been said in SO:

String builder and stringbuffer in java

why use StringBuffer in java instead of string connection operator

Answer 4

Instead of thinking about why the garbage collector did not collect your object, I prefer to collect evidence of the situation. Others have already published their guesses.

If possible, create heap dump files to monitor the memory in your JVM when it runs your code, and then check them to see which objects exist.

Here is a web page that tells you how to do this: http://twit88.com/blog/2008/12/19/java-troubleshooting-memory-problem/

Good luck

---

Another idea: write a short program that does nothing more than create large String objects, and then turn on the detailed garbage collection mode to see what happens there. If you can reproduce the behavior in a small program, you can study it more easily. I think you may find that the JVM on a PC may behave differently than the JVM on a J2ME device such as a cell phone.

Answer 5

I would like to add a little to voyager's answer:

Regarding strings

Statement input = ""; from the collection point matches the entry input = "abcde..."; , since none of the operators invalidates the instance of the input object, but both simply modify the contents of the input String variable. In addition, for accuracy and refinement, input = something" modifies the contents of input , and String input = ""; creates an instance of input .

If input == "", then 'if (input.isEmpty ()) would be true, but if (input == null) `would be false.

Regarding the garbage collection

Operator input = null; decreases the reference count for this particular instance of the object, which, if it is the last reference to input , then input will be marked for garbage collection, which will not happen deterministically by the AKA when the garbage collector gets to it. The case when input = null; not really an input flag for garbage collection, would be: if input also passed to the collection; until input is removed from the collection, it will keep the reference count from decrementing and therefore from garbage collection.

Hope this helps, and for someone else out there, please feel free to correct any errors, even if they are subtle.

-bn

Answer 6

In Java strings, objects and object variable names are always pointers. If you have a line named input and enter input = null, this indicates entering zero space in memory. If you have input = "", it creates a line that does not contain text, an empty line.