Где можно использовать горутины в Go?

Question

[yativ_sobb]

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

Я бы хотел узнать в каких интересных задачи вы использовали горутины?

Comments

[Roman K]

А как связаны массивы и списки с горутинами?

[yativ_sobb]

Верно, как связаны, признаю ошибку. Но вопрос остается открытым

[Александр Павлюк]

Вы какие проекты пишете? Если веб-сервис делаете, то вы уже используете горутины, потому что пакет http каждый принятый запрос обрабатывает в отдельной горутине.

[yativ_sobb]

Да, веб сервисы

Answer 1

[Евгений Мамонов]

Самый простой пример - это HTTP сервер.
Когда к вам приходит HTTP запрос - создаётся горутина и каждый запрос спокойно обрабатывается, никто никого не ждёт. Т.е. сервер может обрабатывать параллельно несколько запросов как раз за счёт горутин.

Фактически, почти во всех сетевых сервисах есть смысл использовать горутины для распараллеливания обработки запросов (кроме epoll, kqueue и т.п.)

Еще хороший пример.
Вам нужно сделать парсер Авито :)) или индесатор сайтов.
Т.е. задача сводится к тому, что нужно будет постоянно качать страницы с сайтов.
Если вы будете качать одну страницу за другой - вы будете очень долго качать.
А так вы можете сделать пул из нескольких горутин (как минимум по 1 на поток процессора) и получите параллельное скачивание страниц.

Для ускорения работы вычислений (параллельные вычисления) есть смысл использовать горутины только по 1 на поток процессора). Т.е. в случаях, когда у вас огромный объём данных и нужно максимально ускорить его обработку. Например у вас файл 100Гб, и 8 ядер в процессоре - вы можете разбить файл на 8 частей и параллельно эти части обработать (в самом простом варианте, в реальной жизни нужно будет просто по частям считывать новые данные и скармливать свободной горутине)

Еще когда нужно сделать чтобы какая нибудь задача выполнялась в "фоне".
Например периодическая очистка кеша/устаревший записей в базе.

Реальных примеров намного больше :)
В целом их есть смысл использовать там, где нужно параллельное выполнение какой либо задачи или разных задач параллельно :)

Comments

[Rouslan943]

Например 4000 http запросов, тоже обрабатываются параллельно?

[Евгений Мамонов]

Ну... почти :)

Смотрите, в рамках одного CPU, выполняться может только одна задача.
Раньше, когда в процессорах всегда было только одно ядро - параллельно ничего выполняться не могло.

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

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

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

Т.е. отвечая на ваш вопрос - часть HTTP запросов равное количеству ядер процессора (если это указано в приложении) будет выполняться одновременно, остальная часть будет выполняться по очереди. Но за счёт того, что операции ввода/вывода очень затратные по времени (не соизмеримо с затратами на переключение между процессами) - будет создаваться впечатление, что оно обрабатывается параллельно :)
На деле оно так и будет выглядеть.

Если вы запустите какой нибудь тест HTTP сервера, который будет создавать одновременные подключения то, когда у вас будет параллельно идти, скажем, 10 запросов - время ответа будет маленькое, когда бы поставите 1000 запросов одновременно - время ответа увеличится за счёт того, что задач, которые должны выполняться параллельно становится много и суммарное время на переключения CPU между ними увеличивается. Ну и, конечно, оно еще может сильно увеличиться за счёт ограничения пропускной способности сети, но этот вариант и другие возможные причины мы не рассматриваем в рамках вопроса о параллельном выполнении горутин :)

Answer 2

[d'Ivan]

Задачи у всех разные. Вы работали с потоками? Это похоже на них.

Простой пример:
Есть 2 запроса в БД. Один длится, скажем, 3 секунд, другой 10 секунд. И нет зависимости одного от другого.
Если выполнять их последовательно, это займет 13 секунд. Многовато. Почесав лоб, вы приходите к другому решению:
выполнять 2 запроса одновременно, каждый запрос в горутине! Дождавшись их окончания, пройдет 10 секунд. Экономия!

Другой пример:
Вы работаете с очередями. В одну очередь вы отправляете команды задач, а в другой вы получаете их результаты. Разумеется, и продюсер и консюмер должны работать независимо друг от друга. Как вы запускаете их в Го?
Правильно, двумя горутинами!

Answer 3

[uvelichitel]

В основном для asyncIO, асинхронного ввода/вывода.