Several ways to optimize the memory of the j2e-based application (1)

The out momory memory overflow problem often occurs during the development of the j2e-based application. Therefore, the optimization of the memory of the j2e-based application is necessary and necessary, I believe this article will surely help you gain some benefits.

Memory Optimization for j2_application

Out momory memory overflow often occurs during the development of the J2EE application. You must tighten your pants belt when using memory on your phone. The phone is calculated based on K. Writing mobile apps has brought people back to the 8086 age. The Optimization of the memory of the J2EE application is necessary.

I. code optimization

Memory overflow is definitely not related to the code. The Garbage Collector is a major advantage of java. Obviously, this feature saves a lot of trouble for code writers, but it brings a lot of risks.
For example, switching between different scenarios often occurs in the game. For example, from the game logic back to the main menu logic, the attitude towards the game logic object, many people will choose to forget to release the memory, it is waiting for the garbage collector to take care of the problem. But in fact, the garbage collector is not real-time. It is not like the C ++ Delete statement to immediately release unused memory. When switching from the game logic to the main menu logic, two objects may exist simultaneously, and the memory is insufficient.

In fact, the garbage collector is not very easy to use on j2s. It is effective only when all the garbage is manually released on j2s. All objects except simple objects must be explicitly set to null, for example, imgs = null; java provides a good tool to find out memory overflow. lang. runtime. freeMemory (). It can return the current amount of memory remaining and properly place it in the code to effectively monitor memory usage.
Some of the j2s programmers have bad habits of writing code.

Example 1: 

 
 

  
  
// A is not empty
  
  
A = new menu ();
 
 

Here there are two problems:

1. The code in this section first creates an object and then assigns values. That is to say, two objects exist simultaneously during this period, which may cause overflow.

2. This will also impede the work of the garbage collector.

The statement is as follows:

 
 

  
  
A = null;
  
  
System. gc (); // reclaim objects referenced before
  
  
A = new menu ();
 
 

Although it is a little troublesome, it is still necessary in j2s.

Example 2:

DrawString ("game time:" + time, 50, 50, Graphics. LEFT | Graphics. TOP );
"Game time:" + time is perfect. In the paint () method, it is refreshed and displayed on the screen. This statement will re-allocate the memory to store the "game time:" + time. After the display is complete, it must be released by the garbage collector. It takes twice the time and is prone to memory overflow. We recommend that you avoid repeatedly defining objects in repeated execution methods. Similar to the paint () method, there are similar situations in the loop.

Example 3:

Put the initialization of all objects in the constructor. The common practice of most people is to complete the initialization of the resources currently used.
A large part of memory overflow occurs in constructors. The peak memory usage is in the constructor, so avoiding this peak can effectively prevent overflow.
It is better to initialize the SDK for the first time. As shown below

 
 

  
  
If (img = null ){
  
  
// Initialization
  
  
}
 
 

Currently, all games require map arrays, sound arrays, and other resources.
These resources can be put in the code or in the file, but we recommend that you put these resources in the file when needed in loading. If these resources are put in the code, it will occupy a lot of code snippet space, and the code is usually loaded into the memory as soon as the program runs.

In addition to the methods listed above, there are other small methods, such as disabling useless rms, disabling useless network connections, and disabling useless streams. Stop the thread correctly. A good program architecture is also a good way to reduce code coupling.