Вначале существовала Java. Но затем, примерно в 2000 году, появилась бета-версия .NET, возможно, из-за отказа от судебного процесса 1997 года, поданного Sun Microsystems.
Несмотря на то, что код, написанный с использованием ранней реализации C# и Java, на первый взгляд выглядел почти идентично, несколько вещей сделали .NET по-настоящему уникальным.
Хотя в Интернете есть много материалов по .NET, большая их часть содержит проблемы, такие как:
- Оно не сосредоточено исключительно на .NET (в частности, на .NET Framework).
- Несмотря на то, что в нем рассматриваются расширенные темы, в основном он охватывает базовые темы с точки зрения программирования.
В этом блоге мы сосредоточимся на основных вопросах, связанных с .NET Framework, включая некоторые, связанные с недавними обновлениями .NET, вплоть до выпуска 9. Мы постараемся не зацикливаться на деталях, связанных с языком.
Для кого нужен .NET?
Чтобы убедиться, что вопросы, затронутые в этом блоге, уникальны, мы специально выбрали вопросы, требующие навыков программирования как минимум среднего уровня и опыта программирования не менее трех лет. Хотя вопросов, касающихся конкретного языка, не существует, вам необходимо базовое понимание хотя бы одного языка программирования в .NET.
Вопросы
Итак, вам не терпится узнать больше? Давайте начнем.
Основы CLR
Вопрос 1. Каковы различные части управляемого модуля?
Давайте сначала разберемся, что такое модуль и в чем разница между управляемым и неуправляемым модулем.
Когда мы компилируем файлы исходного кода в Microsoft .NET, мы получаем модуль, будь то на любом из многочисленных поддерживаемых языков, включая C ++, C # (произносится как C Sharp), Iron Python или Visual Basic.
Управляемый модуль – это, проще говоря, стандартный переносимый исполняемый файл Windows 32 или Windows 64-разрядной версии. Единственное отличие заключается в том, что для его выполнения требуется CLR (среда выполнения common language runtime).
Управляемый модуль состоит из четырех частей: метаданных, заголовка переносимого исполняемого файла, заголовка CLR и кода IL (промежуточного языка).
Давайте кратко обсудим каждый из них далее.
Заголовок PE32 или PE32+
Заголовок файла для стандартного файла Windows основан на формате, обычно называемом Common Object File Format (COFF). В случае PE32 файл может быть выполнен либо в 32-, либо в 64-разрядной Windows. Заголовок PE32 + в файле подразумевает, что файл может быть выполнен только в 64-разрядной Windows.
Некоторые элементы в заголовке включают:
- Тип файла, например, является ли файл графическим интерфейсом, CUI или DLL
- Отметка времени, демонстрирующая время сборки
Заголовок CLR
Заголовок CLR содержит информацию, которая делает управляемый модуль тем, что он есть. Например, он может содержать версию CLR, некоторые флаги и метод точки входа в модули (например, main). Кроме того, он может содержать другие элементы, такие как определение ресурсов, флагов и местоположения метаданных модуля.
Метаданные
Одна вещь, которая отличает управляемый модуль, – это раздел метаданных, в котором размещены таблицы метаданных.
В основном они бывают двух основных типов: с описанием типа / членами, определенными в коде или упомянутыми в нем.
IL code
Это фактический код, созданный компилятором из исходного кода, который преобразуется в собственные инструкции процессора при выполнении кода.
Вопрос 2: Что такое небезопасный код и как он выполняется?
По умолчанию компилятор Microsoft создает код под названием безопасный код. Это означает, что он поддается проверке, поскольку соответствует правилам управляемого выполнения, таким как правила, связанные со сборкой мусора .Среда выполнения NET. В частности, проверка проверяет безопасность кода. Среди прочего, они включают проверку соответствия количества и типа параметров в методах и возвращаемых типах.
Однако небезопасный код может обойти эти проверки и получить прямой доступ к адресам. Таким образом, это палка о двух концах. С одной стороны, это позволяет использовать код в обход правил; при неосторожном использовании это может привести к некоторым из тех же проблем, для решения которых была разработана Microsoft .NET.
Как выполняется небезопасный код?
Из-за рисков, связанных с использованием unsafe, его необходимо пометить определенным ключевым словом или с помощью переключателя компилятора.
Способ, которым это работает, тесно связан с компилятором JIT (точно в срок), который преобразует IL в машинный код.
Для небезопасных методов JIT-компилятор имеет правильные разрешения на выполнение. Только в этом случае JIT-компилятор разрешит компиляцию и выполнение небезопасного кода.
Вопрос 3: Можете ли вы скомпилировать в машинный код и как?
Да, это можно сделать по-разному.
Во-первых, внутри называется .NET Framework Ngen.exe. Поскольку этот код предварительно скомпилирован, нет необходимости делать то же самое во время выполнения.
Затем есть .NET native, который является более новым методом.
Наконец, существует кросс-компиляция, которая позволяет создавать исполняемый код для платформы, отличной от той, на которой запущен компилятор.
Использование машинного кода имеет два конкретных преимущества. Во-первых, это может сократить время начального запуска. Во-вторых, это может сократить рабочий набор приложения, поскольку изначально скомпилированный фрагмент кода может быть передан процессам.
Вопрос 4: Что такое управляемая куча и как она работает?
Всякий раз, когда мы создаем программу, для ее создания требуются различные ресурсы. Они могут быть связаны с памятью (например, буферами), на основе экрана (например, пространством экрана), на основе сети (например, подключениями) и на основе базы данных (например, подключениями).
Если мы хотим их использовать, то они должны быть выделены в виде типа. Способ работы заключается в последовательности шагов, которые выполняются соответствующим образом:
- Во-первых, память выделяется для типа.
- Эта память установлена в исходное состояние, чтобы ресурс можно было использовать.
- Затем это используется при обращении к участникам типа.
- Ресурс закрыт для удаления.
- Сборщик мусора обычно освобождает память в конце.
Решаемая здесь проблема заключается в том, что обычные программисты, например, с опытом работы на C / C ++, привыкли делать все это независимо. Это часто приводит к утечкам памяти, когда выделенная память больше не освобождается.
Однако эти методы могут вызвать другие проблемы. Иногда программисты используют память после ее освобождения, что может легко привести к ошибкам при повреждении памяти и даже проблемам с безопасностью. Учитывая, что мы избегаем небезопасного кода, приложение практически гарантированно защищено от повреждения памяти.
Идея управляемой кучи заключается не только в устранении этих ошибок, но и в том, чтобы предоставить значительно упрощенную модель программирования, которая включает только следующие шаги:
- Распределить
- Инициализировать
- Используйте
Другими словами, нет способа или необходимости наводить порядок. Тем не менее, это не означает, что нам никогда не придется наводить порядок самим. В определенных случаях, если мы используем типы, которые нуждаются в специальной очистке, мы можем выполнить очистку как можно скорее, не дожидаясь сборщика мусора. Все, что нам нужно сделать в этом случае, это вызвать специальный метод, например, dispose . Однако, как уже говорилось, это скорее редкий сценарий, чем норма.
Вопрос 5: Существует ли какая-либо оптимизация производительности для больших объектов?
Да, в .NET есть другой механизм повышения производительности, учитывающий размер объектов. Для больших объектов, т. Е. 85 000 байт или больше, среда CLR использует другую обработку:
- Эти объекты размещены в другом адресном пространстве.
- В настоящее время, по состоянию на 2024 год, сборщик мусора не уплотняет их, поскольку это было бы значительно дорогостоящей операцией.
- Большие объекты по умолчанию считаются частью второго поколения. Учитывая, что .NET garbage collector – это сборщик мусора из поколения в поколение, с поколениями, начинающимися с 0, затем 1, затем 2. эти большие объекты, например, XML-файлы, JSON или массивы байтов, обрабатываются таким образом. Они являются частью LOH (кучи больших объектов).
Вопрос 6: Каковы режимы сборки мусора для .NET CLR?
Существует два режима сборки мусора (GC), которые использует среда CLR:
Режим рабочей станции
Режим рабочей станции настраивается исключительно для приложений, что больше подходит для клиентского режима. Поскольку он ориентирован на приложения, он обеспечит минимальную задержку для потоков приложений.
Режим сервера
В режиме сервера сборка мусора оптимизируется для обеспечения большей пропускной способности и более эффективного использования доступных ресурсов. При сборке данных предполагается, что на компьютере не выполняются другие приложения.
Это также включает разделение GC между процессорами, чтобы на каждый процессор приходилось по одному разделу GC. Более конкретно, на каждый процессор приходится один поток, и поток собирает один раздел.
Вопрос 7: Что означает размещение CLR и как это можно сделать?
Это интересно, потому что включает в себя передовые концепции взаимодействия Microsoft Windows и COM (компонентная объектная модель) на фундаментальном уровне. Прежде чем обсуждать CLR-хостинг, мы должны изучить, как Microsoft выполняет .Среда выполнения NET в Microsoft Windows.
Поскольку .NET Framework работает в Windows, он будет реализован по тем же правилам. По умолчанию CLR была создана как COM-сервер, размещенный внутри библиотеки DLL. Это означает, что стандартный интерфейс идентифицируется с помощью присвоенных ему уникальных строк, называемых GUID (глобально уникальные идентификаторы).
Как правило, это было бы создано в COM с использованием вызова функции Windows с именем CoCreateInstance. Однако для CLR это работает так, что необходимо вызывать другую функцию вместо CLRCreateInstance , которая объявлена в заголовочном файле Metahost.h. Теперь эта функция реализована в библиотеке DLL под названием shim. Задача shim (MSCorEE.dll) – определить фактическую версию среды CLR, которую нужно создать. Однако в нем нет COM-сервера CLR.
Всякий раз, когда запускается управляемый исполняемый файл, оболочка проверяет его, чтобы понять, для какой версии CLR он был собран и протестирован. Может существовать несколько установленных версий CLR.
Чтобы разместить CLR, нам просто нужно использовать CLRCreateInstance, а затем запустить любое управляемое приложение, вызвав:
AppDomain.CurrentDomain.ExecuteAssembly(assemblyName);
Хостинг CLR может быть полезен, поскольку он позволяет любому приложению предлагать эти функции и может быть написан, по крайней мере частично, на управляемом коде. Некоторые из преимуществ включают:
- Вы можете написать свой код на языке по вашему выбору.
- Код предварительно компилируется для повышения скорости, а не интерпретируется во время выполнения.
- Выполнение происходит в безопасной изолированной среде.
- Сборка мусора помогает предотвратить утечки памяти.
- Хостеры могут просто повторно использовать существующие технологии для разработки.
Вопрос 8: Что такое потоки CLR и пулы потоков и как они соотносятся с потоками Windows?
Есть две основные причины использования потоков:
- Оперативность: Во-первых, и это обычно для приложений с графическим интерфейсом, работающих на клиентской стороне, одним из ключевых способов использования потоков является сокращение времени ожидания, если основной поток занят.
- Производительность: Этот вариант использования работает как для клиента, так и для сервера. Windows планирует один поток на процессор, поэтому потоки могут легко повысить производительность приложения.
Мы также хотели бы отметить, что, хотя Microsoft изначально пыталась создать поток, отличный от Windows threads, для среды CLR, от этой идеи отказались после 2005 года. Они идентичны, но некоторые устаревшие API могут находиться внутри фреймворка.
Создание и уничтожение потока может быть трудоемкой операцией с точки зрения времени и памяти. Это также может повлиять на производительность системы, поскольку ОС должна переключать контекст между потоками.
CLR была разработана, чтобы помочь улучшить эту ситуацию, выполняя управление пулом потоков для своего собственного управляемого кода.
Итак, это работает, потому что у каждой среды CLR есть один общий пул потоков. В случае загрузки нескольких сред CLR в рамках одного процесса у каждой среды CLR есть отдельный пул.
Вопрос 9: Каковы различные шаблоны для выполнения асинхронных операций в .NET?
Доступны три шаблона для выполнения асинхронных операций, а именно асинхронный шаблон на основе задач (TAP), асинхронный шаблон на основе событий (EAP), и модель асинхронного программирования (APM).
Вопрос 10: Каковы последние версии .NET и какая область является ключевой в последних выпусках (по состоянию на 2024 год)?
Последняя версия – .NET 9, преемница .NET 8. Эта конкретная версия ориентирована на облачные приложения и повышение производительности. Она включает в себя сильные основы облачных приложений, включая производительность во время выполнения и мониторинг приложений.
В предыдущем выпуске, .NET 8, акцент на ИИ уже был расширен за пределы ML.NET на TensorPrimitives для .NET, в дополнение к подключению к ChatGPT и Enterprise date с Azure OpenAI и когнитивный поиск .NET.