1. The truth about java robustness
Many books have mentioned the robustness of java Because java uses arrays to replace the pointer of c ++. The biggest headache for c ++ is the memory problem, the robustness of java makes it unnecessary for programmers to consider the memory. This idea is not correct. Although java has a garbage collection mechanism, programmers do not need to delete the memory, however, the memory should be taken into account during encoding, And the jvm memory should not be wasted as much as possible; this involves the java stack issue.
2. java stack differences
Heap: storage class type, which is established with new. The automatic garbage collection mechanism is responsible for garbage collection, which is slow.
1) The heap is a "RunTime" Data zone. Class instantiation objects are allocated space from the heap. That is to say, the heap space is created through the new command;
2 ). the difference with c ++ is that java does not need to release the heap, but is responsible for the garbage collection mechanism, because the heap dynamically allocates the memory size, that is, it is allocated when the program runs;
3). This also produces a problem. The data memory reading speed in the heap space is slow.
Example: String str = new String ("yangkai ");
STACK: stores basic data types with High Speed
1) The stack stores the basic data types (byte, short, int, long, float, double, boolean, and char) and object handles;
2). Data can be shared. What is sharing? The share mentioned here is not determined by the programmer but controlled by the jvm. It refers to the automatic processing method of the system, for example: int a = 10; int B = 10; here the space addresses on the stack pointed to by the and B variables are the same, which is called "data sharing". The processing logic of jvm: when the Java Virtual Machine processes int a = 10, it first creates a variable on the stack as a reference to a, and then checks the stack to see if there is a value of 10. If there is a, it points a to 10, if not, store 10.
3). fast compared with the heap;
4) the size and survival of stack data are fixed, and there is a lack of flexibility.
For example, int a = 0;
3. Methods for instantiating objects
For example, the instance of the String class can be created using two methods:
String str = new String ("yangkai ");
String str = "yangkai ";
Analysis: The created objects in these two methods are different. According to the stack knowledge we introduced above, we should have some knowledge about this String instance! The first method is to use the new method to open up space on the stack and create an object if it is not called once. The second method is to create a String object reference on the stack, and then store "yangkai" for str reference; re-call str next time. If there is one on the stack, it will not be created again. Therefore, we generally use two methods to compare String variables: equals () and "= "; generally, "=" determines whether the object is equal, that is, whether it is the same object. If two String objects are equal, the String is stored in the stack and the data is shared, the two strings are the same object, while equals () determines whether the content of the two objects is equal. For example, the equals () method can only be used to determine the content of the string on the stack, "=" indicates false, because every string is stored as a String object in the heap.
4. How to control the memory. Here we will show you how to use the jvm memory.
Maximum memory of the current Virtual Machine: Runtime.GetRuntime(). MaxMemory ();
Memory occupied by the VM before the loop: Runtime.GetRuntime(). TotalMemory ();
The following two cases are used to monitor jvm memory:
Package com. hudong. memory;/***** @ Title: MemoryTest. java * @ Copyright: Copyright (c) 2005 * @ Description:
*
* Test memory usage of the Java Virtual Machine * @ Created on 11:40:35 * @ author Yang Kai */public class MemoryTest {/*** @ param args */public static void main (String [] args) {testStringBuffer (); // testString () ;}/ *** test the memory occupied by the String Instance Object */public static void testString () {String str = new String ("abcdefghijklmn"); int count = 0; System. out. println ("maximum memory of the current Virtual Machine:" + Runtime. getRuntime (). maxMemory ()/1024/1024 + "m ------" + Runtime. getRuntime (). maxMemory () + "byte"); System. out. println ("memory occupied by VM before loop:" + Runtime. getRuntime (). totalMemory ()/1024/1024 + "m =" + Runtime. getRuntime (). totalMemory () + "byte"); while (true) {try {str + = str; count ++;} catch (Error e) {System. out. println ("cycles:" + count); System. out. println ("the size after the string loop is:" + str. length ()/1024/1024 + "m-=" + str. length () + "byte"); System. out. println ("memory occupied by VM before loop:" + Runtime. getRuntime (). totalMemory ()/1024/1024 + "m =" + Runtime. getRuntime (). totalMemory () + "byte"); System. out. println ("encountered error:" + e); break ;}/ ** running result: * maximum memory of the current VM: 793 MB ------ memory occupied by the VM before the 832438272 byte loop: 127 MB = 133234688 byte cycles: 23 the size after the string loop is 112 MB-= 117440512 bytes. The VM occupied memory before the loop: 642 m === 673669120 byte error: java. lang. outOfMemoryError: Java heap space */}/*** test the memory occupied by the StringBuffer Instance Object */public static void testStringBuffer () {StringBuffer sb = new StringBuffer ("abcdefghijklmn "); int count = 0; System. out. println ("maximum memory of the current Virtual Machine:" + Runtime. getRuntime (). maxMemory ()/1024/1024 + "m ------" + Runtime. getRuntime (). maxMemory () + "byte"); System. out. println ("memory occupied by VM before loop:" + Runtime. getRuntime (). totalMemory ()/1024/1024 + "m =" + Runtime. getRuntime (). totalMemory () + "byte"); while (true) {try {sb. append (sb); count ++;} catch (Error e) {System. out. println ("cycles:" + count); System. out. println ("the size after the string loop is:" + sb. length ()/1024/1024 + "m-=" + sb. length () + "byte"); System. out. println ("memory occupied by VM before loop:" + Runtime. getRuntime (). totalMemory ()/1024/1024 + "m =" + Runtime. getRuntime (). totalMemory () + "byte"); System. out. println ("encountered error:" + e); break ;}/ ** running result: * maximum memory of the current VM: 793 MB ------ memory occupied by the VM before the 832438272 byte loop: 127 MB = 133234688 byte cycles: 23 the size after the string loop is 112 MB-= 117440512 bytes. The VM occupied memory before the loop: 539 m === 566108160 byte error: java. lang. outOfMemoryError: Java heap space */}}
Analysis: the above two programs are used to describe the memory usage of String and StringBuffer. The results of the above two classes are as follows: the Stringbuffer is larger than the String byte obtained after the String loop. During this test, the two classes obtain the same String size, the difference is that the memory size of the virtual machine is different, and the latter is obviously smaller than the former.
Note: After jdk is installed, the default jvm size is 63 MB. During the above test, the xmx size of the jvm configuration file is increased.