Cosa sono esattamente le risorse non gestite?

Voglio sapere delle risorse non gestite. Qualcuno può darmi un’idea di base?

    Risorse gestite significa fondamentalmente “memoria gestita” gestita dal garbage collector. Quando non si ha più alcun riferimento a un object gestito (che utilizza la memoria gestita), il garbage collector rilascerà (eventualmente) quella memoria per te.

    Le risorse non gestite sono quindi tutto ciò che il garbage collector non conosce. Per esempio:

    • Apri file
    • Apri le connessioni di rete
    • Memoria non gestita
    • In XNA: buffer di vertici, buffer di indice, trame, ecc.

    Normalmente vuoi rilasciare quelle risorse non gestite prima di perdere tutti i riferimenti che hai all’object che li gestisce. Puoi farlo chiamando Dispose su quell’object o (in C #) usando l’istruzione using che gestirà la chiamata a Dispose per te.

    Se trascuri di Dispose correttamente le tue risorse non gestite, il garbage collector finirà per gestirle per te quando l’object che contiene quella risorsa viene garbage collection (questa è “finalizzazione”). Ma poiché il garbage collector non è a conoscenza delle risorse non gestite, non è in grado di dire quanto sia necessario liberarle, quindi è ansible che il tuo programma funzioni male o esaurisca completamente le risorse.

    Se implementi una class che gestisce risorse non gestite, spetta a te implementare correttamente Dispose e Finalize .

    Alcuni utenti classificano file aperti, connessioni db, memoria allocata, bitmap, flussi di file ecc. Tra risorse gestite, altre tra non gestite. Quindi sono gestiti o non gestiti?

    La mia opinione è che la risposta sia più complessa: quando apri il file in .NET, probabilmente utilizzi qualche class .NET integrata System.IO.File, FileStream o altro. Perché è una normale class .NET, è gestita. Ma è un wrapper, che all’interno fa il “lavoro sporco” (comunica con il sistema operativo usando le dll Win32, chiamando le funzioni di basso livello o anche le istruzioni di assemblatore) che apre davvero il file. E questo è ciò che .NET non sa, non gestito. Ma forse puoi aprire il file da solo usando le istruzioni dell’assemblatore e bypassando le funzioni di file .NET. Quindi l’handle e il file aperto sono risorse non gestite.

    Lo stesso con il DB: se si utilizza un assembly DB, si hanno classi come DbConnection ecc., Sono noti a .NET e gestiti. Ma avvolgono il “lavoro sporco”, che non è gestito (allocare memoria sul server, stabilire una connessione con esso, …). Se non usi questa class wrapper e apri qualche socket di rete da solo e comunichi con il tuo strano database usando alcuni comandi, non è gestito.

    Queste classi wrapper (File, DbConnection ecc.) Sono gestite, ma all’interno usano risorse non gestite allo stesso modo come te, se non usi i wrapper e fai il “lavoro sporco” da solo. E quindi questi wrapper implementano i pattern Dispose / Finalize. È loro responsabilità consentire al programmatore di rilasciare risorse non gestite quando il wrapper non è più necessario e di rilasciarle quando il wrapper è sottoposto a garbage collection. Il wrapper sarà correttamente garbage collection da garbage collector, ma le risorse non gestite all’interno verranno raccolte utilizzando il pattern Dispose / Finalize.

    Se non si utilizzano classi wrapper .NET o di terze parti incorporate e file aperti da alcune istruzioni di assembler ecc. Nella propria class, questi file aperti non sono gestiti e DEVI implementare pattern di eliminazione / finalizzazione. In caso contrario, si verificherà una perdita di memoria, una risorsa bloccata per sempre ecc. Anche quando non la si utilizza più (operazione di file completata) o anche dopo la chiusura dell’applicazione.

    Ma la tua responsabilità è anche quando usi questi wrapper. Per quelli che implementano dispose / finalize (li riconosci, che implementano IDisposable), implementa anche il tuo pattern di smaltimento / finalizzazione e Dispose anche questi wrapper o dà loro il segnale di rilasciare le loro risorse non gestite. Se non lo fai, le risorse saranno rilasciate dopo un tempo indefinito, ma è pulito per rilasciarlo immediatamente (chiudere il file immediatamente e non lasciarlo aperto e bloccato casualmente per diversi minuti / ore). Quindi, nel metodo Dispose della class, chiami i metodi Dispose di tutti i wrapper usati.

    Le risorse non gestite sono quelle che vengono eseguite al di fuori del runtime .NET (CLR) (ovvero codice non- .NET.) Ad esempio, una chiamata a una DLL nell’API Win32 o una chiamata a un dll scritto in C ++.

    La differenza fondamentale tra una risorsa gestita e non gestita è che il garbage collector conosce tutte le risorse gestite, ad un certo punto nel tempo il GC arriverà e ripulirà tutta la memoria e le risorse associate a un object gestito. Il GC non è a conoscenza di risorse non gestite, come file, stream e handle, quindi se non li pulisci esplicitamente nel tuo codice, finirai con perdite di memoria e risorse bloccate.

    Rubato da qui , sentiti libero di leggere l’intero post.

    Una “risorsa non gestita” non è una cosa, ma una responsabilità. Se un object possiede una risorsa non gestita, ciò significa che (1) qualche quadro esterna a essa è stata manipolata in un modo che potrebbe causare problemi se non ripulita, e (2) l’object ha le informazioni necessarie per eseguire tale pulizia ed è responsabile per averlo fatto

    Sebbene molti tipi di risorse non gestite siano fortemente associati a vari tipi di quadro del sistema operativo (file, handle GDI, blocchi di memoria allocati, ecc.) Non esiste un singolo tipo di quadro che è condivisa da tutti, tranne la responsabilità di pulire. In genere, se un object ha la responsabilità di eseguire la pulizia, avrà un metodo Dispose che gli impone di eseguire tutte le operazioni di pulizia per le quali è responsabile.

    In alcuni casi, gli oggetti lasciano spazio alla possibilità che possano essere abbandonati senza che prima nessuno abbia chiamato Dispose. Il GC consente agli oggetti di richiedere la notifica di essere stati abbandonati (chiamando una routine chiamata Finalize) e gli oggetti possono utilizzare questa notifica per eseguire autonomamente la pulizia.

    Termini come “risorsa gestita” e “risorsa non gestita” sono, purtroppo, utilizzati da persone diverse per indicare cose diverse; francamente penso che sia più utile pensare in termini di oggetti come se non avessero alcuna responsabilità di pulizia, avendo responsabilità di pulizia che si prenderà cura di se Dispose è chiamato, o avendo responsabilità di pulizia che dovrebbe essere gestita tramite Dispose, ma che può anche essere curato da Finalize.

    Qualsiasi risorsa per la quale la memoria è allocata nell’heap gestito .NET è una risorsa gestita. CLR è perfettamente a conoscenza di questo tipo di memoria e farà di tutto per assicurarsi che non resti orfano. Qualsiasi altra cosa non è gestita. Ad esempio, l’interoping con COM, potrebbe creare oggetti nello spazio di memoria proces, ma CLR non si prenderà cura di esso. In questo caso l’object gestito che effettua chiamate attraverso il server gestito dovrebbe essere responsabile per qualsiasi cosa al di là di esso.

    Vediamo prima come sono stati utilizzati i programmi VB6 o C ++ (applicazioni Non Dotnet). Sappiamo che i computer capiscono solo il codice a livello macchina. Il codice livello macchina viene anche chiamato come codice nativo o binario. Quindi, quando eseguiamo un programma VB6 o C ++, il rispettivo compilatore di linguaggio, compila il rispettivo codice sorgente del linguaggio in codice nativo, che può essere compreso dal sistema operativo e hardware sottostante.

    Il codice nativo (codice non gestito) è specifico (nativo) al sistema operativo su cui è stato generato. Se si prende questo codice nativo compilato e si tenta di eseguire su un altro sistema operativo, fallirà. Quindi il problema con questo stile di esecuzione del programma è che non è portabile da una piattaforma a un’altra piattaforma.

    Vediamo ora come si esegue un programma .Net. Usando dotnet possiamo creare diversi tipi di applicazioni. Alcuni dei tipi più comuni di applicazioni .NET includono applicazioni Web, Windows, Console e Mobile. Indipendentemente dal tipo di applicazione, quando si esegue un’applicazione .NET accade quanto segue

    1. L’applicazione .NET viene compilata in Intermediate language (IL). L’IL è anche denominato Common Intermediate Language (CIL) e Microsoft Intermediate language (MSIL). Le applicazioni .NET e non .NET generano un assembly. Gli assembly hanno un’estensione di .DLL o .EXE. Ad esempio, se si compila un’applicazione Windows o Console, si ottiene un file .EXE, dove come quando compiliamo un progetto di libreria Web o Classe otteniamo una DLL. La differenza tra un assembly .NET e NON .NET è che, DOTNET Assembly è in un formato di lingua intermedio in cui l’assembly NON DOTNET è in formato di codice nativo.

    2. Le applicazioni NON DOTNET possono essere eseguite direttamente sopra il sistema operativo, dove le applicazioni DOTNET vengono eseguite su un ambiente virtuale chiamato Common Language Runtime (CLR). CLR contiene un componente chiamato Just In-Time Compiler (JIT), che convertirà il linguaggio intermedio in codice nativo che il sistema operativo sottostante può comprendere.

    Quindi, in .NET l’esecuzione dell’applicazione consiste di 2 passaggi 1. Compilatore di lingua, compila il codice sorgente in Intermediate Language (IL) 2. Compilatore JIT in convertitori CLR, IL in codice nativo che può quindi essere eseguito sul sistema operativo sottostante .

    Poiché un assembly .NET è in formato Intermedaite Language e non in codice nativo, gli assembly .NET sono portatili su qualsiasi piattaforma, purché la piattaforma di destinazione abbia Common Language Runtime (CLR). Il CLR della piattaforma di destinazione converte il linguaggio Intermedaite in codice nativo che il sistema operativo sottostante può comprendere. Intermediate Languge è anche chiamato come codice gestito. Questo perché CLR gestisce il codice che viene eseguito al suo interno. Ad esempio, in un programma VB6, lo sviluppatore è responsabile della disallocazione della memoria consumata da un object. Se un programmatore dimentica di annullare l’allocazione della memoria, potremmo incorrere in difficoltà nell’eliminare le eccezioni di memoria. D’altra parte un programmatore .NET non deve preoccuparsi di de-allocare la memoria consumata da un object. La gestione automatica della memoria, nota anche come raccolta dei dati, è fornita da CLR. A parte, dalla raccolta dei rifiuti, ci sono molti altri vantaggi forniti dal CLR, di cui parleremo in una sessione successiva. Poiché CLR gestisce ed esegue l’Intermediate Language, anche (IL) viene chiamato come codice gestito.

    .NET supporta diversi linguaggi di programmazione come C #, VB, J # e C ++. C #, VB e J # possono generare solo codice gestito (IL), dove C ++ può generare sia codice gestito (IL) che codice non gestito (codice nativo).

    Il codice nativo non è memorizzato in modo permanente da nessuna parte, dopo aver chiuso il programma il codice nativo viene gettato via. Quando eseguiamo nuovamente il programma, il codice nativo viene generato di nuovo.

    Il programma .NET è simile all’esecuzione del programma java. In java abbiamo codici byte e JVM (Java Virtual Machine), dove come in .NET abbiamo Intermediate Language e CLR (Common Language Runtime)

    Questo è fornito da questo link: è un grande tutor. http://csharp-video-tutorials.blogspot.in/2012/07/net-program-execution-part-1.html