2017-02-15 32 views
-3

У меня есть большой файл .json, который имеет около 2 Мб. Я использую this code читать JSON, с небольшим изменением:Почему моя программа Go создает другой процесс Go с именем открытого файла и почему он такой большой?

func main() { 
    pages := getPages() 
    for { 

    } 
    for _, p := range pages { 
     fmt.Println(p.toString()) 
    } 

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

go run myfile.go

, но потом я получил 2 двоичных файлов: один по имени go, а другой с именем файла без JSon части. Бинарный файл go имеет 5 Мбайт, но у этого есть 36mb ...

Почему go создает другой процесс с именем файла? Это где он держит файл, чтобы я мог читать? Почему это так? Насколько мне известно, чтение файла должно быть передано ОС. И почему он настолько велик по сравнению с размером .json?

Кроме того, не должно, когда getPages() вернуть, как объект файла, так и объект json будут удалены из памяти из-за сборщика мусора go?

+2

Бесконечная петля без сна или любая плохая идея, она потребляет много CPU. Является ли файл указан URL-адресом точного кода, который вы используете? –

+0

Было бы сложно помочь вам, если вы не ответите на комментарии –

+0

, но затем я получил 2 бинарных файла: один по имени go, а другой с именем файла без части json. У двоичного файла go есть 5mb, но у этого есть 36mb ... 'go run' не создает двоичные файлы в рабочем каталоге –

ответ

4

Почему происходит создание другого процесса с именем файла?

Это не так. Ты сделал. Когда вы делаете go run main.go Вы используете программу go, которая компилирует ваш main.go в другой исполняемый файл (вы помните, что Go - это скомпилированный язык, производящий собственные исполняемые файлы?) И выполняет этот второй исполняемый файл. Вы сказали инструмент go, чтобы сделать это, и он ведет себя так, как сказано. Если вам это не нравится: go build -o whatever; ./whatever.

Кроме того, не должно быть, когда getPages() возвращается, как объект файла, так и объект json будут удалены из памяти из-за сборщика мусора go?

Да и это на самом деле происходит. Это просто не наблюдается в том, как вы пытались его проверить. Управление памятью в Go сложное и сложное взаимодействие с управлением памятью ОС (и зависит от ОС), так и управление памятью ОС.

Очень грубо: объекты Unreferenced собираются Go GC, но эта память не возвращается в ОС, поскольку «возврат» и «повторная покупка» из ОС - очень дорогостоящая операция, поэтому память не «возвращаются» в ОС (если это необходимо).

Поиск SO или сети для «go не выпускает память», если вы считаете, что детали управления памятью вас интересуют.

 Смежные вопросы

  • Нет связанных вопросов^_^