Платформа .Net Framework

       В С# каждый предопределенный тип, распознанный компилятором, отображается на один встроенный тип IL. То же справедливо и в отношении Visual Basic 2008.

       3.3.3 Общая спецификация языка

       Общая спецификация языка (CLS) работает вместе с CTS для обеспечения языкового взаимодействия. CLS — это набор минимальных стандартов, которых должны придерживаться все компиляторы, ориентированные на .NET. Поскольку IL— очень богатый язык, разработчики большинства компиляторов предпочитают ограничивать возможности конкретного компилятора поддержкой только подмножества средств IL и CTS. Это нормально до тех пор, пока компилятор поддерживает все, что определено в CTS.

       Вполне  допустимо писать код, не совместимый  с CLS. Однако в этом случае не гарантируется, что скомпилированный IL-код будет полностью способным к взаимодействию.

       Например, возьмем чувствительность к регистру. IL чувствителен к регистру символов. Разработчики, которые пишут на языках, чувствительных к регистру, широко используют гибкость, которую обеспечивает эта зависимость от регистра при выборе имен переменных. Однако Visual Basic 2008 не чувствителен к регистру символов. CLS обходит эту проблему указывая, что любой CLS-совместимый код не должен включать  никаких пар имен, отличающихся только регистром. Таким образом, код Visual Basic 2008 может работать с CLS-совместимым кодом.

       Этот  пример иллюстрирует, что CLS работает двумя способами. Во-первых, это значит, что индивидуальные компиляторы недостаточно мощны, чтобы поддерживать все возможности .NET — это представляет сложность для разработчиков компиляторов других языков программирования, нацеленных на .NET. Во-вторых, это дает гарантию того, что если ограничить классы лишь CLS-совместимыми средствами то код, написанный на любом другом языке программирования, сможет использовать эти ваши классы.

       Изящество этой идеи состоит в том, что ограничения  в применении CLS-совместимых средств налагаются только на общедоступные и защищенные члены классов и на общедоступные классы. В пределах приватной реализации ваших классов вы вольны писать любой несовместимый с CLS код, поскольку код из других сборок в любом случае не имеет доступа к этой части вашего кода.

       3.3.4 Сборка мусора

       Сборщик мусора— это ответ .NET на вопросы управления памятью, в частности, на вопрос о том, что делать с восстановлением памяти, которую запрашивает приложение. До настоящего времени на платформе Windows использовались две технологии освобождения памяти, выделенной системой по динамическим запросам:

• возложение этой задачи на код приложения;
• поддержка счетчиков ссылок на объекты.

       Возложение  ответственности за освобождение памяти на код приложения — это техника, используемая низкоуровневыми высокопроизводительными  языками, такими как C++. Это эффективно и обладает тем преимуществом, что (в общем случае) ресурсы никогда  не бывают занятыми дольше, чем это  необходимо. Однако большой недостаток такого подхода состоит в том, что он часто порождает ошибки. Код, запрашивающий память, также обязан явно информировать систему, когда он перестает в ней нуждаться. Однако об этом очень легко забыть, что приводит к утечкам памяти.

       Хотя  современные среды разработки предлагают инструменты, помогающие обнаружить такие утечки, все же они пропускают ошибки, которые очень трудно отследить, поскольку они никак не проявляются до тех пор, пока не утечет настолько много памяти, что Windows откажет процессу в распределении новой. И в такой момент весь компьютер начнет заметно "тормозить" при каждом обращении к памяти.

       Поддержка счетчиков ссылок— это техника, используемая в СОМ. Идея заключается в том, что каждый компонент СОМ поддерживает счетчик клиентов, которые в данный момент ссылаются на него. Когда значение счетчика падает до нуля, компонент может уничтожить себя и освободить ассоциированную с ним память и ресурсы. При таком подходе проблема сводится к обязанности клиента "корректно себя вести" и вовремя извещать компонент о том, что он завершил с ним работать. Стоит одному клиенту не сделать этого, и объект останется в памяти. Иногда эта проблема потенциально более серьезна, чем простая утечка памяти в C++, потому что СОМ-компонент может существовать внутри своего собственного процесса, а это значит, что он никогда не будет удален системой (по крайней мере, что касается утечек памяти C++, то система может запросить обратно всю память процесса, когда он завершится).

       Вместо  всего этого .NET полагается на сборщик мусора. Это программа, предназначенная для того, чтобы очищать память. Идея состоит в том, что вся динамически выделяемая память распределяется в области кучи (это верно для всех языков, хотя в случае .NET CLR поддерживает свою собственную управляемую кучу для использования приложениями .NET). Всякий раз, когда .NET обнаруживает, что управляемая куча данного процесса заполнилась и нуждается в приведении в порядок, он вызывает сборщик мусора. Этот сборщик мусора проходит по всем переменным, находящимся в контексте вашего кода, и проверяет ссылки на объекты, расположенные в области кучи, чтобы идентифицировать, какие из них доступны из кода, т.е., чтобы узнать, на какие объектов существуют ссылки. Любой объект с отсутствием ссылок рассматривается как такой, к которому больше не будет осуществляться доступ из кода, потому объект может быть удален. Подобный механизм сборки мусора применяется и в Java.

       Сборка  мусора работает в .NET, потому что IL спроектирован так, чтобы облегчить этот процесс. Принципы организации IL гласят, что вы не можете получить ссылки на существующий объект иначе, кроме как копированием существующих ссылок, а также то, что IL — язык безопасный к типам. Таким образом, если существует какая-то ссылка на объект, то в этой ссылке содержится информация, достаточная для того, чтобы в точности определить тип объекта.

       Механизм  сборки мусора невозможно применить  с таким языком, как, например, неуправляемый C++, потому что C++ допускает свободное  приведение указателей к другим типам.

       Одно  важное свойство сборки мусора заключается  в том, что это недетерминированный процесс. Другими словами, вы не можете знать, когда будет вызван сборщик мусора; он будет вызван тогда, когда CLR решит, что в этом есть необходимость, хотя также возможно переопределить этот процесс и вызвать сборщик мусора из кода вашего приложения.

       3.3.5 Безопасность

       Механизм  безопасности .NET превосходит механизмы безопасности, предоставляемые Windows, поскольку обеспечивает защиту на уровне кода, в то время как Windows на самом деле обеспечивает только безопасность на уровне ролей.

       Безопасность, основанная на ролях (role-based security), базируется на идентификации учетной записи, под которой работает процесс (т.е., кто запускает процесс и владеет им). Безопасность на уровне кода, с другой стороны, основана на том, что именно делает код, и насколько ему можно доверять. Благодаря строгой типизации IL, CLR может инспектировать код перед его запуском с тем, чтобы определить необходимые полномочия безопасности. .NET также предлагает механизм, с помощью которого код может наперед запросить необходимые для работы привилегии.

       Важность  безопасности, основанной на коде (code-based security), в том, что она снижает риск, связанный с кодом сомнительного происхождения (такого, каким может быть код, загруженный из Internet). Например, даже если код выполняется от имени учетной записи администратора, остается возможность использовать защиту уровня кода, чтобы указать, что данному коду не разрешено выполнять действия определенного рода, которые обычно разрешены привилегированному пользователю (администратору) - такие как чтение и запись переменных окружения, чтение и запись регистра или доступ к средствам рефлексии .NET.

         3.3.6 Домены приложений

       Домены  приложений (application domains) — важное нововведение .NET, предназначенное для снижения накладных расходов, связанных с запуском приложений, которые должны быть изолированы друг от друга, но при этом нуждаются во взаимодействии между собой. Классический пример этого — приложения Web-сервера, которые могут совместно отвечать на множество запросов браузеров, а потому должны, вероятно, иметь экземпляры компонента, ответственного за параллельное обслуживание таких запросов.

       Во  времена, предшествовавшие появлению .NET, приходилось выбирать между тем, чтобы позволить этим экземплярам разделять один и тот же процесс (в результате рискуя прекращением работы всего Web-сайта в случае возникновения проблем с одним выполняющимся экземпляром), и изолированием этих экземпляров в отдельных процессах, что приводило к росту накладных расходов и снижению производительности.

       До  последнего времени изоляция кода была возможна только между процессами. Когда запускается новое приложение, оно работает в контексте процесса. Windows изолирует процессы друг от друга посредством адресных пространств. Идея состоит в том, что каждому процессу предоставляется 4 Гбайт виртуальной памяти, в которой он сохраняет свои данные и исполняемый код (4 Гбайт — это для 32-разрядных систем, 64-разрядные системы используют больший объем памяти). Windows вводит дополнительный уровень переадресации, благодаря которому эта виртуальная память отображается на определенную область реальной физической памяти или дисковое пространство. Каждый процесс получает свое отображение, при этом гарантируется, что не случится никакого перекрытия между реальными физическими областями памяти, выделенными каждому из них (рис. 1.2).

       В общем случае любой процесс может  обратиться к памяти только по адресу виртуальной памяти — процессы не имеют прямого доступа к физической памяти. А потому попросту невозможно одному процессу получить доступ к памяти, выделенной для другого. Это гарантирует, что никакой код, который "плохо" себя ведет, не сможет повредить ничего вне собственного адресного пространства.

       Но  процессы не только служат для изоляции друг от друга экземпляров работающего кода. В системах Windows NT/2000/XP/2003/Vista они также формируют элементы, которым назначаются права доступа и привилегии безопасности. Каждый процесс снабжен своей собственным маркером доступа (security token), который указывает системе, какие именно действия разрешено выполнять этому процессу. 

Рис. 1.2. Отображение виртуальной памяти процессов на физическую память 

       Хотя  процессы удобны для обеспечения  безопасности, все же они имеют  серьезный недостаток, связанный с производительностью. Часто бывает так, что множество процессов работают вместе и потому нуждаются в общении друг с другом. Очевидный пример этого — это когда процесс вызывает СОМ-компонент, который является исполняемым, а потому запускает свой собственный процесс. То же случается в СОМ, когда используется "заместитель" (surrogate). Поскольку процесс не может разделить память с другими, должен быть применен сложный процесс маршалинга для копирования данных между процессами. В результате ощутимо страдает производительность. Если вам нужно, чтобы компоненты работали вместе без снижения производительности, то вам следует использовать компоненты, основанные на DLL, чтобы все работало в одном адресном пространстве, подвергаясь риску, что один плохо себя ведущий компонент разрушит все остальные.

       Домены  приложений спроектированы как способ разделения компонентов без сопутствующих проблем снижения производительности, связанных с передачей данных между процессами. Идея заключается в том, что каждый процесс разделяется на несколько доменов приложений. Каждый домен приложения приблизительно соответствует отдельному приложению, и каждый поток выполнения запускается в определенном домене приложения (рис. 1.3).

       Если  разные исполняемые программы запускаются  в одном пространстве процесса, то вполне понятно, что они могут легко разделять общие данные, потому что теоретически в состоянии напрямую видеть данные друг друга. Однако, хотя такая возможность существует в принципе, CLR обеспечивает, чтобы это не случалось на практике, инспектируя код каждого работающего приложения, дабы гарантировать, что код не выйдет за пределы области своих собственных данных. 

Рис. 1.3. Домены приложений 

       На  первый взгляд этот трюк кажется почти  невозможным. Однако, на самом деле, обычно это сделать возможно, благодаря строгой защите типов IL. В большинстве случаев, если только код не применяет небезопасных средств, таких как указатели, то используемые им типы данных гарантируют, что не произойдет никаких неправильных обращений к памяти. Например, типы массивов .NET предусматривают проверку границ, чтобы не допустить никаких действий за границами массива. Если функционирующее приложение нуждается во взаимодействии или разделении данных с другим работающим приложением, оно должно делать это посредством вызова удаленных служб.