👍6❤2🔥1
Многие разработчики начинают с горутин и каналов, но быстро теряются: когда стоит использовать WaitGroup, а когда select? Как правильно закрывать каналы и избегать утечек горутин?
Ответы есть — в бесплатном онлайн-руководстве Go 101, которое разбирает конкурентность в Go максимально чётко и практично.
Вот ключевые главы, которые стоит пройти по порядку:
Goroutines: как Go управляет потоками, стеком и планировщиком
👉 go101.org/article/control-flows-more.html
Channels: основы синхронизации между горутинами и передача данных без блокировок
👉 go101.org/article/channel.html
Channel use cases: шаблоны, ошибки и приёмы для реальных задач — от worker pool до fan-in/fan-out
👉 go101.org/article/channel-use-cases.html
Synchronization overview: обзор всех инструментов — мьютексы, атомики, условия и таймеры
👉 go101.org/article/concurrent-synchronization-overview.html
После этих четырёх статей вы поймёте, почему конкурентность в Go - это не просто «многопоточность», а архитектурная философия языка.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2👍1
🧩 Go Квиз: оцените отношение времени g()/f()
#Golang
Идея проста: какая из функций будет «дороже» и во сколько раз?
- f делает три умножения на итерацию плюс запись в массив. Это «дешёвая» арифметика с линейным проходом по памяти.
- g на каждой итерации создаёт срез a[:] и вызывает doNothing. Если компилятор встраивает пустую функцию и выкидывает бесполезный срез, тело цикла почти исчезает. Если запретить инлайнинг, вы получите N вызовов функции и накладные расходы на создание среза на каждой итерации.
Чего ожидать?
С инлайнингом и DCE: g() часто быстрее f(), потому что почти ничего не делает, тогда как f() реально пишет в память. Отношение g()/f() < 1.
Без инлайнинга: g() резко замедляется из-за стоимости вызова функции и построения среза на каждой итерации. Отношение g()/f() ≫ 1, иногда на порядок.
Вывод: результат зависит от оптимизаций компилятора. «Смысл» цикла, который не производит наблюдаемых эффектов, Go охотно выкидывает.
Как проверить у себя
Что запомнить
- Микробенчи в Go чувствительны к инлайнингу и dead-code elimination.
- Запись в память удерживает цикл «реальным», тогда как пустые вызовы и срезы могут исчезнуть.
- Измеряйте обе конфигурации: с оптимизациями и без, чтобы понять истинную стоимость.
Если коротко:
- В реальном билде с оптимизациями g()/f() обычно < 1.
- С запретом инлайнинга g()/f() обычно ≫ 1 из-за накладных расходов вызова.
#Golang
Идея проста: какая из функций будет «дороже» и во сколько раз?
const N = 1 << 12
func f(){
for a, i := [N]int{}, 0; i < len(a); i++ {
a[i] = i * i * i * i
}
}
func doNothing(a []int) {}
func g(){
for a, i := [N]int{}, 0; i < len(a); i++ {
doNothing(a[:])
}
}
- f делает три умножения на итерацию плюс запись в массив. Это «дешёвая» арифметика с линейным проходом по памяти.
- g на каждой итерации создаёт срез a[:] и вызывает doNothing. Если компилятор встраивает пустую функцию и выкидывает бесполезный срез, тело цикла почти исчезает. Если запретить инлайнинг, вы получите N вызовов функции и накладные расходы на создание среза на каждой итерации.
Чего ожидать?
С инлайнингом и DCE: g() часто быстрее f(), потому что почти ничего не делает, тогда как f() реально пишет в память. Отношение g()/f() < 1.
Без инлайнинга: g() резко замедляется из-за стоимости вызова функции и построения среза на каждой итерации. Отношение g()/f() ≫ 1, иногда на порядок.
Вывод: результат зависит от оптимизаций компилятора. «Смысл» цикла, который не производит наблюдаемых эффектов, Go охотно выкидывает.
Как проверить у себя
Копировать код
# обычный режим
go test -bench . -benchmem
# отключить инлайнинг -l, чтобы увидеть цену вызова функции
go test -gcflags='-l' -bench . -benchmem
Что запомнить
- Микробенчи в Go чувствительны к инлайнингу и dead-code elimination.
- Запись в память удерживает цикл «реальным», тогда как пустые вызовы и срезы могут исчезнуть.
- Измеряйте обе конфигурации: с оптимизациями и без, чтобы понять истинную стоимость.
Если коротко:
- В реальном билде с оптимизациями g()/f() обычно < 1.
- С запретом инлайнинга g()/f() обычно ≫ 1 из-за накладных расходов вызова.
❤2👍2🔥1
Anonymous Quiz
7%
Для очистки ненужных файлов проекта
86%
Для удаления из go.mod и go.sum ненужных зависимостей
7%
Для компиляции проекта без зависимостей
0%
Для запуска тестов
Anonymous Quiz
28%
byte
61%
rune
6%
int
5%
string
❓ Что не так с этим кодом на Go? И чего вы ожидаете на выходе?
На первый взгляд - всё понятно. Но на самом деле это ловушка 😏
Вы переопределяете iota как обычную константу, равную самой себе (iota = iota). С этого момента iota перестаёт быть магической переменной, и счётчик сбрасывается.
Поэтому Y получает значение 0, а не 1 — как многие ожидают.
Вывод программы: 0
💡 Мораль: никогда не переназначайте iota внутри const, иначе потеряете её «магию».
Запустить код: https://go.dev/play/p/7xu1qRUcp2O
package main
func main() {
const (
iota = iota
Y
)
println(Y)
}
На первый взгляд - всё понятно. Но на самом деле это ловушка 😏
Вы переопределяете iota как обычную константу, равную самой себе (iota = iota). С этого момента iota перестаёт быть магической переменной, и счётчик сбрасывается.
Поэтому Y получает значение 0, а не 1 — как многие ожидают.
Вывод программы: 0
💡 Мораль: никогда не переназначайте iota внутри const, иначе потеряете её «магию».
Запустить код: https://go.dev/play/p/7xu1qRUcp2O
👍6❤1🔥1😢1
package main
import (
"encoding/json"
"fmt"
"reflect"
)
type S struct {
A []int `json:"a"`
B []int `json:"b"`
}
func main() {
var a []int // nil
b := []int{} // пустой
fmt.Println(a == nil, len(a), cap(a)) // ?
fmt.Println(b == nil, len(b), cap(b)) // ?
fmt.Println(reflect.DeepEqual(a, b)) // ?
x := S{A: a, B: b}
d, _ := json.Marshal(x)
fmt.Println(string(d))
}
Ответ:
false 0 0
false
{"a":null,"b":[]}
👉 Запустить код: https://go.dev/play/p/PaqGcSwGqpV
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4❤3
Anonymous Quiz
10%
false false false
2%
false false true
25%
false true true
7%
true false true
57%
true true true
Anonymous Quiz
40%
go run -race
7%
go build -race
25%
go test -race
28%
Все варианты верны
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Если присвоить интерфейсу значение nil конкретного типа, сравнение с nil вернёт false, потому что у интерфейса уже есть динамический тип. Запомни правило: интерфейс равен nil только когда и тип отсутствует, и значение nil.
package main
import (
"fmt"
"os"
)
func main() {
var err error = (*os.PathError)(nil)
fmt.Println(err == nil)
}
https://www.youtube.com/shorts/vobogCxfoLk
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🤯4❤2
👍2
package main
import "fmt"
func main() {
s := []int{1, 2, 3, 4}
t := s[1:3] // t = [2, 3]
t = append(t, 99) // возможно, меняет s[3]
s[2] = 42 // изменяем s напрямую
fmt.Println("s:", s)
fmt.Println("t:", t)
}
Ответ :
t: [2 42 99]
⚡️ Запустить код: https://go.dev/play/p/96RGE1ea6Sq
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4❤3🤔2
This media is not supported in your browser
VIEW IN TELEGRAM
package main
import (
"errors"
"fmt"
)
type myError struct{}
func (m *myError) Error() string {
return "something went wrong"
}
func returnsNilError() error {
var e *myError = nil
return e
}
func main() {
err := returnsNilError()
fmt.Println("err == nil:", err == nil) // неожиданно false
fmt.Println("err:", err)
}
Вывод:
err: something went wrong
⚡️ Заплатить код: https://go.dev/play/p/lrw5DEthEvS
@golangtests
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2🥰1
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 САМЫЙ ЭФФЕКТИВНЫЙ АЛГОРИТМ ПОИСКА В GO
Бинарный поиск - один из самых быстрых способов найти элемент в отсортированном слайсе. Вместо полного прохода он делит диапазон пополам, работая за O(log n). Используй его везде, где данные можно заранее отсортировать - прирост скорости огромный.
Бинарный поиск - один из самых быстрых способов найти элемент в отсортированном слайсе. Вместо полного прохода он делит диапазон пополам, работая за O(log n). Используй его везде, где данные можно заранее отсортировать - прирост скорости огромный.
package main
import "fmt"
func binSearch(a []int, t int) bool {
l, r := 0, len(a)-1
for l <= r {
m := (l + r) / 2
if a[m] == t { return true }
if a[m] < t { l = m + 1 } else { r = m - 1 }
}
return false
}
func main() {
nums := []int{1,4,7,9,15,20,33,42}
fmt.Println(binSearch(nums, 33))
fmt.Println(binSearch(nums, 100))
}
👍5❤3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Планировщик задач в Golang работает по схеме G-P-M:
горутины (G) распределяются по логическим процессорам (P), а те в свою очередь выполняются на системных потоках (M).
Так достигается мультиплексирование миллионов горутин на ограниченное число потоков ОС.
Когда горутина блокируется (syscall, mutex, канал без данных) - её паркуют, а поток освобождают.
Когда появляется работа — планировщик перебрасывает G между очередями P и старается держать все ядра загруженными.
Чтобы код работал эффективно:
- не плодите лишние горутины
- избегайте долгих блокировок
- контролируйте GOMAXPROCS
- проверяйте количество G через runtime
package main
import (
"fmt"
"runtime"
"time"
)
func main() {
runtime.GOMAXPROCS(runtime.NumCPU())
for i := 0; i < 5; i++ {
go func(id int) {
for {
fmt.Println("goroutine", id, "работает на потоке")
time.Sleep(200 * time.Millisecond)
}
}(i)
}
for {
fmt.Println("горутин сейчас:", runtime.NumGoroutine())
time.Sleep(time.Second)
}
}
https://www.youtube.com/shorts/XQmGO29JE7w
#junior #golang
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥1