When should GC. Collect be called in. Net?

When should GC. Collect be called in. Net?

 

Recently, a project was upgraded from VB to VB. NET code. Therefore, database operations use a relatively old oo4o (Oracle Objects for OLE) method ). Among them, in a larger external loop to call a function, the function executes an SQL query, but the External Loop is executed more than two hundred times when the "ORA-01000: the maximum number of opened cursors allowed is exceeded. Check the code and the opened recordset is closed. I don't know where the problem is. Finally, GC. Collect is added to the place where recordset is disabled to solve the problem.

 

The sample code is as follows:

Private sub button#click (byval sender as system. object, byval e as system. eventargs) handles button1.click dim clssession as object 'session dim clsdatabase as object 'database dim strsql as string dim lngcount as long dim RS as object' record set clssession = Createobject ("oracleinprocserver. xorasession ") clsdatabase = clssession. opendatabase ("host", "user/password", 0 &) strsql = "select * From t_sta" 'Execute one query SQL for lngcount = 1 to 100' multiple times in a loop and execute SQL retrieval rs = clsdatabase. createdynaset (strsql, & H0 &) console. writeline (RS. recordcount) rs. close () 'close record set rs = nothing GC. collect () 'immediately executes garbage collection. If you comment out the statement, an error with the CORA-01000 will occur. Next MessageBox. Show ("OK") end sub

 

This problem was solved, but it caused me to think about how to use GC. Collect.

On msdn, frequent calls to this function will lead to a decrease in the efficiency of garbage collection and thus affect the performance of applications.

0th
Generation and 1st
Generation of garbage collection is relatively fast and requires less system resources. And
The two-generation garbage collection operation is the opposite. Its activity takes a long time. Therefore, when the Garbage Collector checks Each heap object, the application process will be suspended. The garbage collection mechanism is very effective because it follows the memory allocation method in the system and adjusts its behavior accordingly. An attempt to force the garbage collection operation by calling the collect or waitforpendingfinalizers method will interfere with the garbage collection algorithm, which usually deteriorates the application's memory usage.

The collect method should be called only when you know that the application has used up a large amount of memory allocated once. For example, when the application has used up the large cache, or when the large dialog box is closed and you know (or possibly) it will re-open the dialog box, you can call collect.Method.

 

 

GC. Collect
Memory recovery:

1. Use Microsoft. Office. InterOP. Excel. applicationclass to Operate Excel.

2. Use webbrowser.

 

Based on the situation encountered this time, we can sum up,GC. Collect should be called to recycle memory immediately after a non-hosted component is used.The reason for the analysis is. when using unmanaged components in. net ,. net automatically performs a com. in the finalizer method (this method corresponds to the destructor in C ++ ,.. Net recommends the implementation of the idispose Interface) to release the memory, while the finalizer memory release method is relatively inefficient.

 

The finalizer function type is recycled as follows:

When GC is collected, it performs the following steps:

1. confirm that the object has no reference.

2. Check whether the object has records on the finalizer table.

3. If there is a record in the finalizer table, move the record to another table. Here we call it finalizer2. If no records exist in the finalizer2 table, the memory will be released.

 

The finalizer of the object on the finalizer2 table will be executed on another low priority thread and deleted from the table. When an object is created, GC checks whether the object has a finalizer. If so, a record is added to the finalizer table. The record we mentioned here is actually a pointer. If you carefully read these steps, we will find that objects with finalizer will not be recycled for the first time, that is, objects with finalizer will be recycled only after more than one collect operation, this takes a longer step, so I recommend that you do not create finalizer unless you absolutely need it. In order to prove that GC does this work, rather than the author's nonsense, we will give an example in the chapter on the resurrection of the object! ^_^ GC uses the concept of generation to improve the efficiency of collection. The principle is as follows. The object created before the first collection belongs to generation.
0. After that, the generation number will be moved backwards every time it is recycled. That is to say, the original generation 0 is changed to generation 1 during the second recycling, the objects created after the first recycle and before the second recycle will belong to generation 0. GC will first try to recycle the objects belonging to generation 0, because these are the latest, so it is most likely to be recycled, for example, some local variables in a function are not referenced (can be recycled) When exiting the function ). If enough memory is recycled in generation 0, GC will not be recycled again. If not, GC will try to generation
1. If it is not enough, it will be recycled in generation 2, and so on. Generation also has a maximum limit, depending on the Framework version, which can be obtained using GC. maxgeneration. After memory is recycled, GC will re-arrange the memory so that there is no space between the data. This is because the CLR allocates memory sequentially, So there cannot be free memory between memories. Now we know that CPU time will be wasted every time we recycle it, which is why I generally do not manually GC. Collect.