Платформа Microsoft и язык программирования C#

1.

Платформа Microsoft .NET
и язык программирования C#

2.

Платформа Microsoft .NET —
это технология, которая
поддерживает создание и
выполнение
приложений различных типов

3.

Причины возникновения
платформы
Microsoft .NET Framework

4.

Одна из идей Microsoft объединение различных
программных технологий в
унифицированную платформу

5.

Это позволит разрабатывать
приложения различных типов:
• Консольные приложения
• Оконные графические приложения
• Мобильные приложения
• Web-приложения
• Web-сервисы

6.

Важной идеей разработки .NET
Framework было стремление
сделать кроссплатформенную
виртуальную машину для
выполнения одного и того же
кода в различных ОС

7.

Но со временем Microsoft
ограничилась поддержкой
только своих операционных
систем Windows

8.

Поддержкой некоторых других
операционных систем занимаются
независимые разработчики

9.

Реализация платформы.NET
на базе свободного
программного обеспечения
• Проект Mono
• Xamarin.iOS
• DotGNU Portable.NET
• Xamarin.Android

10.

Недостатки
Microsoft.NET Framework
• Теоретическая
кроссплатформенность
• Более медленное выполнение
программы по сравнению с
программой, написанной не для
.NET Framework

11.

Версии платформы
.NET Framework
• 1.0 (1 мая 2002 года)
• 1.1 (1 апреля 2003 года)
• 2.0 (11 июля 2005 года)
• 3.0 (6 ноября 2006 года)
• 3.5 (9 ноября 2007 года)
• 4.0 (12 апреля 2010 года)
• 4.5 (15 августа 2012 года)
• 4.5.1 (17 октября 2013 года)

12.

Версии платформы
.NET Framework
• 4.5.2 (5 мая 2014 года)
• 4.5.3 (3 октября 2014 года)
• 4.6 (20 июля 2015 года)
• 4.6.1 (17 ноября 2015 года)
• 4.6.2 (20 июля 2016 года)
• 4.7 (5 апреля 2017 года)
• 4.7.1 (17 октября 2017 года)
• 4.7.2 (30 апреля 2018 года)
• 4.8 (18 апреля 2019 года)

13.

Компоненты
Microsoft.NET Framework
• Common Language Runtime (CLR) общеязыковая среда исполнения
• Framework Class Library (FCL) библиотека классов .NET Framework
• Common Type System (CTS) стандартная система типов
• Common Language Specification (CLS)
- общая спецификация языка

14.

Common Language Runtime виртуальная программная среда
(виртуальная машина) для
исполнения приложений .NET

15.

CLR, в основе которой лежит
виртуальный высокоуровневый
процессор, реализует работу с
памятью, процессами, потоками
и остальным окружением

16.

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

17.

Виртуальная машина CLR
обеспечивает эффективное и
контролируемое исполнение кода
приложений .NET

18.

CLR физически имеет вид
библиотеки mscoree.dll (Common
Object Runtime Execution Engine)

19.

Исходный текст программы,
написанный на любом языке
программирования для .NET,
переводится компилятором в
исполняемый файл, который
называется сборкой (.exe или .dll)

20.

Assembly (сборка .NET)

21.

Составные части сборки
• Код, написанный на
промежуточном языке CIL
(Common Intermediate Language)
• Метаданные
• Манифест

22.

Common Intermediate Language «высокоуровневый ассемблер»
виртуальной машины .NET

23.

Common Intermediate Language

24.

CIL-код содержит инструкции,
независимые ни от языка
программирования, ни от ОС,
ни от процессора

25.

Платформа .NET предлагает
управляемую среду выполнения
приложений, в основании
которой лежит виртуальный
высокоуровневый процессор

26.

Виртуальный процессор
исполняет высокоуровневые
инструкции языка CIL (объектноориентированный код)

27.

Например, высокоуровневая
инструкция создания объекта
класса или инструкция вызова
определенного метода

28.

Метаданные – сведения о том,
какие объекты, типы данных,
классы, методы, свойства
используются в сборке

29.

30.

Они позволяют организовать
межъязыковое
взаимодействие, обеспечивают
безопасность и облегчают
развертывание приложений

31.

Манифест – это сведения о
самой сборке (номер версии
сборки, языковые настройки,
список других внешних сборок,
необходимых для нормальной
работы программы и т.д.)

32.

При выполнении сборки (.exe)
виртуальная машина CLR использует
JIT-компилятор (Just-In-Time),
который переводит исполняемый
файл на языке CIL в исполняемый
машинно-зависимый код

33.

34.

Схема
компиляции
приложения
в .NET
Framework

35.

Важно понимать, что сборка
транслируется не целиком, а по
частям по мере необходимости

36.

Уже откомпилированные части
программы сохраняются в кэше
для последующего использования

37.

Неделимая единица
компиляции - функция

38.

Управляемый (безопасный) код –
это код, который выполняется
под управлением общеязыковой
среды CLR

39.

Любое приложение, написанное
под .NET Framework – это и есть
управляемый код

40.

Неуправляемый (небезопасный
код) – это приложение,
написанное не для платформы
.NET Framework (например,
программа на С++
с использованием Windows API)

41.

Платформа .NET предоставляет
возможности для взаимодействия
с неуправляемым кодом

42.

Управляемый и неуправляемый код

43.

Таким образом, среда CLR
исполняет управляемый CIL-код,
оперируя высокоуровневыми
сущностями (объектами)

44.

В этом заключается идея
высокоуровневого виртуального
процессора

45.

В то же время среда исполнения
неуправляемого кода выполняет
низкоуровневые инструкции
процедурного кода
(машинно-зависимый код)

46.

Машинный код

47.

Это главное отличие среды
исполнения CLR от среды
исполнения неуправляемого кода

48.

В каждой конкретной сборке
может содержаться любое
количество различающихся типов

49.

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

50.

CTS (общая система типов)
описывает все типы и
программные конструкции,
поддерживаемые CLR и
доступные в CIL

51.

Все компиляторы языков,
ориентированные на среду .NET,
генерируют CIL-код, который
базируется на CTS

52.

CTS обеспечивает строгую
типизацию данных для
межъязыкового взаимодействия

53.

Например, Integer в VB.NET,
int в C# - безопасные типы
отображаются на System.Int32,
а char* - небезопасный тип

54.

CTS (общая система типов)

55.

Важно понимать, что
конкретный язык, совместимый
с .NET, может и не
поддерживать абсолютно все
возможности, определенные CTS

56.

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

57.

Такой набор описывается
общеязыковой спецификацией
CLS (Common Language
Specification)

58.

CLS – набор правил, которые
определяют подмножество общих
типов и программных
конструкций, понятных всем
языкам программирования,
совместимым с Microsoft.NET

59.

CLS как подмножество CTS

60.

CLS – набор правил, которых
должны придерживаться
производители компиляторов,
чтобы их продукты работали в .NET

61.

CLS как подмножество CTS
требует от создателей
компиляторов обязательной
поддержки библиотекой
базовых классов (BCL)

62.

BCL (Base Class Library) библиотека базовых классов
платформы Microsoft.NET

63.

Программы, написанные на
любом из языков,
поддерживающих платформу
Microsoft.NET, должны иметь
возможность пользоваться
всеми классами BCL

64.

BCL, по сути, представляет
собой API платформы .NET

65.

Вся библиотека базовых классов
поделена на ряд отдельных
сборок, главной среди которых
является сборка mscorlib.dll

66.

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

67.

Также достаточно много классов
находится в сборке system.dll

68.

В частности, BCL предоставляет
средства базового доступа к
файлам, коллекции, потоки
ввода-вывода, средства работы
со строками и многое другое

69.

Framework Class Library—
стандартная библиотека классов
платформы Microsoft.NET,
которая предоставляет
разнообразный набор сервисов

70.

FCL расширяет возможности BCL
и относится ко всей библиотеке
классов, которая поставляется с
платформой .NET Framework

71.

FCL содержит расширенный
набор библиотек, включая
ASP.NET, WinForms, WPF, XML,
ADO.NET и другие

72.

73.

В отличие от BCL, языки,
поддерживающие платформу
.NET, не обязаны предоставлять
одинаково полный доступ ко всем
классам и всем возможностям FCL

74.

Microsoft .NET Core

75.

В настоящее время Microsoft
развивает альтернативную
платформу .NET Core, которая
изначально предполагает
кроссплатформенную
разработку и эксплуатацию

76.

Платформа .NET Core основана
на платформе .NET Framework

77.

.NET Core — это модульная
платформа для разработки
программного обеспечения с
открытым исходным кодом

78.

Каждый компонент .NET Core
обновляется через менеджер
пакетов NuGet

79.

Это означает, что можно
обновлять её модули по
отдельности

80.

В то время как .NET Framework
обновляется целиком

81.

Каждое приложение .NET Core
может работать с разными
модулями и не зависит от
единого обновления платформы

82.

Платформа .NET Core отличается
.NET Framework
кроссплатформенностью

83.

.NET Core совместима с такими
операционными системами
как Windows, Linux и macOS

84.

Версии платформы
.NET Core
• .NET Core 1.0 (27 июня 2016 года)
• .NET Core 1.1 (16 ноября 2016 года)
• .NET Core 2.0 (14 августа 2017 года)
• .NET Core 2.1 (30 мая 2018 года)
• .NET Core 3.0 (23 сентября 2019 года)
• .NET Core 3.1 (3 декабря 2019 года)
• .NET 5.0 (20 ноября 2020 года)
• .NET 6.0 (8 ноября 2021 года)

85.

Следующие версии будут
называться .NET (без
использования "Core" в названии),
что символизирует объединение
Mono и .NET Framework

86.

Компоненты
Microsoft.NET Core
• CoreFX - это библиотека классов,
интегрированная в .NET Core
• CoreCLR - это среда выполнения,
включающая в себя JIT-компилятор,
встроенный сборщик мусора и другие
компоненты

87.

Рефлекторы и дотфускаторы

88.

CIL-код по сравнению
с машинным кодом легче
«поддаётся» декомпиляции

89.

Т.е. восстановлению оригинального
текста программы из текста
исполняемого файла

90.

Технология .NET
реализуют возможность
«отражения» типов данных —
получение информации о типах
данных во время выполнения
программы

91.

В терминологии .NET
этот процесс называется
Reflection — «отражение»

92.

Рефлектор - программа,
позволяющая просматривать
содержимое .NET-сборок

93.

Рефлектор интересен,
как с точки зрения анализа
программного решения, так
и с точки зрения тестирования
приложения на этапе разработки

94.

Возможность применения
рефлектора делает .NET-проекты
уязвимыми с точки зрения «Права
интеллектуальной собственности»

95.

Программные продукты, которые
легко декомпилируются,
открывают все возможности
обратной инженерии

96.

Однако открытый код можно
защитить

97.

Для этой цели были созданы
программные продукты дотфускаторы (dotfuscators)

98.

Данный процесс состоит из
набора методов запутывания кода

99.

Выделяют следующие методы
запутывания:
• запутывание разметки кода
(изменение форматирования
исходного кода, переименование
идентификаторов);
• запутывание данных;
• запутывание конструкций
управления кодом.

100.

Код программных решений
необходимо защищать
от методов обратной инженерии,
особенно если эти решения
являются коммерческими

101.

Объектно-ориентированный язык
разработки приложений для
платформы Microsoft .NET

102.

103.

104.

Все типы платформы .NET
делятся на две категории:
значимые (value) и ссылочные
(reference)

105.

106.

Представителем ссылочного
типа на платформе .NET
является класс

107.

Представителем значимого
типа на платформе .NET
является структура

108.

Главное отличие между
ними состоит в следующем

109.

Когда операция присваивания
применяется к переменной
значимого типа, создается
независимая копия переменной

110.

Когда операция присваивания
применяется к переменной
ссылочного типа, создается
копия ссылки

111.

112.

При передаче в метод по
значению переменной
значимого типа создается
независимая копия переменной

113.

При передаче в метод по
значению переменной
ссылочного типа создается
копия ссылки

114.

Объект ссылочного типа всегда
создается в управляемой куче

115.

Сама ссылка создается в
стеке, если она является
локальной переменной метода

116.

117.

Либо ссылка создается в куче,
если она является полем класса

118.

Объект значимого типа
создается в стеке, если он
является локальной
переменной метода

119.

120.

Объект значимого типа
создается в куче, если он
является полем класса

121.

Массивы в .NET

122.

Все массивы неявно
наследуются от класса
System.Array

123.

Массивы бывают одномерные,
многомерные и зубчатые

124.

Одномерный массив

125.

Многомерный массив

126.

Зубчатый массив

127.

Тип System.String

128.

Объект класса String
неизменяем (immutable)

129.

Созданную однажды строку
нельзя сделать длиннее или
короче, в ней нельзя
изменить ни одного символа

130.

Благодаря неизменности
строк отпадает проблема
синхронизации потоков при
работе со строками

131.

Для конкатенации нескольких
строк на этапе выполнения
оператор + применять
нежелательно, так как он создает в
куче несколько строковых объектов

132.

Вместо него рекомендуется
использовать тип
System.Text.StringBuilder

133.

Производительность String

134.

По соображениям
производительности тип String
тесно интегрирован с CLR

135.

В частности, CLR «знает»
точное расположение полей в
этом типе и обращается
к ним напрямую

136.

За повышение
производительности и прямой
доступ приходится платить
небольшую цену: класс String
является запечатанным (sealed)

137.

Иначе, имея возможность описать
собственный тип, производный от
String, можно было бы добавлять
свои поля, противоречащие
структуре String и нарушающие
работу CLR

138.

Интернирование строк

139.

В CLR несколько ссылок типа
String могут указывать на один, а
не на несколько разных строковых
объектов, если строки идентичны

140.

Это связано с тем, что хранение в
памяти нескольких экземпляров
одной строки приводит к
непроизводительным затратам
памяти — ведь строки неизменяемы

141.

Эффективного использования
памяти можно добиться, если
держать в ней одну строку, на
которую будут указывать
соответствующие ссылки

142.

С этой целью для повышения
производительности применяется
механизм интернирования строк
(string interning)

143.

Перегрузка операторов –
возможность интегрировать
пользовательский тип данных в
язык программирования

144.

Перегрузка операторов дает
возможность определить
собственные действия для
стандартных операций, применяемых
к объектам пользовательского типа

145.

Перегрузка операторов
осуществляется только
статическими методами класса

146.

Общий синтаксис перегрузки
операторов
public static тип operator знак_операции (параметры)
{
< тело функции >
}

147.

Ограничения
• Нельзя перегружать операции для
стандартных типов
• Нельзя создавать новые названия
операций
• Перегрузка не меняет приоритет
операций
• Для той или иной операции нельзя
изменить количество операндов

148.

Запрещенные к перегрузке
операторы
• = - оператор присваивания
• sizeof - оператор определения
размера объекта
• . - оператор выбора
• ?: - условный тернарный оператор
• [ ] - оператор индексирования

149.

Запрещенные к перегрузке
операторы
• is -оператор проверки совместимости
результата выражения с указанным типом
• as - оператор преобразования результата
выражения в указанный ссылочный тип
• typeof - оператор получения объекта
System.Type для указанного типа
• new - оператор создания объекта

150.

С концептуальной точки зрения
перегрузка операторов – частный
случай статического полиморфизма

151.

Возможность одновременного
существования в одной области
видимости нескольких различных
вариантов применения оператора

152.

Абстрагирование от конкретных
типов параметров на этапе
компиляции программы

153.

Абстрактные классы и
интерфейсы

154.

Базовый класс, который
содержит хотя бы один
абстрактный метод называется
абстрактным базовым классом

155.

Абстрактный класс может
использоваться только в
качестве базового для других
классов — объекты абстрактного
класса создавать нельзя

156.

Если производный класс наследует
абстрактный класс, в нем должны
быть реализованы все абстрактные
методы базового класса

157.

В противном случае производный
класс должен быть также
определен как абстрактный

158.

Абстрактный класс можно
рассматривать как заготовку, в
которой часть функциональности
реализована, а оставшаяся часть
делегирована потомкам

159.

Интерфейс - это публичный
контракт

160.

Класс (или структура) может
реализовывать несколько
интерфейсов

161.

Если класс реализует
интерфейс, то это должно быть
сделано полностью

162.

Реализовать интерфейс
выборочно или по частям
нельзя

163.

В интерфейсе все методы неявно
подразумеваются как public

164.

Соответственно, в классе,
реализующем интерфейс, все
интерфейсные методы должны
быть объявлены как public

165.

Один интерфейс может
наследовать другой

166.

В отличие от классов, один
интерфейс может наследовать
сразу несколько базовых
интерфейсов

167.

Структуры в C#/CLR

168.

В отличие от C++, структуры в
C#/CLR заметно отличаются от
классов в сторону уменьшения
функциональности

169.

В частности, структуры не
поддерживают наследование, а
значит не поддерживают
динамический полиморфизм

170.

Однако структуры, как и классы,
могут реализовывать интерфейсы

171.

Спецификатор доступа в C#/CLR
для членов структуры по
умолчанию такой же, как
у классов - private

172.

В структурах можно создавать
любые конструкторы, кроме
конструктора по умолчанию

173.

Следствие невозможности
переопределить конструктор по
умолчанию: поля структуры
нельзя проинициализировать при
их объявлении

174.

Зачем же тогда нужны структуры,
если есть классы, которые умеют
больше?

175.

Использование экземпляров
структур, в случае их размещения
в стеке, обеспечивает большую
производительность

176.

Нет необходимости
разыменовывать ссылки на
объекты, хранящиеся в
динамической памяти и не
нагружается сборщик мусора

177.

Делегаты и события

178.

Делегат - это класс, объект
которого может ссылаться на
метод того или иного класса

179.

По сути, делегат является
абстракцией указателя на функцию

180.

Любой делегат способен
вызывать свои методы синхронно
или асинхронно

181.

Делегат - это сгенерированный
компилятором запечатанный
класс, унаследованный от
System.MulticastDelegate

182.

В свою очередь,
System.MulticastDelegate
унаследован от System.Delegate

183.

Напрямую наследовать класс
делегата от Delegate или
MulticastDelegate нельзя

184.

Экземпляр делегата является
неизменяемым (immutable)
объектом

185.

Делегаты используются для
передачи методов в качестве
аргументов в другие методы

186.

Событие – это механизм
автоматического уведомления о
том, что в зоне ответственности
класса, которому принадлежит
событие, произошло некоторое
изменение

187.

События основаны на делегатах и
являются реализацией паттерна
Observer на платформе .NET

188.

Анонимная функция –это
безымянный метод, полностью
определенный внутри другого
метода

189.

Основное назначение анонимной
функции – упрощение классов за
счет того, что отпадает
необходимость объявлять
отдельный метод, единственное
назначение которого состоит в
том, что он передается делегату

190.

Важно понимать, что анонимная
функция имеет тип делегата

191.

Анонимная функция – это
безымянный блок кода,
передаваемый конструктору
делегата

192.

Анонимные функции реализуют
идею замыкания

193.

Замыкание – это анонимная
функция, находящаяся целиком в
теле другого метода и
захватывающая локальные
переменные этого внешнего
метода в свой контекст

194.

Реализованы две разновидности
анонимных функций –
анонимные методы (C# 2.0) и
лямбда-выражения (C# 3.0)

195.

Рефлексия (отражение) - это
механизм программного
получения метаданных любого
типа в виде объектной модели
во время выполнения

196.

Рефлексия позволяет
создавать более гибкие и
компактные приложения

197.

Возможность получения
метаданных во время выполнения
программы позволяет расширять
её функциональность

198.

Атрибут - это специальный класс,
при помощи которого можно
добавить в сборку
дополнительную информацию
(метаданные)

199.

Атрибут унаследован от базового
класса Attribute

200.

Атрибут обеспечивают эффективный
способ связывания метаданных с
кодом и может быть получен при
помощи механизма рефлексии

201.

Сериализация - это процесс
сохранения состояния
объекта в любом потоке с
возможностью его последующего
восстановления

202.

При этом сохраненная
последовательность байт содержит
всю необходимую информацию для
восстановления этого объекта

203.

Использование этой технологии
намного облегчает процесс
сохранения и извлечения больших
объемов данных приложения в
самых разных форматах

204.

Важно понимать, что когда объект
сохраняется в потоке, все
соответствующие данные (базовые
классы, вложенные объекты и т.п.)
тоже автоматически сохраняются

205.

Таким образом, при попытке
выполнить сериализацию
производного класса в этом
процессе будет задействована вся
цепочка наследования

206.

Множество взаимосвязанных
объектов при сериализации
представляется в виде графа
объектов

207.

Службы сериализации позволяют
сохранить полученный граф
объектов в самых разных форматах:
двоичном формате, формате SOAP,
формате XML или в формате JSON

208.

Сборщик мусора

209.

Работа сборщика мусора
основана на алгоритме
"пометки и сжатия"

210.

Объекты, используемые на
момент сборки мусора,
помечаются, а все остальные
объекты считаются ненужными
и будут освобождены (удалены)

211.

Отбор всех достижимых объектов
(на которые ещё существуют
ссылки) обходится дорого

212.

Сборщик мусора с поддержкой
поколений (generational garbage
collector) работает на основе
следующих предположений

213.

Чем младше объект, тем короче
его время жизни

214.

Чем старше объект, тем длиннее
его время жизни

215.

Сборка мусора в части кучи
выполняется быстрее, чем
во всей куче

216.

Для воплощения этих идей в
сборщике мусора реализована
концепция поколений
(generations)

217.

Управляемая куча разделена
на три поколения: нулевое,
первое и второе

218.

Поколение 0 составляют
объекты, никогда не
проходившие сборку мусора

219.

Объекты поколения 1
пережили одну сборку мусора, а
объекты поколения 2 прошли
сборку мусора несколько раз

220.

Размеры поколений:
•0-е поколение - 256 Кб (зависит от
кэша второго уровня процессора)
•1-е поколение - 2 Мб
•2-е поколение - 10 Мб

221.

Допустим только что запущенное
приложение создало пять объектов
(А–Е). Через некоторое время объекты
С и Е становятся недоступными.

222.

Если в результате выделения
памяти для нового объекта
размер поколения 0 превышает
пороговое значение, должна
начаться сборка мусора

223.

Допустим, объекты А–Е относятся
к поколению 0. Тогда при
создании объекта F должна
начаться сборка мусора.

224.

Сборщик мусора определяет,
что объекты С и E — это мусор,
и выполняет сжатие памяти для
объекта D, перемещая его
вплотную к объекту B

225.

Объекты, пережившие
сборку мусора (А, В и D),
становятся поколением 1. Объекты
из поколения 1 были проверены
сборщиком мусора один раз.

226.

После сборки мусора объектов в
поколении 0 не остается

227.

Туда в дальнейшем помещаются
новые объекты

228.

Допустим приложение продолжает
работу и создает новые объекты
(F–K). В ходе работы приложения
становятся недоступными объекты
B, H и J.

229.

При попытке размещения объекта L
размер поколения 0 превысил
пороговое значение, поэтому
должна начаться сборка мусора

230.

Сборщик мусора будет проверять
только объекты поколения 0

231.

Все объекты из поколения 0,
пережившие сборку мусора,
перешли в поколение 1

232.

Сборщик мусора с поддержкой
поколений предполагает, что
объекты, прожившие достаточно
долго, продолжат жить и дальше

233.

Следовательно, сборка мусора в
поколении 1, скорее всего,
окажется пустой тратой времени

234.

Так как сборщик не проверяет
поколение 1, память, занятая
объектом В, не освобождается,
даже если этот объект на момент
сборки мусора недоступен

235.

Допустим, приложение работает
дальше и выделяет память под
новые объекты (L–O)

236.

Во время работы приложение
прекращает использовать
объекты G, L и M, и они
становятся недоступными

237.

Допустим, в результате
размещения объекта P размер
поколения 0 превысил
пороговое значение, что
инициировало сборку мусора

238.

Сборщик вновь решает собрать
мусор только в поколении 0,
игнорируя недоступные объекты в
поколении 1 (B и G)

239.

Поколение 1 постепенно растет

240.

Приложение продолжает работать
и создает новые объекты (P–S),
которые заполняют поколение 0
до его порогового значения

241.

Допустим, в результате
размещения объекта T размер
поколения 0 превысил
пороговое значение, что вновь
инициировало сборку мусора

242.

Все объекты из поколения 0,
пережившие сборку мусора, должны
перейти в поколение 1 (Q и S)

243.

Однако поколение 1
выросло до таких размеров, что
все его объекты в совокупности
превысили пороговое значение

244.

Поэтому теперь сборщик мусора
проверяет все объекты поколения 1

245.

Все выжившие объекты
поколения 0 теперь находятся в
поколении 1, а все выжившие
объекты поколения 1 — в
поколении 2

246.

Как всегда, сразу после сборки
мусора поколение 0 пустеет: в нем
будут размещаться новые объекты

247.

Если сборщик видит, что после
сборки мусора в поколении 0
остается очень мало выживших
объектов, он может снизить порог
для поколения 0

248.

В этом случае сборка
мусора будет выполняться чаще,
но это меньше загрузит сборщик

249.

В то же время, если после
обработки поколения 0 сборщик
мусора обнаруживает множество
выживших объектов, значит,
удается освободить мало памяти

250.

В этом случае сборщик мусора
может поднять порог для
поколения 0

251.

В результате сборка
мусора выполняется реже, но
каждый раз будет освобождаться
значительный объем памяти

252.

Модель явного освобождения
ресурсов (Паттерн Disposable)

253.

Получение ресурса есть
инициализация (Resource
Acquisition Is Initialization (RAII)) —
паттерн (программная идиома)

254.

Этот паттерн предполагает
получение некоторого ресурса в
момент создания и инициализации
объекта, а освобождение ресурса
— с уничтожением объекта

255.

Паттерн Disposable- это способ
реализации паттерна RAII в .NET

256.

Паттерн необходим для
освобождения захваченных
ранее ресурсов

257.

Для реализации этого паттерна в
.NET используются интерфейс
IDisposable и конструкция using()