Solution to DWR Memory Compatibility and Unable to Call Problems

  • 2021-08-31 07:11:11
  • OfStack

After the last DWR memory leak problem, according to the content of the network, JS file was modified. After modification, it was found that there were still some compatibility problems, and at the same time, there were some cases that could not be called.

And according to statistics, even if DWR memory leak, it is not particularly serious, unless you run a browser for a few days without closing, and refresh in real time!

After querying again, we know that IE browser has its own garbage collection function: CollectGarbage ();

CollectGarbage is a unique attribute of IE. The usage method for releasing memory should be to set the variable or reference object to null or delete

Then, before doing CollectGarbage, two necessary conditions must be clear:

Quote

An object is invalidated if it is outside the context in which it exists.

-1 global object will be invalidated if it is not held (referenced).

There are 1 explanations for when the object fails:


function testObject() {
var _obj1 = new Object();
}

function testObject2() {
var _obj2 = new Object();
return _obj2;
}

//  Example 1
testObject();

//  Example 2
testObject2()

//  Example 3
var obj3 = testObject2();
obj3 = null;

//  Example 4
var obj4 = testObject2();
var arr = [obj4];
obj3 = null;
arr = [];

In these four examples:

-[Example 1] _ obj1 is constructed in the function testObject (), but when the function exits, it has already left the context of the function, so _ obj1 is invalid;

-In "Example 2", an object _ obj2 is also constructed and outgoing in testObject2 (), so the object has an "out-of-function" context (and life cycle), but because of the function
The return value of is not "held" by other variables, so _ obj2 is also immediately invalid;

-In "Example 3", the _ obj2 constructed by testObject2 () is held by the external variable obj3, and then _ obj2 is not invalidated because the reference relationship disappears until the line "obj3=null" takes effect.

-For the same reason as in example 3, _ obj2 in "example 4" does not expire until after the line "arr= []".

In addition, I found that many people have said such a sentence:

Finally, a supplementary note about GC: When the IE form is minimized, IE will actively call the CollectGarbage () function once. This makes the memory footprint significantly improved after the IE window is minimized.

I can only say that calling the CollectGarbage () function will have unexpected gains, but it is not omnipotent, nor can it release memory by calling, let alone minimize the browser once after calling.

We are refreshing 5 times per second, each time there are more than 100 refresh points, so the browser's DOM is always adding and updating things. Calculated, even running for one hour is very expensive.

What's more, our software has to run on a customized machine, and we found that the hardware of this machine has compatibility problems. We updated the browser to IE7.0, and after refreshing the data in real time, we found that the memory 1 grew until the browser crashed. But different machines crash at different times.

I called the garbage collection function after each update and found that the browser's memory was still increasing, but the intervals were increasing, although the overall increase was still increasing. As a result, we ran on that machine for more than 10 hours, and the browser memory did not exceed 50M.

Few pages will refresh so much and run for so long, but we met.

I don't find it reasonable to blame DWR, at least for now, but for the need for a lot of refreshing and long running pages, I think it needs to be further studied.


Related articles: