Может обновление памяти от 2 ГБ до 4 ГБ, предотвращают Исключения из-за переполнения стека?

Почти наверняка не . Переполнение стека (а не нехватка памяти) означает, что вы израсходовали выделенное пространство стека , но стек (относительно говоря) невелик. куча - это то место, где все это происходит ...

Параметры:

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

Нет. Увеличение ОЗУ не увеличивает размер стека.

Вы пишете код, который вызывает переполнение стека (возможно, из-за рекурсии), и вам нужно это исправить.

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

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

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

Размер этой виртуальной памяти равен диапазону, который может адресуются одним машинным регистром. В 32-битных операционных системах это означает около 4 ГБ. Сейчас, независимо от того, сколько фактической памяти есть в вашей системе, ваша программа всегда будет думать, что у него есть 4 ГБ.

Теперь эти 4 ГБ фактически распределяются между вашей программой и пространством, которое операционная система резервирует для обработки данных в режиме ядра как а также поддержание структур, необходимых для вашей программы. На практике вы можете рассчитывать примерно на 2 или 3 ГБ в зависимости от вашей конфигурации (конфигурации вашей ОС). Все это не имеет ничего общего с объемом имеющейся у вас физической памяти, у вас может быть 256 МБ ОЗУ, но ваша программа все равно будет думать, что у него есть 2 ГБ в своем распоряжении.

Когда вы выделяете память, система обычно этого не делает. предоставьте именно то количество памяти, которое вы просите. Вместо этого он использует страницы, которые представляют собой блоки зарезервированной памяти (например, 4 КБ), назначенные вашему процессу. Когда вы это сделаете, ОС зарегистрирует эту "страницу" как выделено, но все еще находится в виртуальной памяти. Внутренне ОС управляет тем, какие из этих страниц хранятся в физической памяти, а какие в разделе подкачки (на жестком диске). Это причина того, что увеличение вашей оперативной памяти увеличивает вашу производительность (больше страниц может быть в основной памяти одновременно, и вам нужно меньше читать с жесткого диска), но не поможет при переполнении стека (или исключении Out of memory на путь).

И это , почему увеличение вашей оперативной памяти не поможет.

Наконец, об исключении Stack Overflow ... ну, трудно сказать, не видя фактического кода, некоторые хорошие ответы уже были даны.

В основном переполнение стека происходит в результате бесконечной рекурсии, прямой или косвенной (A -> B -> C -> A), но в вашем конкретном случае я бы сказал, что вы: re просто выделяет много данных в стеке.

У вас есть массив размером 70000. Я предполагаю, что этот массив полон типов значений, которые выделяются в стеке, который, если я правильно помню (и, пожалуйста, не принимайте это как факт), составляет 1 МБ в .NET, что может быть причиной того, что вы получаете ваш стек переполнен.

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

Изменить: или исправить бесконечную рекурсию, которая может быть в вашем коде.

Переполнение стека может означать бесконечную рекурсию ИЛИ очень глубоко вложенную.

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

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

Собственно, нет. Но у меня другая причина: Windows XP может обрабатывать только до 2 ГБ, если вы не укажете конкретный параметр загрузки в boot.ini. (Параметр / 3gb.) В лучшем случае Windows XP и Vista будут иметь до 3 ГБ ОЗУ, и это в основном предел для Windows. См. Ссылку для получения дополнительной информации об этих ограничениях.

Увеличение объема оперативной памяти и исправление вашего приложения для выхода за пределы ограничения в 2 ГБ может исправить переполнение стека, так как это может увеличить размер вашего стека. Это также может просто отсрочить момент этого переполнения стека, поскольку, как было предложено, ваш код находится в бесконечном рекурсивном цикле и будет продолжать выполняться до тех пор, пока не закончатся ресурсы.

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