> Что такое потоки ввода-вывода в Linux (Go)

Короткий ответ

Потоки ввода-вывода в Linux - это абстракция, представляющая последовательность байт, с которой программа может читать или записывать данные. Всё в Linux - файл: обычные файлы, сокеты, pipe, терминалы. Потоки делятся на три стандартных: stdin (0), stdout (1), stderr (2). В Go работа с потоками реализована через интерфейсы io.Reader и io.Writer, что позволяет единообразно обрабатывать любые источники данных.

Подробное объяснение

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

• stdin (дескриптор 0) - входной поток, обычно клавиатура
• stdout (дескриптор 1) - выходной поток, обычно терминал
• stderr (дескриптор 2) - поток ошибок, тоже терминал, но отдельный

Ключевые свойства потоков:

1. Последовательность - данные читаются и пишутся по порядку, без произвольного доступа (в отличие от файлов с позиционированием)
2. Абстракция - программа не знает, откуда приходят данные (файл, сеть, pipe), она работает с единым интерфейсом
3. Блокирующий/неблокирующий режимы - по умолчанию операции блокирующие, но можно настроить неблокирующий режим
4. Буферизация - данные могут накапливаться в буфере перед фактической записью/чтением

В Go эта концепция реализована через интерфейсы:

GO
type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

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

На практике

В реальной разработке на Go потоки используются повсеместно:

• Чтение HTTP-запроса - r.Body реализует io.Reader
• Запись HTTP-ответа - w реализует io.Writer
• Работа с файлами - os.File реализует оба интерфейса
• Логирование - log.Logger пишет в io.Writer
• Сжатие данных - gzip.Reader/gzip.Writer оборачивают другие потоки

Паттерн оборачивания потоков - ключевой в Go. Например, можно обернуть файл в bufio.Reader для буферизованного чтения или в gzip.Reader для распаковки.

Перенаправление потоков в командной строке:

BASH
go run main.go < input.txt > output.txt 2> errors.log

Пример кода

GO
package main

import (
    "fmt"
    "io"
    "os"
    "strings"
)

func main() {
    // Чтение из строки как из потока
    reader := strings.NewReader("hello, world")
    buf := make([]byte, 5)
    
    for {
        n, err := reader.Read(buf)
        if err == io.EOF {
            break
        }
        if err != nil {
            fmt.Fprintln(os.Stderr, "read error:", err)
            return
        }
        fmt.Printf("read %d bytes: %q\n", n, buf[:n])
    }
    
    // Запись в поток
    writer := os.Stdout
    writer.Write([]byte("written to stdout\n"))
    
    // Копирование между потоками
    io.Copy(os.Stdout, strings.NewReader("copied text\n"))
}

Как отвечать на собеседовании

Начни с определения: потоки - это абстракция последовательного доступа к данным. Упомяни три стандартных потока и их дескрипторы. Подчеркни, что в Linux всё - файл, поэтому потоки универсальны.

Затем перейди к Go: интерфейсы io.Reader и io.Writer - это основа работы с потоками. Приведи примеры: os.File, net.Conn, bytes.Buffer - все реализуют эти интерфейсы.

Если спросят про производительность - упомяни буферизацию через bufio. Если про обработку ошибок - скажи, что io.EOF - это нормальное завершение чтения, а не ошибка.

Хорошо показать понимание композиции: как можно обернуть один поток в другой (например, gzip.NewReader(file)).

Что проверяет интервьюер

Интервьюер оценивает:

• Понимание базовой концепции потоков в Unix
• Знание стандартных потоков и их назначения
• Умение работать с интерфейсами io.Reader/io.Writer в Go
• Понимание паттерна оборачивания потоков
• Умение обрабатывать io.EOF корректно
• Понимание разницы между блокирующим и неблокирующим вводом-выводом

Для junior-позиции достаточно уверенного владения базовыми операциями чтения/записи и понимания интерфейсов.

Типичные ошибки

• Игнорирование io.EOF - считают его ошибкой, хотя это штатное завершение чтения
• Не проверяют n при чтении - Read может вернуть данные и ошибку одновременно
• Путают stdout и stderr - для ошибок нужно использовать stderr, а не stdout
• Не закрывают потоки - забывают про defer file.Close(), что приводит к утечке дескрипторов
• Читают в цикле без обработки частичного чтения - Read не гарантирует заполнение всего буфера
• Используют os.Stdin/os.Stdout напрямую вместо интерфейсов - это усложняет тестирование
• Не понимают разницу между буферизованным и небуферизованным вводом-выводом - это влияет на производительность