На элемент вторичного параметра не могут ссылаться элементы находящиеся вне его

Ограничения первичных и внешних ключей

Первичные ключи и внешние ключи — это два типа ограничений, которые можно использовать для обеспечения целостности данных в таблицах SQL Server. Это важные объекты базы данных.

Ограничения первичного ключа

Обычно в таблице есть столбец или сочетание столбцов, содержащих значения, уникально определяющие каждую строку таблицы. Этот столбец, или столбцы, называются первичным ключом (PK) таблицы и обеспечивает целостность сущности таблицы. Так как ограничения первичного ключа гарантируют уникальные данные, они часто определяются в столбце удостоверений.

При указании ограничения первичного ключа для таблицы ядро СУБД обеспечивает уникальность данных путем автоматического создания уникального индекса для столбцов первичного ключа. Этот индекс также обеспечивает быстрый доступ к данным при использовании первичного ключа в запросах. Если ограничение первичного ключа задано более чем для одного столбца, то значения могут дублироваться в пределах одного столбца, но каждое сочетание значений всех столбцов в определении ограничения первичного ключа должно быть уникальным.

Как показано на следующем рисунке, столбцы ProductID и VendorID в таблице Purchasing.ProductVendor формируют составное ограничение первичного ключа для этой таблицы. При этом гарантируется, что каждая строка в таблице ProductVendor имеет уникальное сочетание значений ProductID и VendorID . Это предотвращает вставку повторяющихся строк.

• В таблице возможно наличие только одного ограничения по первичному ключу.
• Первичный ключ не может превышать 16 столбцов и общую длину ключа 900 байт.
• Индекс, созданный ограничением первичного ключа, не может привести к тому, что число индексов таблицы превышает 999 некластеризованных индексов и 1 кластеризованных индексов.
• Если кластеризованный или некластеризованный не указан для ограничения первичного ключа, кластеризованный используется, если в таблице нет кластеризованного индекса.
• Все столбцы с ограничением первичного ключа должны быть определены как не допускающие значения NULL. Если значение NULL не указано, все столбцы, участвующие в ограничении первичного ключа, имеют значение NULL.
• Если первичный ключ определен на столбце определяемого пользователем типа данных CLR, реализация этого типа должна поддерживать двоичную сортировку.

Foreign Key Constraints

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

Например, таблица имеет ссылку на внешний ключ к Sales.SalesPerson таблице, Sales.SalesOrderHeader так как между заказами на продажу и продавцами существует логическая связь. Столбец SalesPersonID в таблице SalesOrderHeader соответствует столбцу первичного ключа таблицы SalesPerson . Столбец SalesPersonID в таблице SalesOrderHeader является внешним ключом таблицы SalesPerson . Создав эту связь внешнего ключа, невозможно вставить значение SalesPersonID в SalesOrderHeader таблицу, если она еще не существует в SalesPerson таблице.

Максимальное количество таблиц и столбцов, на которые может ссылаться таблица в качестве внешних ключей (исходящих ссылок), равно 253. SQL Server 2016 (13.x) увеличивает ограничение числа других таблиц и столбцов, которые могут ссылаться на столбцы в одной таблице (входящих ссылок), с 253 до 10 000. (Требуется уровень совместимости не менее 130.) Увеличение имеет следующие ограничения:

• Превышение 253 ссылок на внешние ключи поддерживается только для операций DML DELETE. Операции UPDATE и MERGE не поддерживаются.
• Таблица со ссылкой внешнего ключа на саму себя по-прежнему ограничена 253 ссылками на внешние ключи.
• Более 253 ссылок на внешний ключ в настоящее время недоступны для индексов columnstore, оптимизированных для памяти таблиц, Stretch Database или секционированных таблиц внешнего ключа.

Важно! Stretch Database устарел в SQL Server 2022 (16.x) и База данных SQL Azure. Эта функция будет удалена в будущей версии ядро СУБД. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.

Индексы в ограничениях внешнего ключа

В отличие от ограничений первичного ключа, создание ограничения внешнего ключа не автоматически создает соответствующий индекс. Тем не менее, часто возникает необходимость создания индекса для внешнего ключа вручную по следующим причинам:

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

Ссылочная целостность

Главная задача ограничения внешнего ключа состоит в управлении данными, которые могут быть сохранены в таблице внешнего ключа, но это ограничение контролирует также изменение данных в таблице первичного ключа. Например, при удалении строки для менеджера по продажам из таблицы Sales.SalesPerson , идентификатор которого используется в заказах на продажу в таблице Sales.SalesOrderHeader , ссылочная целостность двух таблиц будет нарушена. Заказы на продажу удаленного менеджера в таблице SalesOrderHeader станут недействительными без связи с данными в таблице SalesPerson .

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

Каскадная ссылочная целостность

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

NO ACTION
Ядро СУБД вызывает ошибку, а действие удаления или обновления строки в родительской таблице откатывается.

CASCADE
Соответствующие строки обновляются или удаляются из ссылающейся таблицы, если данная строка обновляется или удаляется из родительской таблицы. КАСКАД нельзя указать, если столбец метки времени является частью внешнего ключа или ключа, на который ссылается ссылка. ON DELETE CASCADE нельзя указать для таблицы с триггером INSTEAD OF DELETE. ON UPDATE CASCADE нельзя указать для таблиц с триггерами INSTEAD OF UPDATE.

SET NULL
Всем значениям, составляющим внешний ключ, присваивается значение NULL, когда обновляется или удаляется соответствующая строка в родительской таблице. Для выполнения этого ограничения внешние ключевые столбцы должны допускать значения NULL. Невозможно указать для таблиц с триггерами INSTEAD OF UPDATE.

SET DEFAULT
Все значения, составляющие внешний ключ, при удалении или обновлении соответствующей строки родительской таблицы устанавливаются в значение по умолчанию. Для выполнения этого ограничения все внешние ключевые столбцы должны иметь определения по умолчанию. Если столбец имеет значение NULL, и нет явного набора значений по умолчанию, NULL становится неявным значением по умолчанию столбца. Невозможно указать для таблиц с триггерами INSTEAD OF UPDATE.

Ключевые слова CASCADE, SET NULL, SET DEFAULT и NO ACTION можно сочетать в таблицах, имеющих взаимные ссылочные связи. Если ядро СУБД обнаруживает NO ACTION, он останавливается и откатывает связанные действия CASCADE, SET NULL и SET DEFAULT. Если инструкция DELETE вызывает сочетание действий CASCADE, SET NULL, SET DEFAULT и NO ACTION, все действия CASCADE, SET NULL и SET DEFAULT применяются перед ядро СУБД проверка для любых действий NO ACTION.

Триггеры и каскадные ссылочные действия

Каскадные ссылочные действия запускают триггеры AFTER UPDATE или AFTER DELETE следующим образом:

• Все каскадные ссылочные действия, прямо вызванные исходными инструкциями DELETE или UPDATE, выполняются первыми.
• Если есть какие-либо триггеры AFTER, определенные для измененных таблиц, эти триггеры запускаются после выполнения всех каскадных действий. Эти триггеры запускаются в порядке, обратном каскадным действиям. Если в одной таблице существует несколько триггеров, они запускаются в случайном порядке, если для таблицы не существует выделенный первый или последний триггер. Этот порядок определяется процедурой sp_settriggerorder.
• Если последовательности каскадных действий происходят из таблицы, которая была непосредственной целью действий DELETE или UPDATE, порядок запуска триггеров этими последовательностями действий не определен. Однако одна последовательность действий всегда запускает все свои триггеры до того, как это начнет делать следующая.
• Триггер AFTER таблицы, являвшейся непосредственной целью действий DELETE или UPDATE, запускается вне зависимости от того, были ли изменены хоть какие-нибудь строки. В этом случае ни на какие другие таблицы каскадирование не влияет.
• Если один из предыдущих триггеров выполняет операции DELETE или UPDATE над другими таблицами, эти операции могут вызывать собственные последовательности каскадных действий. Эти вторичные последовательности действий обрабатываются для каждой операции DELETE или UPDATE после выполнения всех триггеров первичных последовательностей действий. Этот процесс может рекурсивно повторяться для последующих операций DELETE или UPDATE.
• Выполнение операций CREATE, ALTER, DELETE или других операций языка DDL внутри триггеров может привести к запуску триггеров DDL. Это может привести к дальнейшим операциям DELETE или UPDATE, которые начнут дополнительные последовательности каскадных действий и запустят свои триггеры.
• Если в любой конкретной последовательности каскадных ссылочных действий произойдет ошибка, в этой последовательности не будут запущены никакие триггеры AFTER, а для операций DELETE или UPDATE, создаваемых этой последовательностью, будет выполнен откат.
• Таблица с триггером INSTEAD OF не может также содержать предложение REFERENCES, указывающее каскадное действие. Однако триггер AFTER целевой таблицы каскадного действия может выполнить инструкцию INSERT, UPDATE или DELETE для другой таблицы или представления, которое запустит триггер INSTEAD OF для этого объекта.

Следующие шаги

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

Задача	Статья
Описывает, как создать первичный ключ.	Создание первичных ключей
Описывает, как удалить первичный ключ.	Удаление первичных ключей
Описывает, как изменить первичный ключ.	Изменение первичных ключей
Описывается создание связей внешнего ключа	Создание связей по внешнему ключу
Описывает, как изменить связи внешнего ключа.	Изменение связей по внешнему ключу
Описывает, как удалить связи внешнего ключа.	Удаление связей по внешнему ключу
Описывает, как просматривать свойства внешнего ключа.	Просмотр свойств внешнего ключа
Описывает, как отключить ограничения внешнего ключа для репликации.	Отключение ограничений внешнего ключа для репликации
Описывает, как отключить ограничения внешнего ключа на время выполнения инструкций INSERT и UPDATE.	Отключение ограничений внешнего ключа для инструкций INSERT и UPDATE

Revit Structure для конструктора (проблемы проектирования)

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

Сам я конструктор, решил проектировать при помощи Revit и Robot. (ранее работал в AutoCad и Лира).

Возникает ряд вопросов.

Проектирование ребристого перекрытия (как его правильно задавать для последующего экспорта в Robot) и принцип задания сочетаний нагружений в Revit. Оговорюсь, что Revit хотелось бы использовать как препроцессор для Robot.

Спасибо всем ответившим.

Так-же задавайте вопросы, чем смогу помогу.

Просмотров: 3136624

professor_off

Посмотреть профиль

Найти ещё сообщения от professor_off

Регистрация: 02.03.2012
Сообщений: 199
Сообщение от extraneous
Я обычно рекомендую делать рабочие наборы по фамилиям

На практике принадлежность элемента конструкции более стабильна, нежели принадлежность элемента исполнителю. К таму же, часть конструкции часто необходимо отдельно специфицировать.
Я использую общий параметр «ЧастьЗдания» (ранее используемый extraneous) и практически дублирую его рабочими наборами с некоторыми вариациями для настроек видимости.
Плюс рабочего набора перед общим параметром в том, что он автоматически назначается новым объектам. Минус в том, что по нему нельзя отфильтровать спецификацию.
Контроль и переназначение рабочих наборов осуществляется через затенение графики неактивных рабочих наборов и через настроенные 3d виды по рабочим наборам.

extraneous, поясните прочему Вы стали использовать «Орг.Уровень» вместо «ЧастьЗдания».

Регистрация: 10.10.2013
Сообщений: 244
Сообщение от ИГС

Возникла проблемка. В ревите 2014 на 3Д виде не отбрасывается тень от прозрачных материалов (делаю навес из поликарбоната), как только не пытался настроить ничего не получилось. При этом на виде фасадов тень есть. Просто какая-то неурядица. Может и не стоит искать так как это невозможно? Подскажите, кто знает в чем дело.

А тема то называется Revit Structure для конструктора (проблемы проектирования) Может есть смысл спросить у архитекторов кто пользует Ревит?

__________________
. И опыт, сын ошибок трудных,
И гений, парадоксов друг.

Anton_KAM_2013

Посмотреть профиль

Найти ещё сообщения от Anton_KAM_2013

Регистрация: 04.05.2010
Сообщений: 338

Архитекторы вопросом меня озадачили. почему у них на планах колонна не выделяется(штриховака стены поверх колонны) из стены?

я попробовал рядом нарисовал выделяется..

а в модели где это настраивается и что за это отвечает?

иеще вопрос. можно ли чертежи КР и АР нумеровать 2 альбома отдельно, что бы с 1 го листа все начиналось.Пока у нас с ними все друг за другом нумеруется.

и 3й вопрос возник: почему у меня вечно такое окошко вылетает?

Последний раз редактировалось SNIIP, 25.05.2015 в 13:11 .
Регистрация: 07.06.2010
Сообщений: 1,153
Сообщение от VadimS7
extraneous, поясните прочему Вы стали использовать «Орг.Уровень» вместо «ЧастьЗдания».

Да все просто. Уровень — это параметр «Целое», значит для него можно использовать операторы «больше-меньше». Например, делаю опалубку плиты на уровне 3 и скрываю через фильтр все элементы «Уровень > 3». Также по этому параметру можно сделать спецификацию несущих конструкций на один уровень. Для проверки правильности назначенного уровня используется, во первых, маркировка из двух цифр (Марка.Уровень), а во-вторых — 3d-виды с фильтром для каждого уровня.

Сообщение от VadimS7
Минус в том, что по нему нельзя отфильтровать спецификацию

. что делает рабочие наборы бесполезными для организации работы. Единственное, для чего использую рабочие наборы — это для связанных файлов или каких-то вспомогательных элементов, которые должны быть невидимыми на всех видах. Соответственно закидываю их в рабочий набор с отключенной галкой «Видимый на всех видах».

__________________
Мой блог по Revit

extraneous

Посмотреть профиль

Посетить домашнюю страницу extraneous

Найти ещё сообщения от extraneous

Регистрация: 10.10.2013
Сообщений: 244
Сообщение от extraneous
Единственное, для чего использую рабочие наборы

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

__________________
. И опыт, сын ошибок трудных,
И гений, парадоксов друг.

Anton_KAM_2013

Посмотреть профиль

Найти ещё сообщения от Anton_KAM_2013

Регистрация: 02.03.2012
Сообщений: 199
Сообщение от extraneous
Уровень — это параметр «Целое», значит для него можно использовать операторы «больше-меньше».

А для параметра «Текст» тоже можно использовать операторы «больше-меньше» и дополнительно содержит/не содержит, что дает гораздо больше возможностей и более понятно.

Сообщение от extraneous
. что делает рабочие наборы бесполезными для организации работы.

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

Сообщение от extraneous

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

При использовании шаблонов видов удобно некоторые элементы не «скрывать на виде» а назначить рабочий набор отключенный для данного шаблона.

Регистрация: 07.06.2010
Сообщений: 1,153
Сообщение от VadimS7
А для параметра «Текст» тоже можно использовать операторы «больше-меньше»

Хм, и правда работает — почему-то, когда я пробовал, он считал 2 больше чем 10. Спасибо, пригодится

Сообщение от VadimS7
То, что он автоматически назначается новым объектам помогает в организации работы.

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

Сообщение от VadimS7

При использовании шаблонов видов удобно некоторые элементы не «скрывать на виде» а назначить рабочий набор отключенный для данного шаблона.

«Скрывать на виде» вообще ничего не надо, и скрыть можно и через фильтр.
__________________
Мой блог по Revit

extraneous

Посмотреть профиль

Посетить домашнюю страницу extraneous

Найти ещё сообщения от extraneous

Регистрация: 02.03.2012
Сообщений: 199
Сообщение от extraneous
А мне это, наоборот, показалось неудобным.

Может вы и правы, проблемы с отслеживанием есть.

Сообщение от extraneous
«Скрывать на виде» вообще ничего не надо, и скрыть можно и через фильтр.
Это да. Я просто вообще не пользовал фильтр по выбранным объектам.
Регистрация: 13.10.2011
Сообщений: 2,359

я использую «назначение вида» и «принадлежность конструкции» текстовые общие параметры, по ним фильтрую конструкции и специфицирую. Как то рабочие наборы мне показались менее удобными но каждому свое.

Регистрация: 02.03.2012
Сообщений: 199
Сообщение от miko2009
я использую «назначение вида» и «принадлежность конструкции» текстовые общие параметры

Системный параметр «Назначение вида» тоже использую. По нему удобней фильтровать нежели по «Семейство и типоразмер» или «Имени вида». С помощью этих фильтров душу лишние разрезы, фрагменты.
Рабочие наборы удобны для фильтрации конструкций смежников (скрыть отделку стен, полы).

Регистрация: 20.03.2012
Сообщений: 25

Друзья! Подскажите, возможно ли в параметрах семейства ревита формулами поставить зависимость параметра экземляра (Да/Нет) от двух других таких же параметров экземляра? Например: если оба параметра галочка включена, чтобы на третьем была выключена, а если на первом включена, на втором нет, чтобы третий тоже включал галочку. Если такое решение присутствует, напишите, пожалуйста, формулой как его воплотить жизнь. У меня логический оператор if ругается и никак слушаться не хочет. Премного благодарен.

Регистрация: 13.10.2011
Сообщений: 2,359
Регистрация: 12.09.2009
г. Краснодар
Сообщений: 314
Сообщение от Room114

Подскажите, возможно ли в параметрах семейства ревита формулами поставить зависимость параметра экземляра (Да/Нет) от двух других таких же параметров экземляра?

Смотрите в сторону Dynamo. возможно с её помощью можно решить эту задачу.
Регистрация: 20.03.2012
Сообщений: 25
Благодарю вас за ответы. Чувствую, что Dynamo мне еще рановато, но на будущее возможно и осилю.
Регистрация: 07.06.2010
Сообщений: 1,153
Сообщение от Room114

если оба параметра галочка включена, чтобы на третьем была выключена, а если на первом включена, на втором нет, чтобы третий тоже включал галочку.

Не совсем понял, но разве это не оно?
__________________
Мой блог по Revit

extraneous

Посмотреть профиль

Посетить домашнюю страницу extraneous

Найти ещё сообщения от extraneous

Регистрация: 12.09.2009
г. Краснодар
Сообщений: 314
Сообщение от Room114
Чувствую, что Dynamo мне еще рановато, но на будущее возможно и осилю.
Сам не освоил . есть уроки на Ютубе Алексея Лобанова . смотрю
Регистрация: 02.03.2012
Сообщений: 199
Сообщение от Room114

если оба параметра галочка включена, чтобы на третьем была выключена, а если на первом включена, на втором нет, чтобы третий тоже включал галочку.

Да3=not(and(Да1, Да2))
Регистрация: 20.03.2012
Сообщений: 25

Огромное спасибо за идею! Немного перестроил под нужную для меня формулу Да3=and(Да1, not(Да2)), главное ,что понял суть!)))

Регистрация: 13.10.2011
Сообщений: 2,359

Честно не совсем понял вопроса ,а понял я его так ,есть 3 параметра да/нет,при включении одного выключаются другие, цикличность не победить

Регистрация: 10.10.2013
Сообщений: 244

Возникла проблема при работе с вариантами конструкций. Во вложении балка, при попытке дотягивания которой до стены (которая в главной модели). Ошибка говорит: «На элемент вторичного параметра не могут ссылаться элементы, находящиеся вне его.» Причём даже руками тяну — не желает привязываться ни к чему что не находится в наборе данного варианта конструкции. К линиям построения не привязывается с той же ошибкой. Как привязать балки?

Пришло некоторое понимание проблемы. Балка (во второстепенном варианте) дотягиваясь до стены влияет на стены впринципе (якобы вырезая или соединяясь). Балка которая дотягивается, но не взаимодействует ни с какой конструкцией (просто тянется до линии) — отлично себя чувствует. В основном варианте таких проблем вообще нет, тяни куда хочешь что хочешь. То есть всё таки надо было правку делать в «основном варианте». Какая то странная ерунда получается.
Но вопрос остался, как привязать/дотянуть балки во вторичном варианте?

Может как то отключить автоматическое вырезание геометрии?

__________________
. И опыт, сын ошибок трудных,
И гений, парадоксов друг.
Последний раз редактировалось Anton_KAM_2013, 26.05.2015 в 10:27 . Причина: новые мысли по проблеме

Anton_KAM_2013

Посмотреть профиль

Найти ещё сообщения от Anton_KAM_2013

Объединение объектов

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

Методы объединения объектов

Эффекты обработки контуров

Эффекты обработки контуров позволяют объединять несколько объектов с помощью режимов взаимодействия. При использовании эффектов обработки контуров нельзя редактировать взаимодействие между объектами. См. Объединение объектов с помощью эффектов обработки контуров.

Составные фигуры

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

Составные контуры

Составные контуры позволяют использовать объект для вырезания отверстия в другом объекте. Например, можно создать кольцо из двух вложенных кругов. После создания составного контура контуры действуют как сгруппированные объекты. Инструмент «Частичное выделение» или «Групповое выделение» позволяет выделять объекты и управлять ими, а также выбирать и редактировать объединенный контур. См. Объединение объектов с помощью составных контуров.

Примечание.

Добавить объект можно также с помощью инструмента «Кисть-клякса». При использовании этой кисти рисуемые контуры добавляются к смежным контурам, в которых используются идентичные атрибуты заливки. См. Рисование и объединение контуров с помощью инструмента «Кисть-клякса» и Создание новых фигур с помощью инструмента «Создание фигур».

Объединение объектов с помощью эффектов обработки контуров

Навигация по палитре «Обработка контуров»

Палитра «Обработка контуров» («Окно» > «Обработка контуров») используется для объединения объектов в новые фигуры.

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

Используйте верхнюю строку кнопок в палитре для создания контуров или составных контуров. Чтобы создать составные фигуры, используйте кнопки в этих строках, удерживая клавишу Alt или Option. Выберите один из следующих режимов формы:

Добавить к области фигуры
Добавляет область компонента к базовой геометрии.
Вычесть из области фигуры
Вырезает область компонента из базовой геометрии.
Пересечение областей фигур
Использует область компонента для обрезки базовой геометрии в качестве маски.
Исключить перекрывающиеся области фигуры

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

A. Все компоненты в режиме добавления B. К квадратам применяется режим вычитания C. К квадратам применяется режим пересечения D. К квадратам применяется режим исключения

Задание параметров обработки контуров

Задайте параметры обработки контуров в меню палитры «Обработка контуров» или дважды щелкните эффект обработки контуров в палитре «Оформление».

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

Удалить лишние точки
При нажатии кнопки «Обработка контуров» удаляются ненужные точки.
При разделении и обводке удалять незакрашенные объекты
Удаляет все незаполненные объекты в выделенном объекте при нажатии кнопки «Разделить» или «Контур».

Применение эффектов обработки контуров

Эффекты обработки контуров позволяют создавать новые фигуры из перекрывающихся объектов. Примените эффекты обработки контуров с помощью меню «Эффекты» или палитры «Обработка контуров».

• Эффекты обработки контуров в меню «Эффекты» может применяться только к группам, слоям и текстовым объектам. После применения эффекта можно по-прежнему выделять и редактировать исходные объекты. Для изменения или удаления эффекта можно также использовать палитру «Оформление». См. Применение эффекта обработки контуров с помощью меню «Эффекты».
• Эффекты обработки контуров в палитре «Обработка контуров» может применяться к любой комбинации объектов, групп и слоев. Конечная комбинация фигур создается при нажатии кнопки обработки контуров. После этого исходные объекты редактировать нельзя. Если эффект приводит к появлению нескольких объектов, они автоматически группируются вместе. См. Применение эффекта обработки контуров с помощью палитры «Обработка контуров».

Применение эффекта обработки контуров с помощью меню «Эффекты»

Выполните одно из следующих действий.

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

Выберите команду «Эффект» > «Обработка контуров» и выберите эффект обработки контуров.
Примечание.

Чтобы быстро снова применить тот же эффект обработки контуров, выберите «Эффект» > «Применить [эффект]».

Применение эффекта обработки контуров с помощью палитры «Обработка контуров»

Выберите объекты, к которым требуется применить эффект.
Чтобы применить эффект обработки контуров к группе или слою, выберите группу или слой.

В палитре «Обработка контуров» нажмите кнопку обработки контуров (в нижней строке) или, удерживая клавишу «Alt» (Windows) или «Option» (Mac OS), нажмите кнопку «Режим фигуры» (в верхней строке).

Сводка эффектов обработки контуров

Трассировка контура всех объектов, как если бы они были единым объединенным объектом. Результирующая фигура принимает атрибуты заливки верхнего объекта.

Трассировка контура области, перекрываемой всеми объектами.

Трассировка всех неперекрывающихся областей объектов делает перекрывающиеся области прозрачными. Если перекрывается четное число объектов, наложение становится прозрачным. Если перекрывается нечетное число объектов, наложение заполняется заливкой.

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

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

Разделяет графический объект на залитые компоненты фрагменты ( лицо представляет собой область, не разделенную отрезком линии).

Примечание: При использовании кнопки «Разделить» в палитре «Обработка контуров» можно использовать инструменты «Частичное выделение» или «Групповое выделение» для независимой от друг друга обработки результирующих лиц. При применении команды «Разделить» можно также удалить или сохранить незаполненные объекты.

Удаляет скрытую часть объекта с заливкой. Удаляет все обводки и не объединяет объекты одного цвета.

Удаляет скрытую часть объекта с заливкой. Удаляет все обводки и объединяет соседние или перекрывающиеся объекты, залитые одним цветом.

Делит иллюстрацию на фрагменты с заливкой компонента, а затем удаляет все части иллюстрации, находящиеся за пределами верхнего объекта. Также удаляются все обводки.

Разделяет объект на отрезки линии его компонента, или края. Эта команда полезна при подготовке иллюстрации, для которой необходим треппинг для объектов с наложением цветов. См. Создание зоны треппинга.

Примечание: При использовании кнопки «Контур» в палитре «Обработка контуров» можно использовать инструменты «Частичное выделение» или «Групповое выделение» для независимой манипуляции с каждым краем. При использовании команды «Контур» можно также удалить или сохранить незаполненные объекты.

Объединяет цвета, выбирая максимальное значение каждого из компонентов цвета. Например, если цвет 1 — 20% голубой, 66% пурпурный, 40% желтый и 0% черный, а цвет 2 — 40% голубой, 20% пурпурный, 30% желтый и 10% черный, то резуль — 46 6% пурпурного, 40% желтого и 10% черного.

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

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

Объединение объектов с помощью составных фигур

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

Составные фигуры действуют как сгруппированные объекты и отображаются как на панели «Слои». Палитра «Слои» позволяет отображать, выбирать и управлять содержимым составной фигуры, например менять порядок наложения ее компонентов. Для выделения компонентов составной фигуры можно также использовать инструмент «Частичное выделение» или «Групповое выделение».

При создании составной фигуры в режиме «Добавить», «Пересечение» или «Исключение» применяются атрибуты заливки и прозрачности самого верхнего компонента. Впоследствии можно изменить атрибуты заливки, стиля или прозрачности составной фигуры. Illustrator упрощает этот процесс, автоматически выбрав любую его часть, указывая на всю составную фигуру, если только не выбран явный целевой компонент на панели «Слои».

A. Исходные объекты B. Созданная составная фигура C. Отдельные режимы фигур, применяемые к каждому компоненту D. Стиль, примененный ко всей составной фигуре

Вопросы и ответы для собеседования Go-разработчика

Структурирование информации — очень полезный навык. И дабы привнести некоторый порядок в этап подготовки к интервью на должность Golang разработчика (и немножко техлида) решил записывать в этой заметке в формате FAQ те вопросы, которые я задавал, задавали мне или просто были мной найдены на просторах сети вместе с ответами на них. Стоит относиться к ним как к шпаргалке (если затупишь на реальном интервью — будет где подсмотреть) и просто набору тем, которым тебе стоит уделить внимание.

Я постарался копнуть в каждый вопрос чуть глубже чем, возможно, надо бы — что бы у читателя был не только короткий ответ на вопрос, но и некоторое понимание «а почему именно так устроена та или иная штука». Более того, крайне рекомендую ознакомиться и с ссылками на источники, что будут под ответами — там вы найдете более развернутые ответы.

Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.

Расскажи о себе?

Чаще всего этот вопрос идёт первым и даёт возможность интервьюверу задать вопросы связанные с твоим резюме, познакомиться с тобой, попытаться понять твой характер для построения последующих вопросов. Следует иметь в виду, что интервьюверу не всегда удается подготовиться к интервью, или он банально не имеет перед глазами твоего резюме. Тут есть смысл ещё раз представиться (часто в мессенджерах используются никнеймы, а твоё реальное имя он мог забыть), назвать свой возраст, образование, рассказать о предыдущих местах работы и должностях, сколько лет в индустрии, какие ЯП и технологии использовал — только «по верхам», для того чтоб твой собеседник просто понял с кем он «имеет дело».

Расскажи о своем самом интересном проекте?

К этому вопросу есть смысл подготовиться заранее и не спустя рукава. Дело в том, что это тот момент, когда тебе надо подобно павлину распустить хвост и создать правильное первое впечатление о себе, так как этот вопрос тоже очень часто идёт впереди всех остальных. Возьми и выпиши для себя где-нибудь на листочке основные тезисы о том, что это был за проект/сервис/задача, уделяя основное внимание тому какой профит это принесло для компании/команды в целом. Например:

• Я со своей командой гоферов из N человек в течении трех месяцев создали аналог сервиса у которого компания покупала данные за $4000 в месяц, а после перехода на наш сервис — расходы сократились до $1500 в месяц и значительно повысилось их качество и uptime;
• Внедренные мной практики в CI/CD пайплайны позволили сократить время на ревью изменений в проектах на 25..40%, а зная сколько стоит время работы разработчиков — вы сами всё понимаете;
• Разработанный мной сервис состоял из такого-то набора микросервисов, такие-то службы и протоколы использовал, были такие-то ключевые проблемы которые мы так-то зарешали; основной ценностью было то-то.

Кем был создан язык, какие его особенности?

Go (часто также golang) — компилируемый многопоточный язык программирования, разработанный внутри компании Google. Разработка началась в 2007 году, его непосредственным проектированием занимались Роберт Гризмер, Роб Пайк и Кен Томпсон. Официально язык был представлен в ноябре 2009 года.

В качестве ключевых особенностей можно выделить:

• Простая грамматика (минимум ключевых слов — язык создавался по принципу «что ещё можно выкинуть» вместо «что бы ещё в него добавить»)
• Строгая типизация и отказ от иерархии типов (но с сохранением объектно-ориентированных возможностей)
• Сборка мусора (GC)
• Простые и эффективные средства для распараллеливания вычислений
• Чёткое разделение интерфейса и реализации
• Наличие системы пакетов и возможность импортирования внешних зависимостей (пакетов)
• Богатый тулинг «из коробки» (бенчмарки, тесты, генерация кода и документации), быстрая компиляция

Для того, чтоб вспомнить историю создания Go и о его особенностях можно посмотреть:

Go — императивный или декларативный? А в чем разница?

Go является императивным языком.

Императивное программирование — это описание того, как ты делаешь что-то (т.е. конкретно описываем необходимые действия для достижения определенного результата), а декларативное — того, что ты делаешь (например, декларативным ЯП является SQL — мы описываем что мы хотим получить от СУБД, но не описываем как именно она должна это сделать).

Что такое ООП? Как это сделано в Golang?

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

• Абстракция вообще присуща для любого программирования, а не только для ООП. По большому счету (топорный, но понятный пример) это про выделение общего и объединение этого в какие-то сущности но без реализации, про контракты. Например — экземпляры абстрактных классов не могут быть созданы ( new AbstractClass ), но могут содержать абстрактные методы, чтоб разработчик решив наследоваться от этого абстрактного класса их реализовал так, как ему нужно для своих целей (например — ходить в SQL СУБД или файл). Другой пример — это интерфейсы, они же контракты чистой воды — содержат только сигнатуры методов и ни капельки реализации. Но абстракция не ограничивается ими и должна быть умеренной, так как усложняет архитектуру приложения в общем и целом. Опираться следует на интуицию и опыт. Слишком много слоев абстракции (ещё раз — тут дело не ограничивается интерфейсами и абстрактными классами) приводит к переусложнению и головной боли последующего сопровождения продукта. Недостаточная — к сложности внесения изменений и расширению функционала
• Инкапсуляция про контроль доступа к свойствам объекта и их динамическая валидация/преобразования. Если метод/свойство должно быть доступно «извне» объекта — объявляем публичным, иначе — приватным. Если есть необходимость переопределять его из потомков класса — то защищенным (protected). Python, например, реализуют инкапсуляцию, но не предусматривает возможности сокрытия в принципе; в то время как С++ и Java она просто всюду
• Наследование это возможность (барабанная дробь!) наследоваться одним объектам от других, «перенимая» все методы родительских объектов. Своеобразный вариант Матрешки. Т.е. выделяя в родительских объектах «всё общее» мы можем не повторяться в реализации частных, а просто «наследоваться»
• Полиморфизм — «поли» — много, «морф» — вид. Везде, где есть интерфейсы — подразумевается полиморфизм. Суть — это контракты (интерфейсы), мы можем объявить «что-то умеет закрывать себя методом Close() «, и нам не важно что именно это будет. Реализаций может быть много, и если это что-то умеет делать то, что нам надо — нам удобнее с этим работать

Тут же можно упомянуть про знание SOLID, а именно:

• S (single responsibility principle, принцип единственной ответственности) — определенный класс/модуль должен решать только определенную задачу, максимально узко но максимально хорошо (своеобразные UNIX-way). Если для выполнения своей задачи ему требуются какие-то другие ресурсы — они в него должны быть инкапсулированы (это отсылка к принципу инверсии зависимостей)
• O (open-closed principle, принцип открытости/закрытости) — классы/модули должны быть открыты для расширения, но закрыты для модификации. Должна быть возможность расширить поведение, наделить новым функционалом, но при этом исходный код/логика модуля должна быть неизменной
• L (Liskov substitution principle, принцип подстановки Лисков) — поведение наследующих классов не должно противоречить поведению, заданному базовым классом, то есть поведение наследующих классов должно быть ожидаемым для кода
• I (interface segregation principle, принцип разделения интерфейса) — много тонких интерфейсов лучше, чем один толстый
• D (dependency inversion principle, принцип инверсии зависимостей) — «завязываться» на абстракциях (интерфейсах), а не конкретных реализациях. Так же (это уже про IoC, но всё же) можно рассказать что если какому-то классу для своей работы требуется функциональность другого — то есть смысл «запрашивать» её в конструкторе нашего класса используя интерфейс, под который подходит наша зависимость. Таким образом целевая реализация опирается только на интерфейсы (не зависит от реализаций) и соответствует принципу под буквой S

А теперь о том, как это реализовано в Go (наконец-то!).

В Go нет классов, объектов, исключений и шаблонов. Нет иерархии типов, но есть сами типы (т.е. возможность описывать свои типы/структуры). Структурные типы (с методами) служат тем же целям, что и классы в других языках. Так же следует упомянуть что структура определяет состояние.

В Go нет наследования. Совсем. Но есть встраивание (называемое «анонимным», так как Foo в Bar встраивается не под каким-то именем, а без него) при этом встраиваются и свойства, и функции:

import "fmt" type Foo struct < name string Surname string >func (f Foo) SayName() string < return f.name >type Bar struct < Foo >func main() < bar := Bar> fmt.Println(bar.SayName()) // one fmt.Println(bar.Surname) // baz bar.name = "two" fmt.Println(bar.SayName()) // two >

Есть интерфейсы (это типы, которые объявляют наборы методов). Подобно интерфейсам в других языках, они не имеют реализации. Объекты, которые реализуют все методы интерфейса, автоматически реализуют интерфейс (так называемый Duck-typing). Не существует наследования или подклассов или ключевого слова Implements :

import "fmt" type Speaker interface < Speak() string >type Foo struct<> func (Foo) Speak() string < return "foo" >type Bar struct<> func (Bar) Speak() string < return "bar" >func main() < var foo, bar Speaker = new(Foo), &Bar<>fmt.Println(foo.Speak()) // foo fmt.Println(bar.Speak()) // bar >

В примере выше мы объявили переменные foo и bar с явным указанием интерфейсного типа, а так интерфейс это «ссылочный» тип (на самом деле в Go нет ссылок, но есть указатели) — то и структуры мы инициализировали указателями на них с использованием new() (что аллоцирует структуру и возвращает указатель на неё) и (или) & .

Инкапсуляция реализована на уровне пакетов. Имена, начинающиеся со строчной буквы, видны только внутри этого пакета (не являются экспортируемыми). И наоборот — всё, что начинается с заглавной буквы — доступно извне пакета. Дешево и сердито.

Полиморфизм — это основа объектно-ориентированного программирования: способность обрабатывать объекты разных типов одинаково, если они придерживаются одного и того же интерфейса. Интерфейсы Go предоставляют эту возможность очень прямым и интуитивно понятным способом. Пример использования интерфайса был описан выше.

Что можно почитать: ООП в картинках, Golang и ООП

Как устроено инвертирование зависимостей?

Инвертирование зависимостей позволяет в нашем коде не «завязываться» на конкретную реализацию (используя, например, интерфейсы), тем самым понижая связанность кода и повышая его тестируемость. Так же сужается зона ответственности конечной структуры/пакета, что повышает его переиспользуемость.

Принцип инверсии зависимостей (dependency inversion principle) в Go который можно реализовывать следующим образом:

import ( "errors" "fmt" ) type speaker interface < Speak() string >type Foo struct < s speaker // s *Foo - было бы плохо >func NewFoo(s speaker) (*Foo, error) < if s == nil < return nil, errors.New("speaker is nil") >return &Foo, nil > func (f Foo) SaySomething() string < return f.s.Speak() >func main() < var foo, err = NewFoo(someSpeaker) if err != nil < panic(err) >fmt.Println(foo.SaySomething()) // depends on the speaker implementation >

Мы объявляем интерфейс speaker не экспортируемым на нашей, принимающей стороне, и используя псевдо-конструктор NewFoo гарантируем что свойство s будет проинициализировано верным типом (дополнительно проверяя его на nil ).

Как сделать свои методы для стороннего пакета?

Например, если мы используем логгер Zap в нашем проекте, и хотим к этому Zap-у прикрутить наши методы — то для этого нам нужно будет создать свою структуру, внутри в неё встраивать логгер Zap-а, и к этой структуре уже прикручивать требуемые методы. Просто «навесить сверху» функции на сторонний пакет мы не можем.

Типы данных и синтаксис

К фундаментальным типам данных можно отнести:

• Целочисленные — int , int , uint , uint , byte как синоним uint8 и rune как синоним int32 . Типы int и uint имеют наиболее эффективный размер для определенной платформы (32 или 64 бита), причем различные компиляторы могут предоставлять различный размер для этих типов даже для одной и той же платформы
• Числа с плавающей запятой — float32 (занимает 4 байта/32 бита) и float64 (занимает 8 байт/64 бита)
• Комплексные числа — complex64 (вещественная и мнимая части представляют числа float32 ) и complex128 (вещественная и мнимая части представляют числа float64 )
• Логические aka bool
• Строки string

Как устроены строки в Go?

В Go строка в действительности является слайсом (срезом) байт, доступным только для чтения. Строка содержит произвольные байты, и у неё нет ёмкости ( cap ). При преобразовании слайса байт в строку ( str := string(slice) ) или обратно ( slice := []byte(str) ) — происходит копирование массива (со всеми следствиями).

Создание подстрок работает очень эффективно. Поскольку строка предназначена только для чтения, исходная строка и строка, полученная в результате операции среза, могут безопасно совместно использовать один и тот же массив:

var ( str = "hello world" sub = str[0:5] usr = "/usr/kot"[5:] ) print(sub, " ", usr) // hello kot

Go использует тип rune (алиас int32 ) для представления Unicode. Конструкция for . range итерирует строку посимвольно (а не побайтово, как можно было бы предположить):

var str = "привет" println(str, len(str)) // привет 12 for i, c := range str < println(i, c, string(c)) >// 0 1087 п // 2 1088 р // 4 1080 и // 6 1074 в // 8 1077 е // 10 1090 т

И мы видим, что для кодирования каждого символа кириллицы используются по 2 байта.

Эффективным способом работы со строками (когда есть необходимость часто выполнять конкатенацию, например) является использование слайса байт или strings.Builder :

import "strings" func main() < // происходит только 1 аллокация при вызове `Grow()` var str strings.Builder str.Grow(12) // сразу выделяем память str.WriteString("hello") str.WriteRune(' ') str.WriteString("мир") println(str.String()) // hello мир >

И ещё одну важную особенность стоит иметь в виду — это подсчет длины строки (например — для какой-нибудь валидации). Если считать по количеству байт, и строка содержит не только ASCII символы — то количество байт и фактическое количество символов будут расходиться:

const str = "hello мир!" println(len(str), utf8.RuneCountInString(str)) // 13 10

Тут дело в том, что для кодирования символов м , и и р используются 2 байта вместо одного. Поэтому len == 13 , а фактически в строке лишь 10 символов (пакет utf8 , к примеру, нам в помощь).

Что можно почитать: Строка, байт, руна, символ в Golang

В чём ключевое отличие слайса (среза) от массива?

• Срез — всегда указатель на массив, массив — значение
• Срез может менять свой размер и динамически аллоцировать память

В Go не бывает ссылок — но есть указатели. Где говорится про «по ссылке» имеется в виду «по указателю»

Слайсы и массивы в Go это упорядоченные структуры данных последовательностей элементов. Ёмкость массива объявляется в момент его создания, и после изменить её уже нельзя (его длина это часть его типа). Память, необходимая для хранения элементов массива выделяется соответственно сразу при его объявлении, и по умолчанию инициализируется в соответствии с нулевыми значением для типа ( fasle для bool , 0 для int , nil для интерфейсов и т.д.). На стеке можно разместить массив объемом 10 MB. В качестве размера можно использовать константы (компилятор должен знать это значение на этапе компиляции, т.е. что-то вида var a [getSize()]int или i := 3; var a [i]int недопустимо):

const mySize uint8 = 8 type myArray [mySize]byte var constSized = [. ]int // размер сам посчитается исходя из кол-ва эл-ов

Кстати, массивы с элементами одного типа но с разными размерами являются разными типами. Массивы не нужно инициализировать явно; нулевой массив — это готовый к использованию массив, элементы которого являются нулями:

var a [4]int // [0 0 0 0] a[0] = 1 // [1 0 0 0] i := a[0] // i == 1

Представление [4]int в памяти — это просто четыре целых значения, расположенных последовательно. Так же следует помнить что в Go массивы передаются по значению, т.е. передавая массив в какую-либо функцию она получает копию массива (для передачи его указателя нужно явно это указывать, т.е. foo(&a) ).

А слайс же это своего рода версия массива но с вариативным размером (структура данных, которая строится поверх массива и предоставляет доступ к элементами базового массива). Слайсы до 64 KB могут быть размещены на стеке. Если посмотреть исходники Go (src/runtime/slice.go), то увидим:

type slice struct < array unsafe.Pointer // указатель на массив len int // длина (length) cap int // вместимость (capacity) >

Для аллокации слайса можно воспользоваться одной из команд ниже:

var ( a = []int<> // [] len=0 cap=0 b = []int // [1 2] len=2 cap=2 c = []int // [0 0 0 0 0 123] len=6 cap=6 d = make([]int, 5, 10) // [0 0 0 0 0] len=5 cap=10 )

В последнем случае рантайм Go создаст массив из 10 элементов (выделит память и заполнит их нулями) но доступны прямо сейчас нам будут только 5, и установит значения len в 5 , а cap в 10 . Cap означает ёмкость и помогает зарезервировать место в памяти на будущее, чтобы избежать лишних операций выделения памяти при росте слайса (это ключевой параметр для аллокации памяти, влияет на производительность вставки в срез). При добавлении новых элементов в слайс новый массив для него не будет создаваться до тех пор, пока cap меньше len .

Слайсы передаются «по ссылке» (фактически будет передана копия структуры slice со своими len и cap , но указатель на массив array будет тот-же самый). Для защиты слайса от изменений следует передавать его копию:

var ( a = []int b = make([]int, len(a)) ) copy(b, a) fmt.Println(a, b) // [1 2 0 0 1] [1 2 0 0 1]

Важной особенностью является то, так как «под капотом» у слайса лежит указатель на массив — при изменении значений слайса они будут изменяться везде, где слайс используется (будь то присвоение в переменную, передача в функцию и т.д.) до момента, пока размер слайса не будет переполнен и не будет выделен новый массив для его значений (т.е. в момент изменения cap слайса всегда происходит копирование данных массива):

var ( one = []int // [1 2] two = one // [1 2] ) two[0] = 123 fmt.Println(one, two) // [123 2] [123 2] one = append(one, 666) fmt.Println(one, two) // [123 2 666] [123 2]

Как вы отсортируете массив структур по алфавиту по полю Name ?

Например, преобразую массив в слайс и воспользуюсь функцией sort.SliceStable :

package main import ( "fmt" "sort" ) func main() < var arr = [. ]struct< Name string >, , > // ^^^^^^^^^^^^^^^^^^^^^ анонимная структура с нужным нам полем fmt.Println(arr) // [  ] sort.SliceStable(arr[:], func(i, j int) bool < return arr[i].Name < arr[j].Name >) // ^^^ вот тут вся "магия" - из массива сделали слайс fmt.Println(arr) // [  ] >

Вся магия в том, что при создании слайса из массива «под капотом» у слайса начинает лежать исходный массив, и функции из пакета sort нам становятся доступны над ними. Т.е. изменяя порядок элементов в слайсе функцией sort.SliceStable мы будем менять их в нашем исходном массиве.

Как работает append в слайсе?

append() делает простую операцию — добавляет элементы в слайс и возвращает новый. Но под капотом там делаются довольно сложные манипуляции, чтобы выделять память только при необходимости и делать это эффективно.

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

Увеличении размера слайса (метод growslice ) происходит по следующему алгоритму — если его размер менее 1024 элементов, то его размер будет увеличиваться вдвое; иначе же слайс увеличивается на ~12.5% от своего текущего размера.

Что важно помнить — если на основании слайса one выделить подслайс two , а затем увеличим слайс one (и его вместимость будет превышена) — то one и two будут уже ссылаться на разные участки памяти!

var ( one = make([]int, 4) // [0 0 0 0] two = one[1:3] // [0 0] ) one[2] = 11 fmt.Println(one, two) // [0 0 11 0] [0 11] fmt.Printf("%p %p\n", one, two) // 0xc0000161c0 0xc0000161c8 one = append(one, 1) fmt.Printf("%p %p\n", one, two) // 0xc00001c1c0 0xc0000161c8 one[2] = 22 fmt.Println(one, two) // [0 0 22 0 1] [0 11] fmt.Printf("%p %p\n", one, two) // 0xc00001c1c0 0xc0000161c8

Есть еще много примеров добавления, копирования и других способов использования слайсов тут — Slice Tricks.

Что можно почитать: Как не наступать на грабли в Go

Задача про слайсы #1

Вопрос: У нас есть 2 функции — одна делает append() чего-то в слайс, а другая просто сортирует слайс, используя пакет sort . Модифицируют ли слайс первая и (или) вторая функции?

Ответ: append() не модифицирует а возвращает новый слайс, а sort модифицирует порядок элементов, если он изначально был не отсортирован.

Задача про слайсы #2

Вопрос: Что выведет следующая программа?

package main import "fmt" func main() < a := [5]intt := a[3:4:4] fmt.Println(t[0]) >

Объяснение: Такой синтаксис позволяет задать capacity (вместимость) для полученного под-слайса, который будет равен «последний элемент минус первый элемент из выражения в квадратных скобках», т.е. из примера выше он будет равен 1 (т.к. от четырёх, т.е. третьего сегмента вычитаем первый, т.е. тройку). Если бы выражение имело вид a[3:4:5] , то cap была бы равна 2 (5 — 3 = 2). Но при этом на сами данные он не влияет.

Появилась эта штука в Go 1.2.

Что можно почитать: Slicing a slice with slice [a : b : c] , Full slice expressions

Какое у слайса zero value? Какие операции над ним возможны?

Zero value у слайса всегда nil , а len и cap равны нулю, так как «под ним» нет инициализированного массива:

var a []int println(a == nil, len(a), cap(a)) // true 0 0 a = append(a, 1) println(a == nil, len(a), cap(a)) // false 1 1

Как видно из примера выше — несмотря на то, что a == nil (слайс «не инициализирован»), с этим слайсом возможна операция append — в этом случае Go самостоятельно создаёт нижележащий массив и всё работает так, как и ожидается. Более того — для полной очистки слайса рекомендуется его присваивать к nil .

Так же важно помнить, что не делая make для слайса — не получится сделать пре-аллокацию, что часто очень болезненно для производительности.

Что можешь рассказать про map ?

Карта ( map или hashmap ) — это неупорядоченная коллекция пар вида ключ-значение. Пример:

type myMap map[string]int

Подобно массивам и слайсам, к элементам мапы можно обратиться с помощью скобок:

var m = make(map[string]int) // инициализация m["one"] = 1 // запись в мапу fmt.Println(m["one"], m["two"]) // 1 0

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

В случае с m[«two»] вернулся 0 так как это является нулевым значением для типа int . Для проверки существования ключа используем конструкцию вида (доступ к элементу карты может вернуть два значения вместо одного) называемую «multiple assignment»:

var m = map[string]int v1, ok1 := m["one"] // чтение v2, ok2 := m["two"] fmt.Println(v1, ok1) // 1 true fmt.Println(v2, ok2) // 0 false for k, v := range m < // итерация всех эл-ов мапы fmt.Println(k, v) >delete(m, "one") // удаление v1, ok1 = m["one"] fmt.Println(v1, ok1) // 0 false

Мапы всегда передаются по ссылке (вообще-то Go не бывает ссылок, невозможно создать 2 переменные с 1 адресом, как в С++ например; но зато можно создать 2 переменные, указывающие на один адрес — но это уже указатели). Если же быть точнее, то мапа в Go — это просто указатель на структуру hmap :

type hmap struct < // Note: the format of the hmap is also encoded in cmd/compile/internal/reflectdata/reflect.go. // Make sure this stays in sync with the compiler's definition. count int // # live cells == size of map. Must be first (used by len() builtin) flags uint8 B uint8 // log_2 of # of buckets (can hold up to loadFactor * 2^B items) noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details hash0 uint32 // hash seed buckets unsafe.Pointer // array of 2^B Buckets. may be nil if count==0. oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing nevacuate uintptr // progress counter for evacuation (buckets less than this have been evacuated) extra *mapextra // optional fields >

Так же структура hmap содержит в себе следующее:

• Количество элементов
• Количество «ведер» (представлено в виде логарифма для ускорения вычислений)
• Seed для рандомизации хэшей (чтобы было сложнее заddosить — попытаться подобрать ключи так, что будут сплошные коллизии)
• Всякие служебные поля и главное указатель на buckets, где хранятся значения

На картинке схематичное изображение структуры в памяти — есть хэдер hmap, указатель на который и есть map в Go (именно он создается при объявлении с помощью var, но не инициализируется, из-за чего падает программа при попытке вставки). Поле buckets — хранилище пар ключ-значение, таких «ведер» несколько, в каждом лежит 8 пар. Сначала в «ведре» лежат слоты для дополнительных битов хэшей ( e0..e7 названо e — потому что extra hash bits). Далее лежат ключи и значения как сначала список всех ключей, потом список всех значений.

По хэш функции определяется в какое «ведро» мы кладем значение, внутри каждого «ведра» может лежать до 8 коллизий, в конце каждого «ведра» есть указатель на дополнительное, если вдруг предыдущее переполнилось.

Как растет map ?

В исходном коде можно найти строчку Maximum average load of a bucket that triggers growth is 6.5 . То есть, если в каждом «ведре» в среднем более 6,5 элементов, происходит увеличение массива buckets . При этом выделяется массив в 2 раза больше, а старые данные копируются в него маленькими порциями каждые вставку или удаление, чтобы не создавать очень крупные задержки. Поэтому все операции будут чуть медленнее в процессе эвакуации данных (при поиске тоже, нам же приходится искать в двух местах). После успешной эвакуации начинают использоваться новые данные.

Из-за эвакуации данных нельзя и взять адрес мапы — представьте, что мы взяли адрес значения, а потом мапа выросла, выделилась новая память, данные эвакуировались, старые удалились, указатель стал неправильным, поэтому такие операции запрещены.

Что там про поиск?

Поиск, если разобраться, устроен не так уж и сложно: проходимся по цепочкам «ведер», переходя в следующее, если в этом не нашли. Поиск в «ведре» начинается с быстрого сравнения дополнительного хэша, для которого используется всего 8 бит (вот для чего эти e0. e7 в начале каждого — это «мини» хэш пары для быстрого сравнения). Если не совпало, идем дальше, если совпало, то проверяем тщательнее — определяем где лежит в памяти ключ, подозреваемый как искомый, сравниваем равен ли он тому, что запросили. Если равен, определяем положение значения в памяти и возвращаем.

К сожалению, мир не совершенен. Когда имя хешируется, то некоторые данные теряются, так как хеш, как правило, короче исходной строки. Таким образом, в любой реализации хеш таблицы неизбежны коллизии когда по двум ключам получаются одинаковые хеши. Как следствие, поиск может быть дороже чем O(1) (возможно это связано с кешем процессора и коллизиями коротких хэшей), так что иногда выгоднее использовать бинарный поиск по слайсу данных нежели чем поиск в мапе (пишите бенчмарки).

Что можно почитать: Хэш таблицы в Go. Детали реализации, Кажется, поиск в map дороже чем O(1)

Есть ли у map такие же методы как у слайса: len , cap ?

У мапы есть len но нет cap . У нас есть только overflow который указывает «куда-то» когда мапа переполняется, и поэтому у нас не может быть capacity .

Какие типы ключей разрешены для ключа в map ?

Любым сравнимым (comparable) типом, т.е. булевы, числовые, строковые, указатели, канальные и интерфейсные типы, а также структуры или массивы, содержащие только эти типы. Слайсы, мапы и функции использовать нельзя, так как эти типы не сравнить с помощью оператора == или != .

Может ли ключом быть структура? Если может, то всегда ли?

Как было сказано выше — структура может быть ключом до тех пор, пока мы в поля структуры не поместим какой-либо слайс, мапу или любой другой non-comparable тип данных (например — функцию).

Что будет в map , если не делать make или short assign ?

Будет паника (например — при попытке что-нибудь в неё поместить), так как любые «структурные» типы (а мапа как мы знаем таковой является) должны быть инициализированы для работы с ними.

Race condition. Потокобезопасна ли мапа?

Нет, потокобезопасной является sync.Map . Для обеспечения безопасности вокруг мапы обычно строится структура вида:

type ProtectedIntMap struct < mx sync.RWMutex m map[string]int >func (m *ProtectedIntMap) Load(key string) (val int, ok bool) < m.mx.RLock() val, ok = m.m[key] m.mx.RUnlock() return >func (m *ProtectedIntMap) Store(key string, value int)

Что такое интерфейс?

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

Как устроен Duck-typing в Go?

Если это выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

Если структура содержит в себе все методы, что объявлены в интерфейсе, и их сигнатуры совпадают — она автоматически удовлетворяет интерфейс.

Такой подход позволяет полиморфно (полиморфизм — способность функции обрабатывать данные разных типов) работать с объектами, которые не связаны в иерархии наследования. Достаточно, чтобы все эти объекты поддерживали необходимый набор методов.

Интерфейсный тип

В Go интерфейсный тип выглядит вот так:

type iface struct

Где tab — это указатель на Interface Table или itable — структуру, которая хранит некоторые метаданные о типе и список методов, используемых для удовлетворения интерфейса, а data указывает на реальную область памяти, в которой лежат данные изначального объекта (статическим типом).

Компилятор генерирует метаданные для каждого статического типа, в которых, помимо прочего, хранится список методов, реализованных для данного типа. Аналогично генерируются метаданные со списком методов для каждого интерфейса. Теперь, во время исполнения программы, runtime Go может вычислить itable на лету (late binding) для каждой конкретной пары. Этот itable кешируется, поэтому просчёт происходит только один раз.

Зная это, становится очевидно, почему Go ловит несоответствия типов на этапе компиляции, но кастинг к интерфейсу — во время исполнения.

Что важно помнить — переменная интерфейсного типа может принимать nil . Но так как объект интерфейса в Go содержит два поля: tab и data — по правилам Go, интерфейс может быть равен nil только если оба этих поля не определены (faq):

var ( builder *strings.Builder stringer fmt.Stringer ) fmt.Println(builder, stringer) // nil nil fmt.Println(stringer == nil) // true fmt.Println(builder == nil) // true stringer = builder fmt.Println(builder, stringer) // nil nil fmt.Println(stringer == nil) // false (. ) fmt.Println(builder == nil) // true

Пустой interface<>

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

На какой стороне описывать интерфейс — на передающей или принимающей?

Многое зависит от конкретного случая, но по умолчанию описывать интерфейсы следует на принимающей стороне — таким образом, ваш код будет меньше зависеть от какого-то другого кода/пакета/реализации.

Другими словами, если нам в каком-то месте требуется «что-то что умеет себя закрывать», или — умеет метод Close() error , или (другими словами) удовлетворят интерфейсу:

type something interface

То он (интерфейс) должен быть описан на принимающей стороне. Так принимающая сторона не будет ничего знать о том, что именно в неё может «прилететь», но точно знает поведение этого «чего-то». Таким образом реализуется инверсия зависимости, и код становится проще переиспользовать/тестировать.

Что такое замыкание?

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

Функции, у которых есть имя — это именованные функции. Функции, которые могут быть созданы без указания имени — это анонимные функции.

func main() < var text = "some string" var ourFunc = func() < // именованное замыкание println(text) >ourFunc() // some string getFunc()() // another string > func getFunc() func() < return func() < // анонимное println("another string") >>

Замыкания сохраняют состояние. Это означает, что состояние переменных содержится в замыкании в момент декларации. Одна из самых очевидных ловушек — это создание замыканий в цикле:

var funcs = make([]func(), 0, 5) for i := 0; i < 5; i++ < funcs = append(funcs, func() < println("counter =", i) >) // исправляется так: //var value = i //funcs = append(funcs, func() < println("counter https://kodazm.ru/articles/go/zamykaniya/" rel="nofollow noopener noreferrer">Замыкания 
Что такое сериализация? Зачем она нужна?
 
Сериализация — это процесс преобразования объекта в поток байтов для сохранения или передачи. Обратной операцией является десериализация (т.е. восстановление объекта/структуры из последовательности байтов). Синонимом можно считать термин "маршалинг" (от англ. marshal — упорядочивать).
 
Из минусов сериализации можно выделить нарушение инкапсуляции, т.е. после сериализации "приватные" свойства структур могут быть доступны для изменения.
 
Типичными примерами сериализации в Go являются преобразование структур в json-объекты. Кроме json существуют различные кодеки типа MessagePack, CBOR и т.д.
 
Что такое type switch?
 
Проверка типа переменной, а не её значения. Может быть в виде одного switch и множеством case:
 
package main func checkType(i interface<>) < switch i.(type) < case int: println("is integer") case string: println("is string") default: println("has unknown type") >>
А может в виде if -конструкции:
package main func main() < var any interface<>any = "foobar" if s, ok := any.(string); ok < println("this is a string:", s) >// а так можно проверить наличие функций у структуры if closable, ok := any.(interface< Close() >); ok < closable.Close() >>
Какие битовые операции знаешь?
Побитовые операторы проводят операции непосредственно на битах числа.
// Побитовое И/AND (разряд результата равен 1 только тогда, когда оба соответствующих бита операндов равны 1) println(0b111_000 /* 56 */ & 0b011_110 /* 30 */ == 0b011_000 /* 24 */) // Побитовое ИЛИ/OR (разряд результата равен 0 только тогда, когда оба соответствующих бита в равны 0) println(0b111_000 /* 56 */ | 0b011_110 /* 30 */ == 0b111_110 /* 62 */) // Исключающее ИЛИ/XOR (разряд результата равен 1 только тогда, когда только один бит равен 1) println(0b111_000 /* 56 */ ^ 0b011_110 /* 30 */ == 0b100_110 /* 38 */) // Сброс бита AND NOT println(0b111_001 /* 57 */ &^ 0b011_110 /* 30 */ == 0b100_001 /* 33 */) // Сдвиг бита влево println(0b000_001 /* 1 */ > 1 == 0b000_011 /* 3 */)
Пример использования простой битовой маски:
type Bits uint8 const ( F0 Bits = 1 func Clear(b, flag Bits) Bits < return b &^ flag >func Toggle(b, flag Bits) Bits < return b ^ flag >func Has(b, flag Bits) bool < return b&flag != 0 >func main() < var b Bits b = Set(b, F0) b = Toggle(b, F2) for i, flag := range [. ]Bits < println(i, Has(b, flag)) >// 0 true // 1 false // 2 true >
Что можно почитать: О битовых операциях, Поразрядные операции
Дополнительный блок фигурных скобок в функции
Его можно использовать, и он означает отдельный скоуп для всех переменных, объявленных в нём (возможен и "захват переменных" объявленных вне скоупа ранее, естественно). Иногда используется для декомпозиции какого-то отдельного куска функции, к примеру.
var i, s1 = 1, "foo" < var j, s2 = 2, "bar" println(i, s1) // 1 foo println(j, s2) // 2 bar s1 = "baz" >println(i, s1) // 1 baz //println(j, s2) // ERROR: undefined: j and s2
Так же это может быть связано с AST (Abstract Syntax Tree) — когда оно строится и происходят SSA (Static Single Assignment) оптимизации, к сожалению SSA не работает на всю длину дерева. Как следствие, если у нас слишком длинная функция (примерно дохулион строк) и мы по каким-то причинам не можем её декомпозировать, но можем изолировать какие-то скоупы то, таким образом, мы помогаем SSA произвести оптимизации (если они возможно).






Что такое захват переменной?
Во вложенном скоупе есть возможность обращаться к переменным, объявленных в скоупе выше (но не наоборот). Обращение к переменным из вышестоящего скоупа и есть их захват. Типичной ошибкой является использование значение итератора в цикле:
var out []*int for i := 0; i < 3; i++ < out = append(out, &i) >println(*out[0], *out[1], *out[2]) // 3 3 3
Испраляется путём создания локальной (для скоупа цикла) переменной с копией знаяения итератора:
var out []*int for i := 0; i < 3; i++ < i := i // Copy i into a new variable. out = append(out, &i) >println(*out[0], *out[1], *out[2]) // 0 1 2
Что можно почитать: Using reference to loop iterator variable
Как работает defer ?
Defer является функцией отложенного вызова. Выполняется всегда (даже в случае паники внутри функции вызываемой) после того, как функция завершила своё выполнение но до того, как управление вернётся вызывающей стороне (более того — внутри defer возможен захват переменных, и даже возвращаемого результата). Часто используется для освобождения ресурсов/снятия блокировок. Пример использования:
func main() < println("result =", f()) // f started // defer // defer in defer // result = 25 >func f() (i int) < println("f started") defer func() < recover() defer func() < println("defer in defer"); i += 5 >() println("defer") i = i * 2 >() i = 10 panic("panic is here") >
Когда выполняется ключевое слово defer , оно помещает следующий за ним оператор в список, который будет вызван до возврата функции.
Как работает init ?
В Go есть предопределенная функция init() . Она выделяет фрагмент кода, который должен выполняться перед всеми другими частями пакета. Этот код будет выполняться сразу после импорта пакета.
Также функция init() используется для автоматической регистрации одного пакета в другом (например, так работает подавляющее большинство "драйверов" для различных СУБД, например — go-sql-driver/mysql/driver.go).
Функцию init() можно использовать неоднократно в рамках даже одного файла, выполняться они будут в этом случае в порядке, как их встречает компилятор.
Хотя использование init() и является довольно полезным, но часто оно затрудняет чтение/понимание кода, и (почти) всегда можно обойтись без неё, поэтому необходимость её использования — всегда очень большой вопрос.






Прерывание for/switch или for/select
Что произойдёт в следующем примере, если f() вернёт true ?
Очевидно, будет вызван break . Вот только прерван будет switch , а не цикл for . Простое решение проблемы – использовать именованный (labeled) цикл и вызывать break c этой меткой, как в примере ниже:
loop: for < switch f() < case true: break loop case false: // Do something >>
Сколько можно возвращать значений из функции?
Теоретически, неограниченное количество значений. Так же хочется отметить, что есть правила "де-факто", которых следует придерживаться:

Последним значением возвращать ошибку, если её возврат подразумевается
Первым значением возвращать контекст, если он подразумевается
Хорошим тоном является не возвращать более четырёх значений
Если функция что-то проверяет и возвращает значение + булевый результат проверки — то результат проверки возвращать последним (пример — os.LookupEnv(key string) (string, bool) )
Если возвращается ошибка, то остальные значения возвращать нулевыми или nil

Дженерики — это про что?
Дженерики, или обобщения — это средства языка, позволяющего работать с различными типами данных без изменения их описания.
В версии 1.18 появились дженерики (вообще-то они были и ранее, но мы не могли их использовать в своём коде — вспомни функцию make(T type) ), и они позволяют объявлять (описывать) универсальные методы, т.е. в качестве параметров и возвращаемых значений указывать не один тип, а их наборы.
Появились новые ключевые слова:

any — аналог interface<> , можно использовать в любом месте ( func do(v any) any , var v any , type foo interface < Do() any >)
comparable — интерфейс, который определяет типы, которые могут быть сравнены с помощью == и != (переменные такого типа создать нельзя — var j comparable будет вызывать ошибку)

И появилась возможность определять интерфейсы, которые можно будет использовать в параметризованных функциях и типах (переменные такого типа создать нельзя — var j Int будет вызывать ошибку):
type Int interface
Если добавить знак ~ перед типами то интерфейсу будут соответствовать и производные типы, например myInt из примера ниже:






type Int interface < ~int | ~int32 | ~int64 >type myInt int
Разработчики golang создали для нас уже готовый набор интерфейсов (пакет constraints ), который очень удобно использовать.
Параметризованные функции
Рассмотрим пример функции, что возвращает максимум из двух переданных значений, причём тип может быть любым:
import "constraints" func Max[T constraints.Ordered](a T, b T) T < if a >b < return a >return b >
Ограничения на используемые типы описываются в квадратных скобочках. В качестве ограничения для типов можно использовать любой интерфейс и особые интерфейсы описанные выше.
Для слайсов и мап был создан набор готовых полезных функций.
Параметризованные типы
import "reflect" type myMap[K comparable, V any] map[K]V func main() < m := myMap[int, string]println(m[5]) // foo println(reflect.TypeOf(m)) // main.myMap[int,string] >
Что можно почитать: Зачем нужны дженерики в Go?, Golang пощупаем дженерики
Память и управление ей
Что такое heap и stack ?
Стек (stack) — это область оперативной памяти, которая создаётся для каждого потока. Он работает в порядке LIFO (Last In, First Out), то есть последний добавленный в стек кусок памяти будет первым в очереди на вывод из стека. Каждый раз, когда функция объявляет новую переменную, она добавляется в стек, а когда эта переменная пропадает из области видимости (например, когда функция заканчивается), она автоматически удаляется из стека. Когда стековая переменная освобождается, эта область памяти становится доступной для других стековых переменных.
Стек быстрый, так как часто привязан к кэшу процессора. Размер стека ограничен, и задаётся при создании потока.
Куча (heap) — это хранилище памяти, также расположенное в ОЗУ, которое допускает динамическое выделение памяти и не работает по принципу стека: это просто склад для ваших переменных. Когда вы выделяете в куче участок памяти для хранения переменной, к ней можно обратиться не только в потоке, но и во всем приложении. Именно так определяются глобальные переменные. По завершении приложения все выделенные участки памяти освобождаются. Размер кучи задаётся при запуске приложения, но, в отличие от стека, он ограничен лишь физически, и это позволяет создавать динамические переменные.






В сравнении со стеком, куча работает медленнее, поскольку переменные разбросаны по памяти, а не сидят на верхушке стека. То что попадает в кучу, живёт там пока не придёт GC.
Но почему стек так быстр? Основных причин две:

Стеку не нужно иметь сборщик мусора (garbage collector). Как мы уже упоминали, переменные просто создаются и затем вытесняются, когда функция завершается. Не нужно запускать сложный процесс освобождения памяти от неиспользуемых переменных и т.п.
Стек принадлежит одной горутине, переменные не нужно синхронизировать в сравнении с теми, что находятся в куче. Что также повышает производительность

Где выделяется память под переменную? Можно ли этим управлять?
Прямых инструментов для управления местом, где будет выделена память у нас, к сожалению — нет. Но есть некоторые практики, которые позволяют это понять и использовать эффективно.
Память под переменную может быть выделена в куче (heap) или стеке (stack). Очень приблизительно:

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

Давайте рассмотрим простой пример, в котором вы возвращаем значение:
func getFooValue() foo < var result foo // Do something return result >
Здесь переменная result создаётся в текущей горутине. И эта переменная помещается в стек. Как только функция завершает работу, клиент получает копию этой переменной. Исходная переменная вытесняется из стека. Эта переменная всё ещё существует в памяти, до тех пор, пока не будет затёрта другой переменной, но к этой переменной уже нельзя получить доступ.
Теперь тот же пример, но с указателем:
func getFooPointer() *foo < var result foo // Do something return &result >
Переменная result также создаётся текущей горутиной, но клиент получает указатель (копию адреса переменной). Если result вытеснена из стека, клиент функции не сможет получить доступ к переменной.






В подобном сценарии компилятор Go вынужден переместить переменную result туда, где она может быть доступна (shared) – в кучу (heap).
Хотя есть и исключение. Для примера:
func main() < p := &foo<>f(p) >
Поскольку мы вызываем функцию f() в той же горутине, что и функцию main() , переменную p не нужно перемещать. Она просто находится в стеке и вложенная функция f() будет иметь к ней доступ.
В качестве заключения, когда мы создаём функцию — поведением по умолчанию должно быть использование передачи по значению, а не по указателю. Указатель должен быть использован только когда мы действительно хотим переиспользовать данные.
Как работает Garbage Collection ( GC ) в Go?
Garbage Collection — это процесс освобождения места в памяти, которая больше не используется. Стек освобождается быстро и просто (условно-самостоятельно), а вот с кучей имеются некоторые сложности.
В основе работы GC в Go лежит:

"Трехцветный алгоритм пометки и очистки" (выполняется параллельно с основной программой) — все данные в куче представляются в виде связанного графа, каждая вершина которого (каждый объект, данные) может быть помечена как "белая", "серая", или "чёрная"; данный граф обходится в несколько проходов, все вершины размечаются своими цветами, и "белые" (мусорные) объекты могут быть удалены ("чёрные" — точно нельзя удалять; "серые" — под вопросом, пока не трогать)
Write Barrier, следящий за тем, чтоб черные объекты не указывали на белые; и "останавливать мир" (Stop The World, STW) для включения или отключения Write Barrier

GC можно вызвать ручками — runtime.GC() , но пользоваться этим нужно с осторожностью (есть риск блокировки вызывающей стороны или всего приложения целиком).
По умолчанию, GC запускается самостоятельно когда размер кучи становится в 2 раза больше (за это отвечает Pacer ; данный коэффициент можно регулировать при сборке с помощью env GOGC ).






Полный цикл работы GC:

Sweep termination — фаза завершения очистки: 

Stop the World
Ожидаем пока все горутины достигнут safe-point
Завершаем очистку ресурсов


Mark phase — фаза разметки (выполняется конкурентно с основной программой, выделяется на неё ~25% CPU): 

Включаем Write Barrier
Start the World
Запускаем сканирование глобальных переменных и стеков
При сканировании работа горутины приостанавливается (но не происходит полная остановка всей программы)
Выполняем 3-х цветный алгоритм поиска мусора


Mark termination — фаза завершения разметки 

Stop the World (не является обязательной, но с ней проце было реализовать)
Дожидаемся завершения обработки последних задач из очереди
Очистка кэшей
Завершаем разметку


Sweep phase — фаза очистки 

Отключаем Write Barrier
Start The World
Очистка ресурсов происходит в фоне




Не реализован алгоритм поколений (GC Generations)
Не реализовано уплотнение
Stop the World (STW), вызываемый аж дважды
Нет возможности тонкой настройки

Для оптимизации можно:
Какое поведение по умолчанию используется в Go при передаче в функцию?
По умолчанию всегда используется копирование, т.е. передача по значению. Для передачи по указателю необходимо это явно указывать:
func main() < var i = 5 byValue(i) // 5 byPointer(&i) // 5 >func byValue(i int) < println(i) >// передача по значению (копии переменной) func byPointer(i *int) < println(*i) >// передача по указателю
Что можешь рассказать про escape analysis?
Escape analysis — это процесс, который компилятор использует для определения размещения значений, созданных вашей программой.
В частности, компилятор выполняет статический анализ кода, чтобы определить, может ли значение быть помещено в стековый фрейм для функции, которая его строит, или значение должно "сбежать" в кучу. Используется разработчиками для оптимизации кода и аналитики причин возможного замедления.
Команда для запуска escape-анализа: go build -gcflags="-m" (так же можно использовать флаги -N для отключени оптимизаций, -l для отключения "инлайнинга").
Что можно почитать: Языковая механика escape analysis, Escape Analysis in Golang
Сoncurrency (конкурентность)
В данном разделе будут вопросы, относящиеся к параллелизму и конкурентной работе.
Как устроен мьютекс?
Mutex означает MUTual EXclusion (взаимное исключение), и обеспечивает безопасный доступ к общим ресурсам.






Под капотом мьютекса используются функции из пакета atomic ( atomic.CompareAndSwapInt32 и atomic.AddInt32 ), так что можно считать мьютекс надстройкой над atomic . Мьютекс медленнее чем atomic , потому что он блокирует другие горутины на всё время действия блокировки. А в свою очередь atomic быстрее потому как использует атомарные инструкции процессора.
В момент, когда нужно обеспечить защиту доступа — вызываем метод Lock() , а по завершению операции изменения/чтения данных — метод Unlock() .
В чем отличие sync.Mutex от sync.RWMutex ?
Помимо Lock() и Unlock() (у sync.Mutex ), у sync.RWMutex есть отдельные аналогичные методы только для чтения — RLock() и RUnlock() . Если участок в памяти нуждается только в чтении — он использует RLock() , который не заблокирует другие операции чтения, но заблокирует операцию записи и наоборот.
По большому счёту, RWMutex это комбинация из двух мьютексов.
Что такое synс.Map ?
Коротко — предоставляет атомарный доступ к элементам map .
Go, как известно, является языком созданным для написания concurrent программ — программ, который эффективно работают на мультипроцессорных системах. Но тип map не безопасен для параллельного доступа. То есть для чтения, конечно, безопасен — 1000 горутин могут читать из map без опасений, но вот параллельно в неё ещё и писать — уже нет.
Для обеспечения потоко-безопасного доступа к map можно использовать sync.RWMutex , но он имеет проблему производительности при работе на большом количестве ядер процессора (в RWMutex при блокировке на чтение каждая горутина должна обновить поле readerCount — простой счётчик, с помощью atomic.AddInt32() , что проиводит к сбросу кэша для этого адреса памяти для всех ядер, и каждое ядро становится в очередь и ждёт этот сброс и вычитывание из кэша — эта проблема называется cache contention).
sync.Map решает совершенно конкретную проблему cache contention в стандартной библиотеке для таких случаев, когда ключи в map стабильны (не обновляются часто) и происходит намного больше чтений, чем записей.






Пример работы с sync.Map :
var m sync.Map m.Store("one", 1) // запись one, ok := m.Load("one") // чтение fmt.Println(one, ok) // 1 true m.Range(func(k, v interface<>) bool < // итерация эл-ов мапы fmt.Println(k, v) // one 1 return true >) m.Delete("one") // удаление
Что можно почитать: Разбираемся с новым sync.Map в Go 1.9
Какие ещё примитивы синхронизации знаешь?
Как было сказано выше — для синхронизации можно использовать мьютексы. Кроме того из стандартной библиотеки нам доступны:
sync.WaitGroup
Используется для координации в случае, когда программе приходится ждать окончания работы нескольких горутин (эта конструкция похожа на CountDownLatch в Java). Отличный способ дождаться завершения набора одновременных операций. Принцип работы следующий:
var wg sync.WaitGroup wg.Add(1) // увеличиваем счётчик на 1 go func() < fmt.Println("task 1") () wg.Add(1) // увеличиваем счётчик на 1 go func() < fmt.Println("task 2") () wg.Wait() // блокируемся, пока счётчик не будет == 0 // task 2 // task 1 // task 2 done // task 1 done // Total time: 1.00s
sync.Cond
Условная переменная (CONDition variable) полезна, например, если мы хотим разблокировать сразу несколько горутин ( Broadcast ), что не получится сделать с помощью канала. Метод Signal отправляет сообщение самой долго-ожидающей горутине. Пример использования:
var ( c = sync.NewCond(&sync.Mutex<>) wg sync.WaitGroup // нужна только для примера free = true ) wg.Add(1) go func() < defer wg.Done() c.L.Lock() for !free < // проверяем, что ресурс свободен c.Wait() >fmt.Println("work") c.L.Unlock() >() free = false // забрали ресурс, чтобы выполнить с ним работу <-time.After(1 * time.Second) // эмуляция работы free = true // освободили ресурс c.Signal() // оповестили горутину wg.Wait()
sync.Once
Позволяет определить задачу для однократного выполнения за всё время работы программы. Содержит одну-единственную функцию Do , позволяющую передавать другую функцию для однократного применения.
var once sync.Once for i := 0; i < 10; i++ < once.Do(func() < fmt.Println("Hell yeah!") >) > // Hell yeah! (выводится 1 раз вместо 10)
sync.Pool
Используется для уменьшения давления на GC путём повторного использования выделенной памяти (потоко-безопасно). Пул необязательно освободит данные при первом пробуждении GC, но он может освободить их в любой момент. У пула нет возможности определить и установить размер и нет необходимости заботиться о его переполнении.
Что можно почитать: Go sync.Pool
Какие типы каналов существуют?
Если которотко, то синхронные (небуферизированным) и асинхронные (буферизированные), оба работают по принципу FIFO (first in, first out) очереди.
Канал — это объект связи, с помощью которого (чаще всего) горутины обмениваются данными. Потокобезопасен, передаётся "по указателю". Технически это можно представить как конвейер (или трубу), откуда можно считывать и помещать данные. Для создания канала предоставляет ключевое слово chan — создание не буферизированного канала c := make(chan int) , для чтения из канала — data := 






Запись данных в закрытый канал вызовет панику.
Чтение или запись данных в небуферизированный канал блокирует горутину и контроль передается свободной горутине. Через закрытый канал невозможно будет передать или принять данные (проверить открытость канала можно используя val, isOpened := закрыт и отсутствуют данные для чтения из него).
Буферизированный канал создается указанием второго аргумента для make — c := make(chan int, 5) , в этом случае горутина не блокируется до тех пор, пока буфер не будет заполнен. Подобно слайсам, буферизированный канал имеет длину ( len , количество сообщений в очереди, не считанных) и емкость ( cap , размер самого буфера канала):
c := make(chan string, 5) c println(val) > // "foo" // "bar"
При этом ok == true до того момента, пока в канале есть сообщения (вне зависимости от того, открыт он или закрыт), в противном случае ok == false а val будет нулевым значением в зависимости от типа данных канала. При попытке записи в закрытый канал будет паника (авторы языка так сделали "ибо нефиг — канал закрыт значит закрыт").
Используя буферизованный канал и цикл for val := range c < . >мы можем читать с закрытых каналов (поскольку у закрытых каналов данные все еще живут в буфере).
Кроме того, существует синтаксический сахар однонаправленных каналов (улучшает безопасность типов в программe, что, как следствие, порождает меньше ошибок):
Так же можно в сигнатуре принимаемой функции указать однонаправленность канала ( func write(c chan ) — в этом случае функция не сможет из него читать, а сможет только писать или закрыть его.
Читать "одновременно" из нескольких каналов возможно с помощью select (оператор select является блокируемым, за исключением использования default ):






c1, c2 := make(chan string), make(chan string) defer func() < close(c1); close(c2) >() // не забываем прибраться go func(c chan(c1) go func(c chan(c2) for i := 1; ; i++ < select < // блокируемся, пока в один из каналов не попадёт сообщение case val := if i >= 2 < // через 2 итерации выходим (иначе будет deadlock) break >> // channel 1 foo // channel 2 bar // Total execution time: 1.00s
В случае, если в оба канала одновременно придут сообщения (или они уже там были), то case будет выбран случайно (а не по порядку их объявления, как могло бы показаться).
Если ни один из каналов недоступен для взаимодействия, и секция default отсутствует, то текущая горутина переходит в состояние waiting до тех пор, пока какой-то из каналов не станет доступен.
Если в select указан default , то он будет выбран в том случае, если все каналы не имеют сообщений (таким образом select становится не блокируемым).
Под капотом (src/runtime/chan.go) канал представлен структурой:
type hchan struct < qcount uint // количество элементов в буфере dataqsiz uint // размерность буфера buf unsafe.Pointer // указатель на буфер для элементов канала elemsize uint16 // размер одного элемента в канале closed uint32 // флаг, указывающий, закрыт канал или нет elemtype *_type // содержит указатель на тип данных в канале sendx uint // индекс (смещение) в буфере по которому должна производиться запись recvx uint // индекс (смещение) в буфере по которому должно производиться чтение recvq waitq // указатель на связанный список горутин, ожидающих чтения из канала sendq waitq // указатель на связанный список горутин, ожидающих запись в канал lock mutex // мьютекс для безопасного доступа к каналу >
В общем случае, горутина захватывает мьютекс, когда совершает какое-либо действие с каналом, кроме случаев lock-free проверок при неблокирующих вызовах.
Go не выделяет буфер для синхронных (небуферизированных) каналов, поэтому указатель на буфер равен nil и dataqsiz равен нулю. При чтении из канала горутина произведёт некоторые проверки, такие как: закрыт ли канал, буферизирован он или нет, содержит ли гоуртины в send-очереди. Если ожидающих отправки горутин нет — горутина добавит сама себя в recvq и заблокируется. При записи другой горутиной все проверки повторяются снова, и когда она проверяет recvq очередь, она находит ожидающую чтение горутину, удаляет её из очереди, записывает данные в её стек и снимает блокировку. Это единственное место во всём рантайме Go, когда одна горутина пишет напрямую в стек другой горутины.
При создании асинхронного (буферизированного) канала make(chan bool, 1) Go выделяет буфер и устанавливает значение dataqsiz в единицу. Чтобы горутине отправить отправить значение в канал, сперва производятся несколько проверок: пуста ли очередь recvq , пуст ли буфер, достаточно ли места в буфере. Если всё ок, то она просто записывает элемент в буфер, увеличивает значение qcount и продолжает исполнение далее. Когда буфер полон, буферизированный канал будет вести себя точно так же, как синхронный (небуферизированный), тоесть горутина добавит себя в очередь ожидания и заблокируется.






Проверки буфера и очереди реализованы как атомарные операции, и не требуют блокировки мьютекса.
При закрытии канала Go проходит по всем ожидающим на чтение или запись горутинам и разблокирует их. Все получатели получают дефолтные значение переменных того типа данных канала, а все отправители паникуют.
Что можно делать с закрытым каналом?
Из закрытого канала можно читать с помощью for val := range c < . >— вычитает все сообщения что в нём есть, или с помощью:
for < if val, ok := else < break >>
Расскажи про планировщик (горутин)
Goroutine scheduler является перехватывающим задачи (work-stealing) планировщиком, который был введен еще в Go 1.1 Дмитрием Вьюковым вместе с командой Go. Основная его суть заключается в том, что он управляет:

G (горутинами) — просто горутины Go
M (машинами aka потоками или тредами) — потоки ОС, которые могут выполнять что-либо или же бездействовать
P (процессорами) — можно рассматривать как ЦП (физическое ядро); представляет ресурсы, необходимые для выполнения нашего Go кода, такие как планировщик или состояние распределителя памяти

Основная задача планировщика состоит в том, чтобы сопоставить каждую G (код, который мы хотим выполнить) с M (где его выполнять) и P (права и ресурсы для выполнения).
Когда M (поток ОС) прекращает выполнение нашего кода, он возвращает свой P (ЦП) в пул свободных P . Чтобы возобновить выполнение Go кода, он должен повторно заполучить его. Точно так же, когда горутина завершается, объект G (горутина) возвращается в пул свободных G и позже может быть повторно использован для какой-либо другой горутины.
Go запускает столько тредов, сколько доступно процессорных ядер (если вы специально это не перенастраиваете) и распределяет на эти треды сколько угодно горутин которые уже запускает программист. В один момент на одном ядре ЦП может находиться в исполнении только одна грутина, а в очереди исполнения их может быть неограниченное количество.
Треды M во время выполнения могут переходить от одного процессора P к другому. Например, когда тред делает системный вызов, в ответ на который ОС блокирует этот тред (например — чтение какого-то большого файла с диска) — мало того что заблокируется сама горутина, что спровоцировала этот вызов, но и все остальные, что стоят в очереди для этого процессора P . Чтоб этого не происходило — Go отвязывает горутины стоящие в очереди от этого процессора P и переназначает на другие.






Основные типы многозадачности что используются в большинстве ОС это "вытесняющая" (все ресурсы делятся между всеми программами одинаково, всем выделяется одинаковое время выполнения) и "кооперативная" (программы выполняются столько, сколько им нужно, и сами уступают друг-другу место). В Go используется неявная кооперативность:

Горутина уступает место другис при обращении к вводу-выводу, каналам, вызовам ОС и т.д.
Может уступить место при вызове любой функции (с некоторой вероятностью произойдет переключение между горутинами)
Есть явный способ переключить планировщик на другую горутину — вызвать функцию runtime.Gosched() (почти никогда не нужна, но она есть)

Основные принципы планировщика:

Очередь FIFO (first in — first out) — порядок запуска горутин обуславливается порядом их вызова
Необходимый минимум тредов — создается не больше тредов чем доступных ядер ЦП
Захват чужой работы — когда тред простаивает, то он не удаляется рантаймом Go, а будет по возможности "нагружен" работой, взятой из очередей горутин на исполнение с других тредов
"Неинвазивность" — работа горутин насильно не прерывается


Очередь FIFO (нет приоритезации и изменения порядка исполнения)
Отсутствие гарантий времени выполнения (времени запуска горутин)
Горутины могут перемещаться между тредами, что снижает эффективность кэшей

Что такое горутина?
Горутина (goroutine) — это функция, выполняющаяся конкурентно с другими горутинами в том же адресном пространстве.
Для её запуска достаточно использовать ключевое слово go перед именем вызываемой (или анонимной) функции.
Горутины очень легковесны (~2,6Kb на горутину). Практически все расходы — это создание стека, который очень невелик, хотя при необходимости может расти. Область их применения чаще всего следующая:

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

Сама структура горутины занимает порядка 600 байт, но для неё ещё выделяется и её собственный стек, минимальный размер котого составляет 2Kb, который увеличивается и уменьшается по мере необходимости (максимум зависит от архитектуры и составляет 1 ГБ для 64-разрядных систем и 250 МБ для 32-разрядных систем).
Переключение между двумя Горутинами — супер дешевое, O(1) , то есть, не зависит от количества созданных горутин в системе. Всё, что нужно сделать для переключения, это поменять 3 регистра — Program counter , Stack Pointer и DX .
В чем отличия горутин от потоков ОС?

Каждый поток операционной системы имеет блок памяти фиксированного размера (зачастую до 2 Мбайт) для стека — рабочей области, в которой он хранит локальные переменные вызовов функций, находящиеся в работе или приостановленные на время вызова другой функции. В противоположность этому go-подпрограмма начинает работу с небольшим стеком, обычно около 2 Кбайт. Стек горутины, подобно стеку потока операционной системы, хранит локальные переменные активных и приостановленных функций, но, в отличие от потоков операционной системы, не является фиксированным; при необходимости он может расти и уменьшаться
Потоки операционной системы планируются в ее ядре, а у go есть собственный планировщик (m:n) мультиплексирующий (раскидывающий) горутинки (m) по потокам (n). Основной плюс — отсутствие оверхеда на переключение контекста
Планировщик Go использует параметр с именем GOMAXPROCS для определения, сколько потоков операционной системы могут одновременно активно выполнять код Go. Его значение по умолчанию равно количеству процессоров (ядер) компьютера, так что на машине с 8 процессорами (ядрами) планировщик будет планировать код Go для выполнения на 8 потоках одновременно. Спящие или заблокированные в процессе коммуникации go-подпрограммы потоков для себя не требуют. Go-подпрограммы, заблокированные в операции ввода-вывода или в других системных вызовах, или при вызове функций, не являющихся функциями Go, нуждаются в потоке операционной системы, но GOMAXPROCS их не учитывает
В большинстве операционных систем и языков программирования, поддерживающих многопоточность, текущий поток имеет идентификацию, которая может быть легко получена как обычное значение (обычно — целое число или указатель). У горутин нет идентификации, доступной программисту. Так решено во время проектирования языка, поскольку локальной памятью потока программисты злоупотребляют

Где аллоцируется память для горутин?
Так как горутины являются stackful — то и память для них (их состояние) хранится на стеке. Поэтому, теоретически, если очень постараться и сделать миллиард вложенных вызовов, то можно сделать себе переполнение стека.






Для самих же переменных, что используются внутри горутин память берётся с хипа (ограничены только размером "физического" хипа, т.е. объемом памяти сколько есть на машине).
Как завершить много горутин?
Один из вариантов — это пристрелить main (шутка). Работу одной гороутины в принципе нельзя принудительно остановить из другой. Механизмы их завершения необходимо реализовывать отдельно (учить сами горутины завершаться).
Наиболее часто используются 2 подхода — это использование контекста context.Context :
import ( "context" "time" ) func f(ctx context.Context) < loop: for < select < case > > func main() < ctx, cancel := context.WithCancel(context.Background()) for i := 0; i < 3; i++ < go f(ctx) // запускаем 3 горутины ><-time.After(time.Millisecond * 50) cancel() // отменяем контекст, на что горутины должны среагировать выходом <-time.After(time.Millisecond * 60) // do some work // do some work // do some work // break f // break f // break f >
И отдельного канала для уведомлений о необходимости завершения (часто для уведомлений используется пустая структура struct<> , которая ничего не весит):
import ( "time" ) func f(c ) < loop: for < select < case > > func main() < const workersCount = 3 var c = make(chan struct<>, workersCount) for i := 0; i < workersCount; i++ < go f(c) // запускаем 3 горутины ><-time.After(time.Millisecond * 50) for i := 0; i < workersCount; i++ < c <- struct<><> // отправляем 3 сообщения в канал (по одному для каждой горутины) о выходе > // ВООБЩЕ - цикл с отправкой сообщений НЕ является обязательным, и можно просто закрыть канал close(c) <-time.After(time.Millisecond * 60) // do some work // do some work // do some work // break f // break f // break f >
Кейсы использования контекста
Пакет context в Go особенно полезен при взаимодействиях с API и медленными процессами, особенно в production-grade системах. С его помощью можно уведомить горутины о необходимости завершить свою работу, "пошарить" какие-то данные (например, в middleware), или легко организовать работу с таймаутом.
context.WithCancel()
Эта функция создает новый контекст из переданного ей родительского, возвращая первым аргументом новый контекст, а вторым — функцию "отмены контекста" (при её вызове родительский контект "отменен" не будет). Важно — вызывать функцию отмены контекста должна только та функция, которая его создает. При вызове функции отмены сам контекст и все контексты, созданные на основе него получат в ctx.Done() пустую структуру и в ctx.Err() ошибку context.Canceled .
ctx, cancel := context.WithCancel(context.Background()) fmt.Println(ctx.Err()) // nil cancel() fmt.Println( <-ctx.Done()) // <>fmt.Println(ctx.Err().Error()) // context canceled
context.WithDeadline()
Так же создает контекст от родительского, который отменится самостоятельно при наступлении переданной временной отметке, или при вызове функции отмены. Отмена/таймаут затрагивает только сам контекст и его "наследников". ctx.Err() возвращает ошибку context.DeadlineExceeded . Полезно для реализации таймаутов:
ctx, cancel := context.WithDeadline( context.Background(), time.Now().Add(time.Millisecond*100), ) defer cancel() fmt.Println(ctx.Err()) // nil <-time.After(time.Microsecond * 110) fmt.Println(<-ctx.Done()) // <>fmt.Println(ctx.Err().Error()) // context deadline exceeded
context.WithTimeout()
Работает аналогично context.WithDeadline() за исключением того, что принимает в качестве значения таймаута длительность (например — time.Second ):






ctx, cancel := context.WithTimeout(context.Background(), time.Second*2)
context.WithValue()
Позволяет "пошарить" данные через всё контекстное дерево "ниже". Часто используют чтоб передать таким образом, например, логгер или HTTP запрос в цепочке middleware (но в 9 из 10 случаев так делать не надо, это можно считать антипаттерном). Лучше всего использовать функции для помещения/извлечения данных из контекста (так как "в нём" они храняться как interface<> ):
import ( "context" "log" "os" ) const loggerCtxKey = "logger" // should be unique func PutLogger(ctx context.Context, logger *log.Logger) context.Context < return context.WithValue(ctx, loggerCtxKey, logger) >func GetLogger(ctx context.Context) *log.Logger < return ctx.Value(loggerCtxKey).(*log.Logger) >func f(ctx context.Context) < logger := GetLogger(ctx) logger.Print("inside f") println(logger) >func main() < var ( logger = log.New(os.Stdout, "", 0) ctxWithLogger = PutLogger(context.Background(), logger) ) logger.Printf("main") println(logger) f(ctxWithLogger) // main // 0xc0000101e0 // inside f // 0xc0000101e0 >
Что можно почитать: Разбираемся с пакетом Context в Golang
Как задетектить гонку?
Пишем тесты, и запускаем их с флагом -race (в этом случае рантайм будет в случайном порядке переключаться между горутинами (если не ошибаюсь), и компилятор генерирует дополнительный код, который "журналирует" обращения к памяти). Этот флаг можно использовать как для go test , так и для go run или go build .
Детектор гонки основан на библиотеке времени выполнения (runtime library) C/C++ ThreadSanitizer.
Так же предпочитаю писать тесты, провоцирующие гонку. Код в этом случае будет работать значительно медленнее, но для этапа тестирования это и не так важно. А именно для тестируемой структуры запускаю (например) 100 горутин которые читают и пишут что-то в случайном порядке.
Важно и ещё одно высказывание — "Если race detector обнаруживает состояние гонки, то оно у вас наверняка есть; если же не обнаруживает — то это не означает что его нет".
Тестирование
Для unit-тестирования (aka модульного) используется команда вида go test , которая запускает все функции, что начинаются с префикса Test в файлах, что имеют в своем имени постфикс _test.go — всё довольно просто.
Важно писать сам код так, чтоб его можно было протестировать (например — не забывать про инвертирование зависимостей и использовать интерфейсы там, где они уместны).
TDT, Table-driven tests (табличное тестирование)
Являются более предпочтительным вариантом для тестирования множества однотипных кейсов перед описанием "один кейс — один тест", так как позволяют отделить часть входных данных и ожидаемых данных от всех этапов инициализации и tear-down (не знаю как это будет по-русски). Например, тестируемая функция и её тест могут выглядеть так:






package main func Sum(a, b int) int
package main import "testing" func TestSum(t *testing.T) < for name, tt := range map[string]struct < // ключ мапы - имя теста giveOne, giveSecond int wantResult int >< "1 + 1 = 2": < giveOne: 1, giveSecond: 1, wantResult: 2, >, "140 + 6 = 146": < giveOne: 140, giveSecond: 6, wantResult: 146, >, > < t.Run(name, func(t *testing.T) < // setup here if res := Sum(tt.giveOne, tt.giveSecond); res != tt.wantResult < t.Errorf("Unexpected result. Want %d, got %d", tt.wantResult, res) >// teardown here >) > >
Имя пакета с тестами
Если имя пакета в файле с тестами ( foo_test.go ) указывать с постфиксом _test (например — имя пакета, для которого пишутся тесты foo , а имя пакета указанное в самом файле с тестами для него — foo_test ), то в тестах не будет доступа в не-экспортируемым свойствам, структурам и функциям, таким образом тестирование пакета будет происходить "как извне", и не будет соблазна пытаться использовать что-то приватное, что в пакете содержится. По идее, в одной директории не может находиться 2 и более файлов, имена пакетов в которых отличаются, но *_test является исключением из этого правила.
Более того, этот подход стимулирует тестировать API, а не внутренние механизмы, т.е. относиться к функциональности как к "черному ящику", что очень правильно.
Статические анализаторы (линтеры)
Уже давно на все случаи жизни существует golangci-lint, который является универсальным решением, объединяющим множество линтеров в "одном флаконе". Удобен как для запуска локально, так и на CI.
Ошибка в бенчмарке
Про бенчмарки — иногда встречается кейс с написанием бенчмарка который внутри своего цикла выполняет тестируемую функцию, а результат этого действия никуда не присваивается и не передаётся:
func BenchmarkWrong(b *testing.B) < for i := 0; i < b.N; i++ < ourFunc() >>
Компилятор может принять это во внимание, и будет выполнять её содержимое как inline-последовательность инструкций. После чего, компилятор определит, что вызовы тестируемой функции не имеет никаких побочных эффектов (side-effects), т.е. никак не влияет на среду исполнения. После чего вызов тестируемой функции будет просто удалён. Один из вариантов избежать сценария выше – присваивать результат выполнения функции переменной уровня пакета. Примерно так:
var result uint64 func BenchmarkCorrect(b *testing.B) < var r uint64 for i := 0; i < b.N; i++ < r = ourFunc() >result = r >
Теперь компилятор не будет знать, есть ли у функции side-effect и бенчмарк будет точен.
Что про функциональное тестирование?
Тут всё зависит от того, что мы собираемся тестировать, и тянет на отдельную тему для разговора. Для HTTP посоветовать можно postman и его CLI-версию newman. Ещё как вариант "быстро и просто" — это hurl.
Для за-mock-ивания стороннего HTTP API — jmartin82/mmock или lamoda/gonkey.






Профилирование ( pprof )
Для профилирования "родными" средствами в поставке с Go имеется пакет pprof и одноименная консольная утилита go tool pprof . Причинами необходимости в профилировании могут стать:

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

Профилировщик является семплирующим — с какой-то периодичностью мы прерываем работу программы, берем стек-трейс, записываем его куда-то, а в конце, на основе того, как часто в стек-трейсах встречаются разные функции, мы понимаем, какие из них использовали больше ресурсов процессора, а какие меньше. Работа с ним состоит из двух этапов — сбор статистики по работе сервиса, и её визуализация + анализ. Собирать статистику можно добавив вызовы пакета pprof , либо запустив HTTP сервер.
Пример использования pprof
Рассмотрим простой случай, когда у нас есть функция, которая выполняется по какой-то причине очень долго. Обрамим вызовы потенциально-тяжелого кода в startPprof и stopPprof :
Подробности
package main import ( "os" "runtime/pprof" "time" ) func startPprof() *os.File < // вспомогательная функция начала профилирования f, err := os.Create("profile.pprof") if err != nil < panic(err) >if err = pprof.StartCPUProfile(f); err != nil < panic(err) >return f > func stopPprof(f *os.File) < // вспомогательная функция завершения профилирования pprof.StopCPUProfile() if err := f.Close(); err != nil < panic(err) >> func main() < // наша основания функция var ( slice = make([]int, 0) m = make(map[int]int) ) pprofFile := startPprof() // начинаем профилирование // тут начинается какая-то "тяжелая" работа for i := 0; i < 10_000_000; i++ < slice = append(slice, i*i) >for i := 0; i < 10_000_000; i++ < m[i] = i * i >
После компиляции и запуска приложения ( go build -o ./main . && ./main ) в текущей директории появится файл с именем profile.pprof , содержащий профиль работы. "Конвертируем" его в читаемое представление в виде svg изображения с помощью go tool pprof -svg ./profile.pprof (на Linux для этого понадобится установленный пакет graphviz ) и открываем его (имя файла будет в виде profile001.svg ):

Посмотрим на получившийся граф вызовов. Изучая такой граф, в первую очередь нужно обращать внимание на толщину ребер (стрелочек) и на размер узлов графа (квадратиков). На ребрах подписано время — сколько времени данный узел или любой из ниже лежащих узлов находился в стек-трейсе во время профилирования.
В нашем профиле можем заметить, что runtime evacuate_fast64 занимает очень много времени. Связано это с тем, что из мапы данным приходиться эвакуироваться, так как размер мапы очень сильно растёт. Исправляем это (а заодно и слайс) всего в двух строчках:
var ( slice = make([]int, 0, 10_000_000) // заставляем аллоцировать память в слайсе m = make(map[int]int, 10_000_000) // и в мапе заранее )
Повторяем все сделанные ранее операции снова, и видим уже совсем другую картину:

Теперь картина значительно лучше, и следующее место оптимизации (потенциально) это пересмотреть работу с данными, а именно — нужна ли нам работа с мапой в принципе (может заменить её каким-то слайсом), и если нет — то как можно улучшить (оптимизировать) запись в неё.
Так как же профилировщик работает в принципе?
Go runtime просит ОС посылать сигнал ( man setitimer ) с определенной периодичностью и назначает на этот сигнал обработчик. Обработчик берет стек-трейс всех горутин, какую-то дополнительную информацию, записывает ее в буфер и выходит.
Каковы же недостатки данного подхода?

Каждый сигнал — это изменение контекста, вещь довольно затратная в наше время. В Go сейчас получается получить порядка 100 в секунду. Иногда этого мало
Для нестандартных сборок, например, с использованием -buildmode=c-archive или -buildmode=c-shared , профайлер работать по умолчанию не будет. Это связано с тем, что сигнал SIGPROF (который посылает ОС) придет в основной поток программы, который не контролируется Go
Процесс user space , которым является программа на Go, не может получить ядерный стек-трейс. Неоптимальности и проблемы иногда кроются и в ядре

Основное преимущество, конечно, в том, что Go runtime обладает полной информацией о своем внутреннем устройстве. Внешние средства, например, по умолчанию ничего не знают о горутинах. Для них существуют только процессы и треды.
Что можно почитать: Профилирование и оптимизация программ на Go
Компилятор
Компиляция — это процесс преобразования вашего (говно)кода в кашу из машинного кода. Первое понятно тебе, второе — машине.
Из каких этапов состоит компиляция?
cmd/compile содержит основные пакеты Go компилятора. Процесс компиляции может быть логически разделен на четыре фазы:

Parsing ( cmd/compile/internal/syntax ) — сорец парсится, разбивается на токены, создается синтаксическое дерево
Type-checking and AST (Abstract Syntax Tree) transformations ( cmd/compile/internal/gc ) — дерево переводится в AST, тут же происходит магия по авто-типизации, проверок интерфейсов этапа компиляции, определяется мертвый код и происходит escape-анализ
Generic SSA (Static Single Assignment) ( cmd/compile/internal/gc , cmd/compile/internal/ssa ) — AST переводится в SSA (промежуточное представление более низкого уровня), что упрощает реализацию оптимизаций; так же применяются множественные оптимизации этого уровня (тут, например, циклы range переписываются в обычные for ; а copy заменяется перемещением памяти), удаляются ненужные проверки на nil и т.д.
Generating machine code ( cmd/compile/internal/ssa , cmd/internal/obj ) — универсальные штуки перезаписываются на машинно-зависимые (в зависимости от архитектуры и ОС), после чего над SSA снова выполняются оптимизации, удаляется мертвый код, распределяются регистры, размечается стековый фрейм; после — ассемблер превращает всё это добро в машинный код и записывает объектный файл

Что можно почитать: Введение в компилятор Go
Статическая компиляция/линковка — что это, и в чем особенности?
Линковка (ну или компоновка) последний этап сборки. Статически слинкованный исполняемый файл не зависит от наличия других библиотек в системе во время своей работы.
Для включения статической компиляции/линковки (при этом все внешние библиотеки, от которых зависит исполнение кода будут встроены в итоговый бинарный файл) необходимо использовать переменную окружения при сборке CGO_ENABLED=0 (т.е. CGO_ENABLED=0 go build . ). Полученный бинарный файл можно безбоязненно использовать, например, в docker-образе, основанном на scratch (т.е. не содержащем абсолютно никаких файлов, кристально чистая файловая система).
Однако, это накладывает некоторые ограничения и привносит особенности, которые необходимо помнить:

C -код будет недоступен, совсем (часть модулей из stdlib Go от него зависят, к слову, но не критичных)
Не будет использоваться системный DNS-резольвер
Не будет работать проверка x.509 сертификатов, которая должна работать на MacOS X

И ещё, если итоговый бинарный файл планируется использовать в docker scratch , то так же следует иметь в виду:

Для осуществления HTTP запросов по протоколу HTTPS вашим приложением, в образ нужно будет поместить корневые SSL/TLS сертификаты /etc/ssl/certs
Файл временной зоны ( /etc/timezone ) тоже будет необходим, чтоб корректно работать с датой/временем

Что можно почитать: Docker scratch & CGO_ENABLED=0, Кросс-компиляция в Go, Go dns
Какие директивы компилятора знаешь?
Компилятор Go понимает некоторые директивы (пишутся они в виде комментариев, как правило //go:directive ), которые влияют на процесс компиляции (оптимизации, проверок, и т.д.) но не являются частью языка. Вот некоторые из них:
//go:linkname
Указывает компилятору реальное местонахождение функции или переменной. Можно использовать для вызова приватных функций из других пакетов. Требует импортирования пакета unsafe ( import _ "unsafe" ). Формат следующий:
//go:linkname localname [importpath.name]
import ( _ "strings" // for explodeString _ "unsafe" // for go:linkname ) //go:linkname foo main.bar func foo() string func bar() string < return "bar" >//go:linkname explodeString strings.explode func explodeString(s string, n int) []string func main() < println(foo()) // bar println(explodeString("foo", -1)) // [3/3]0xc0000a00f0 >
//go:nosplit
Указывается при объявлении функции, и указывает на то, что вызов функции должен пропускать все обычные проверки на переполнение стека.
//go:norace
Так же указывается при объявлении функции и "выключает" детектор гонки (race detector) для неё.
//go:noinline
Отключает оптимизацию "инлайнига" для функции. Обычно используется отладки компилятора, escape-аналитики или бенчаркинга.
//go:noescape
Тоже "функциональная" директива, смысл которой сводится к тому, что "я доверяю этой функции, и ни один указатель, переданных в качестве аргументов (или возвращенных) этой функции не должен быть помещен в кучу (heap)".
//go:build
Эта директива обеспечивает условную сборку. То есть мы можем "размечать" тегами файлы, и таким образом компилировать только определенные их "наборы" (тегов может быть несколько, а так же можно использовать ! для указания "не"). Часто используется для кодогенерации, указывая какой-то специфичный тег (например ignore — //go:build ignore ) чтоб файл никогда не учавствовал с борке итогового приложения.
В качестве примера создадим 2 файла в одной директории:
// file: main.go //go:build one package main func main()
// file: main2.go //go:build two package main func main()
И соберем с разными значениями -tags для go build или go run (обрати внимение — какой именно файл собирать не указывается, только тег):
$ go run -tags one . one! $ go run -tags two . two!
//go:generate
Позволяет указать какие внешние команды должны вызваться при запуске go generate . Таким образом, мы можем использовать кодогенерацию, к примеру, или выполнять какие-то операции что дожны предшевствовать сборке (например — //go:generate go run gen.go где gen.go это файл, что содержит //go:build ignore т.е. исключён из компиляции, но при этом генерирует для нас какие-то полезные данные и/или целые .go файлы):
package main //go:generate echo "my build process" func main()
$ go generate my build process
//go:embed
Позволяет "встраивать" внешние файлы в Go приложение. Требует импортирования пакета embed ( import _ "embed" ). Поддерживает типы string , []byte и embed.FS . Пример использования:
package main import _ "embed" //go:embed test.txt var hello string func main()
$ echo "hello world" > test.txt $ go run . hello world


Похожие публикации:

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