Se ho un'applicazione console con un codice simile:Calling Environment.Exit() all'interno di un blocco Utilizzando
using (DisposableObject object = new DisposableObject())
{
if (a condition)
Environment.Exit(0);
// Do Stuff
}
Sarà il mio oggetto essere correttamente smaltiti? O il thread muore prima che l'oggetto venga ripulito?
L'applicazione verrà chiusa e tutta la memoria gestita verrà rilasciata in quel punto.
Il blocco finally generato non verrà eseguito, quindi non verranno chiamati tutti i metodi Dispose, pertanto è possibile che le risorse non gestite non vengano rilasciate.
Il codice '// Do Stuff' verrebbe eseguito? Cosa significa 'Environment.Exit (0);' fare esattamente? –
'// Do Stuff' non verrà eseguito. 'Environment.Exit (0)' uccide il thread e restituisce 0 dal main. –
@ OlivierJacot-Descombes - '// Do Stuff' non verrà eseguito. La chiamata termina semplicemente il processo (restituendo un codice di errore - il passato in 'int'). – Oded
Le risorse di cui il sistema operativo è a conoscenza verranno generalmente ripulite all'uscita di un'applicazione. Le risorse di cui il sistema operativo non è a conoscenza non verranno generalmente ripulite.
Ad esempio, alcuni programmi che utilizzano un database e devono implementare un paradigma di blocco diverso da qualsiasi cosa il server di database supporti direttamente possono utilizzare una o più tabelle "LockedResources" per tenere traccia di quali risorse devono essere bloccate. Il codice che deve acquisire una risorsa bloccherà la tabella "LockedResources", aggiornandola per mostrare quali risorse devono essere bloccate e quindi rilasciarla; l'operazione sulla tabella "LockedResource" sarà in genere abbastanza veloce (quindi la tabella "LockedResource" verrà bloccata solo brevemente), anche se l'applicazione deve mantenere la risorsa reale per un lungo periodo. Se, tuttavia, l'applicazione fa un Environment.Exit mentre la tabella "LockedResources" dice che possiede una risorsa, il sistema operativo non avrà idea di come aggiornare la tabella "LockedResources" per annullare tale proprietà.
In generale, le cose come le applicazioni di database devono essere progettate per essere robuste anche se un'applicazione client inaspettatamente muore. Ad esempio, potrebbe esserci una tabella di client attivi, con ogni client attivo che tiene un blocco su un record che si identifica. Se un client che desidera utilizzare una risorsa nota che la tabella "LockedResources" ha eseguito il check out su un altro client, il primo client potrebbe verificare che la voce di quest'ultimo client nella tabella "client attivi" sia ancora bloccata. In caso contrario, potrebbe capire che il cliente in questione è morto e intraprendere azioni appropriate (riconoscendo che il cliente morto potrebbe aver lasciato la sua risorsa in cattivo stato). D'altra parte, il fatto che il database sia progettato per essere robusto se i client muoiono inaspettatamente non significa che lo siano sempre. L'abbandono delle risorse non è una buona cosa, anche se è di solito sopravvissuto.
Si noti che se si sta arrestando l'applicazione, anche se l'oggetto non è Smaltito, in realtà non si verificherà alcuna perdita di memoria (dato che lo spazio di memoria protetto viene completamente liberato una volta terminato il processo.) Altre cose potrebbero andare storte se lo smaltimento ha effetti collaterali più persistenti (come il commit su un database o qualcosa che vive al di fuori dell'ambito del processo). –
@DanBryant una risorsa non rilasciata non perderà memoria * managed *. Se la risorsa non occupata è una memoria non gestita (probabilmente a causa di un'interpolazione con una lingua non modificata), allora potresti avere una memoria non pubblicata. – Servy
Lo sto effettivamente usando su 'SqlConnection', ma quel blocco' using' è nidificato in altri due (oggetti SharePoint). Volevo solo essere sicuro che i metodi 'Dispose() 'sarebbero stati chiamati perché non eliminare gli oggetti SP genera errori nei log. –