Я хочу знати про некеровані ресурси. Може хто-небудь, будь ласка, дайте мені основну думку?
Відповіді:
Керовані ресурси в основному означають "керовану пам'ять", якою керує сміттєзбірник. Коли у вас більше немає посилань на керований об’єкт (який використовує керовану пам'ять), збирач сміття (зрештою) звільнить цю пам'ять для вас.
Некеровані ресурси - це все, про що смітник не знає. Наприклад:
Зазвичай ви хочете звільнити ці некеровані ресурси, перш ніж ви втратите всі посилання на об'єкт, яким керує ними. Ви робите це, зателефонувавши Disposeна цей об’єкт або (у C #), використовуючи usingоператор, який буде обробляти дзвінки Disposeза вас.
Якщо ви знехтуєте Disposeсвоїми некерованими ресурсами правильно, збирач сміття врешті обробляє це за вас, коли об’єкт, що містить цей ресурс, зібраний сміття (це "доопрацювання"). Але оскільки збирач сміття не знає про некеровані ресурси, він не може сказати, наскільки погано потрібно їх звільнити - тому для вашої програми можливо погана робота або вичерпання ресурсів цілком.
Якщо ви самостійно впроваджуєте клас, який обробляє некеровані ресурси, то саме вам належить реалізувати Disposeта Finalizeправильно.
Disposeчи скористатися using.
IDisposable. Якщо клас робить реалізації IDisposable, то ви повинні позбавитися від реалізації відповідного класу з usingабо , Dispose()коли ви зробили з ними. Виходячи з цього, ваше зворотне твердження: Якщо клас реалізує IDisposable, то він, ймовірно, містить внутрішні керовані ресурси.
Деякі користувачі класифікують відкриті файли, db-з'єднання, виділену пам’ять, растрові карти, потоки файлів тощо серед керованих ресурсів, інші - серед некерованих. Так вони управляються чи не керуються?
На мою думку, відповідь складніша: Коли ви відкриваєте файл у .NET, ви, ймовірно, використовуєте якийсь вбудований .NET-клас System.IO.File, FileStream або щось інше. Оскільки це нормальний .NET клас, ним керується. Але це обгортка, яка всередині виконує "брудну роботу" (спілкується з операційною системою, використовуючи dll Win32, викликаючи функції низького рівня або навіть інструкції асемблера), які дійсно відкривають файл. І це те, про що .NET не знає, некерований. Але, можливо, ви можете відкрити файл самостійно, скориставшись інструкціями асемблера та обійшовши функції файлу .NET. Тоді ручка та відкритий файл - некеровані ресурси.
Те ж саме з БД: Якщо ви використовуєте деяку збірку БД, у вас є такі класи, як DbConnection і т. Д., Вони відомі .NET і керуються ними. Але вони завершують «брудну роботу», яка не управляється (виділяйте пам’ять на сервері, встановлюйте зв’язок з нею, ...). Якщо ви не використовуєте цей клас обгортки і не відкриваєте якийсь мережевий сокет самостійно і спілкуєтесь із власною дивною базою даних за допомогою деяких команд, це не управляється.
Цими класами обгортки (File, DbConnection тощо) керують, але вони всередині використовують некеровані ресурси так само, як і ви, якщо ви не використовуєте обгортки і виконайте "брудну роботу" самостійно. Отже, ці обгортки дійсно реалізують шаблони утилізації / завершення. Їх відповідальність полягає в тому, щоб дозволити програмісту випускати некеровані ресурси, коли обгортка більше не потрібна, і випускати їх, коли обгортка збирається сміттям. Обгортка буде правильно сміттям, зібраним сміттєзбірником, але некеровані ресурси всередині збиратимуться за допомогою шаблону "Утилізувати / Фіналізувати".
Якщо ви не використовуєте вбудовані класи .NET або сторонні обгортки та відкриті файли за допомогою інструкцій асемблера тощо у вашому класі, ці відкриті файли не керуються, і ви ОБОВ'ЯЗКОВО реалізуєте шаблон розпорядження / доопрацювання. Якщо цього не зробити, випаде пам'ять, назавжди заблокований ресурс тощо, навіть коли ви більше не користуєтесь ним (файлова робота завершена) або навіть після завершення роботи програми.
Але ваша відповідальність також полягає у використанні цих обгортків. Для тих, хто реалізує розпорядження / доопрацювання (ви визнаєте їх, що вони реалізують IDisposable), реалізуйте також свою схему розпорядження / доопрацювання та розмістіть навіть ці обгортки або подайте їм сигнал для звільнення своїх некерованих ресурсів. Якщо ви цього не зробите, ресурси будуть випущені через деякий невизначений час, але його можна негайно випустити (негайно закрийте файл, не залишаючи його відкритим і заблокованим випадковим чином декілька хвилин / годин). Тож у своєму розпорядженні методом розпорядження класу ви називаєте методи викидання всіх використаних обгортків.
unmanaged vs managed resources
"Некерований ресурс" - це не річ, а відповідальність. Якщо об'єкт володіє некерованим ресурсом, це означає, що (1) деяким суб'єктом, що знаходиться поза ним, маніпулювали таким чином, що може викликати проблеми, якщо його не очистити, і (2) об'єкт має інформацію, необхідну для проведення такої очистки, і несе відповідальність. за це.
Хоча багато типів некерованих ресурсів дуже сильно пов'язані з різними типами об'єктів операційної системи (файли, ручки GDI, виділені блоки пам'яті тощо), не існує єдиного типу сутності, який би поділявся всіма ними, крім відповідальності прибирати. Як правило, якщо об'єкт або несе відповідальність за очищення, він матиме метод Dispose, який дає йому змогу виконувати всі очищення, за які він несе відповідальність.
У деяких випадках об’єкти дозволяють допустити можливість того, що вони можуть бути покинуті без того, щоб хтось покликав спочатку розпоряджатися. GC дозволяє об’єктам запитувати сповіщення про те, що вони були залишені (зателефонувавши у програму під назвою Finalize), і об’єкти можуть використовувати це сповіщення для самостійного проведення очищення.
Такі терміни, як "керований ресурс" та "некерований ресурс", на жаль, використовуються різними людьми для позначення різних речей; відверто подумайте, що корисніше думати з точки зору об'єктів як про неприйняття будь-якої відповідальності за прибирання, чи за відповідальність за очищення, за яку слід потурбуватися лише за виклику утилізації, або за відповідальність за очищення, за яку слід піклуватися через Dispose, але яка може також опікується Finalize.
Основна відмінність керованого та некерованого ресурсу полягає в тому, що збирач сміття знає про всі керовані ресурси, в певний момент часу GC зійде і очистить усю пам'ять та ресурси, пов'язані з керованим об'єктом. GC не знає про некеровані ресурси, такі як файли, потік та ручки, тому якщо ви не очистите їх явно у своєму коді, то у вас з’явиться витоки пам'яті та заблоковані ресурси.
Вкрадений звідси , сміливо читайте всю публікацію.
Будь-який ресурс, для якого виділена пам'ять у керованій купі .NET, є керованим ресурсом. CLR цілком усвідомлює подібну пам’ять і зробить усе, щоб переконатися, що вона не залишиться сиротою. Все інше некероване. Наприклад, взаємодія з COM може створити об'єкти в просторі пам'яті процесора, але CLR не буде дбати про це. У цьому випадку керований об’єкт, який здійснює дзвінки через керовану межу, повинен нести відповідальність за все, що знаходиться поза ним.
Давайте спочатку розберемося, як програми VB6 або C ++ (додатки, які не є Dotnet) використовували для виконання. Ми знаємо, що комп'ютери розуміють лише код машинного рівня. Код машинного рівня також називають нативним або двійковим кодом. Отже, коли ми виконуємо програму VB6 або C ++, відповідний компілятор мови компілює відповідний вихідний код мови у нативний код, який потім може бути зрозумілий базовій операційній системі та апаратному забезпеченню.
Рідний код (Unmanaged Code) є специфічним (рідним) для операційної системи, на якій він генерується. Якщо взяти цей скомпільований нативний код і спробувати запустити в іншій операційній системі, він не вдасться. Тому проблема з цим стилем виконання програми полягає в тому, що він не переноситься з однієї платформи на іншу.
Давайте тепер розберемося, як виконується програма .Net. Використовуючи dotnet, ми можемо створювати різні типи додатків. Кілька поширених типів програм .NET включають веб-, Windows, консольні та мобільні додатки. Незалежно від типу програми, під час виконання будь-якої програми .NET відбувається таке
Додаток .NET компілюється на проміжну мову (IL). IL також називають загальною проміжною мовою (CIL) та проміжною мовою Microsoft (MSIL). І .NET, і не .NET програми генерують збірку. Асамблеї мають розширення .DLL або .EXE. Наприклад, якщо ви компілюєте додаток Windows або Console, ви отримуєте .EXE, де, якби під час компіляції веб-проекту чи бібліотечного проекту класу ми отримували .DLL. Різниця між збіркою .NET і NON .NET полягає в тому, що збірка DOTNET знаходиться в проміжному мовному форматі, де як NON DOTNET-збірка знаходиться у форматі коду.
Програми NON DOTNET можуть працювати безпосередньо над операційною системою, де додатки DOTNET запускаються поверх віртуального середовища, що називається загальною мовою виконання (CLR). CLR містить компонент під назвою Just In-Time Compiler (JIT), який перетворить проміжну мову в основний код, який може зрозуміти базова операційна система.
Так, у .NET виконання програми складається з 2 кроків 1. Компілятор мови, компілює вихідний код у проміжний мову (IL) 2. Компілятор JIT в CLR перетворює, IL в нативний код, який потім може бути запущений в базовій операційній системі .
Оскільки збірка .NET виконується у форматі мови Intermedaite, а не є власним кодом, .NET збірки переносяться на будь-яку платформу, якщо цільова платформа має загальну мову виконання (CLR). CLR цільової платформи перетворює мову Intermedaite в нативний код, який може зрозуміти базова операційна система. Проміжну мову називають також керованим кодом. Це тому, що CLR управляє кодом, який працює всередині нього. Наприклад, у програмі VB6 розробник несе відповідальність за розподіл пам'яті, споживаної об'єктом. Якщо програміст забуде виділити пам'ять, ми можемо зіткнутися з труднощами виявити винятки з пам'яті. З іншого боку, .NET-програмісту не потрібно турбуватися про розподіл пам'яті, споживаної об'єктом. CLR забезпечує автоматичне управління пам’яттю, також відоме як збір сміття. Крім того, від вивезення сміття є кілька інших переваг, наданих CLR, про які ми поговоримо на наступній сесії. Оскільки CLR керує та виконує проміжну мову, її (IL) також називають керованим кодом.
.NET підтримує різні мови програмування, такі як C #, VB, J # і C ++. C #, VB і J # можуть генерувати лише керований код (IL), де як C ++ може генерувати як керований код (IL), так і некерований код (Native code).
Народний код не зберігається постійно ніде, після закриття програми нативний код викидається. Коли ми знову виконуємо програму, нативний код знову генерується.
Програма .NET схожа на виконання програми java. У Java у нас є байт-коди та JVM (віртуальна машина Java), де, як у .NET, ми проміжні мови та CLR (загальна мова виконання)
Про це йдеться за цим посиланням - Він чудовий вихователь. http://csharp-video-tutorials.blogspot.in/2012/07/net-program-execution-part-1.html