что и где находится стек и куча?

<p>книги по языку программирования объясняют, что типы значений создаются в<strong> stack </strong>, а ссылочные типы создаются в<strong> heap </strong>без объяснения того, что представляют собой эти две вещи. я не прочитал четкое объяснение этого. я понимаю, что<em> стек </em>есть. но,</p><ul> <li>где и что они (физически в памяти реального компьютера)?</li> <li>в какой степени они контролируются ос или языком времени выполнения?</li> <li>какова их сфера применения?</li> <li>от чего зависит размер каждого из них?</li> <li>что делает быстрее?</li> </ul>

<p>стек - это память, выделенная как пустое место для потока выполнения. когда вызывается функция, блок резервируется в верхней части стека для локальных переменных и некоторых бухгалтерских данных. когда эта функция возвращается, блок становится неиспользованным и может быть использован при следующем вызове функции. стек всегда зарезервирован в порядке lifo (последний в порядке очереди); последний зарезервированный блок всегда является следующим блоком, который должен быть освобожден. это действительно упрощает отслеживание стека; освобождение блока из стека - это не более, чем настройка одного указателя.</p><p>куча памяти выделяется для динамического выделения. в отличие от стека, нет принудительного шаблона распределения и удаления блоков из кучи; вы можете выделить блок в любое время и освободить его в любое время. это значительно усложняет отслеживание того, какие части кучи выделены или свободны в любой момент времени; есть много пользовательских распределителей кучи, доступных для настройки производительности кучи для различных моделей использования.</p><p>каждый поток получает стек, в то время как для приложения обычно есть только одна куча (хотя весьма часто иметь несколько куч для разных типов размещения).</p><p>чтобы ответить на ваши вопросы напрямую: </p><blockquote> <p><em>в какой степени они контролируются ос или языковой средой выполнения?</em></p> </blockquote><p>ос выделяет стек для каждого потока системного уровня при создании потока. обычно ос вызывается языковой средой выполнения для выделения кучи для приложения.</p><blockquote> <p><em>какова их сфера применения?</em></p> </blockquote><p>стек присоединен к потоку, поэтому, когда поток выходит из стека, он освобождается. куча обычно выделяется при запуске приложения средой выполнения и восстанавливается при выходе из приложения (технически процесса).</p><blockquote> <p><em>от чего зависит размер каждого из них?</em> </p> </blockquote><p>размер стека устанавливается при создании потока. размер кучи устанавливается при запуске приложения, но может увеличиваться по мере необходимости в пространстве (распределитель запрашивает больше памяти у операционной системы).</p><blockquote> <p><em>что делает быстрее?</em></p> </blockquote><p>стек работает быстрее, потому что шаблон доступа упрощает выделение и освобождение памяти из него (указатель/целое число просто увеличивается или уменьшается), в то время как куча имеет гораздо более сложную бухгалтерию, связанную с выделением или освобождением. кроме того, каждый байт в стеке имеет тенденцию использоваться очень часто, что означает, что он, как правило, отображается в кэш процессора, что делает его очень быстрым. другим ударом производительности для кучи является то, что куча, являющаяся главным образом глобальным ресурсом, как правило, должна быть многопоточной безопасной, то есть каждое распределение и освобождение должно быть - как правило - синхронизировано со «всеми» другими обращениями к куче в программе.</p><p>четкая демонстрация: <img src="https://i.stack.imgur.com/i6k0z.png" alt=""> <br/><sub>источник изображения: <a href="http://vikashazrati.wordpress.com/2007/10/01/quicktip-java-basics-stack-and-heap/">vikashazrati.wordpress.com</a> </sub></p>

<p><strong> стек: </strong></p><ul> <li>хранится в компьютере ram, как в куче.</li> <li>переменные, созданные в стеке, выйдут из области видимости и будут автоматически освобождены.</li> <li>гораздо быстрее выделить по сравнению с переменными в куче.</li> <li>реализовано с фактической структурой данных стека.</li> <li>хранит локальные данные, обратные адреса, используемые для передачи параметров.</li> <li>может иметь переполнение стека, когда используется слишком много стека (в основном из-за бесконечной или слишком глубокой рекурсии, очень больших выделений).</li> <li>данные, созданные в стеке, могут использоваться без указателей.</li> <li>вы бы использовали стек, если точно знаете, сколько данных нужно выделить перед компиляцией, и он не слишком велик.</li> <li>обычно максимальный размер уже определен при запуске вашей программы.</li> </ul><p><strong> куча: </strong></p><ul> <li>хранится на компьютере ram точно так же, как и стек.</li> <li>в c++ переменные в куче должны быть уничтожены вручную и никогда не выпадать из области видимости. данные освобождаются с помощью <code>delete</code>, <code>delete[]</code> или <code>free</code>.</li> <li>медленнее выделять по сравнению с переменными в стеке.</li> <li>используется по требованию для выделения блока данных для использования программой.</li> <li>может иметь фрагментацию, когда есть много выделений и освобождений.</li> <li>в c++ или c данные, созданные в куче, будут указываться указателями и размещаться соответственно с <code>new</code> или <code>malloc</code>.</li> <li>может иметь ошибки выделения, если запрошен слишком большой буфер.</li> <li>вы бы использовали кучу, если не знаете точно, сколько данных вам потребуется во время выполнения или если вам нужно выделить много данных.</li> <li>ответственный за утечки памяти.</li> </ul><p><strong> пример: </strong></p><pre class="lang-cpp prettyprint-override"><code>int foo() { char *pbuffer; //<--nothing allocated yet (excluding the pointer itself, which is allocated here on the stack). bool b = true; // allocated on the stack. if(b) { //create 500 bytes on the stack char buffer[500]; //create 500 bytes on the heap pbuffer = new char[500]; }//<-- buffer is deallocated here, pbuffer is not }//<--- oops there's a memory leak, i should have called delete[] pbuffer; </code></pre>

<p>наиболее важным моментом является то, что куча и стек являются общими терминами для способов выделения памяти. они могут быть реализованы различными способами, и эти термины применяются к основным понятиям.</p><ul> <li><p>в пачке предметов предметы располагаются один над другим в том порядке, в котором они были там размещены, и вы можете удалить только верхний (не переворачивая все это).</p> <p><img src="https://i.stack.imgur.com/zlzmv.jpg" alt="stack like a stack of papers"></p> <p>простота стека заключается в том, что вам не нужно поддерживать таблицу, содержащую запись каждого раздела выделенной памяти; единственная информация о состоянии, которая вам нужна, - это единственный указатель на конец стека. чтобы выделить и удалить, вы просто увеличиваете и уменьшаете этот единственный указатель. примечание: иногда может быть реализован стек, который начинается в верхней части раздела памяти и расширяется вниз, а не растёт вверх.</p></li> <li><p>в куче нет определенного порядка расположения элементов. вы можете входить и удалять предметы в любом порядке, потому что нет четкого «верхнего» предмета.</p> <p><img src="https://i.stack.imgur.com/kinqo.jpg" alt="heap like a heap of licorice allsorts"></p> <p>выделение кучи требует ведения полной записи о том, какая память выделена, а что нет, а также некоторых служебных расходов для уменьшения фрагментации, поиска смежных сегментов памяти, достаточно больших, чтобы соответствовать требуемому размеру, и так далее. память может быть освобождена в любое время, оставляя свободное место. иногда распределитель памяти выполняет задачи обслуживания, такие как дефрагментация памяти, перемещая выделенную память или собирая мусор - идентифицируя во время выполнения, когда память больше не находится в области действия, и освобождает ее. </p></li> </ul><p>эти образы должны довольно хорошо описать два способа выделения и освобождения памяти в стеке и куче. yum!</p><ul> <li><p>в какой степени они контролируются ос или языковой средой выполнения?</p> <p>как уже упоминалось, куча и стек являются общими терминами и могут быть реализованы многими способами. компьютерные программы обычно имеют стек, называемый <a href="http://en.wikipedia.org/wiki/call\_stack">стек вызовов</a> , в котором хранится информация, относящаяся к текущей функции, такая как указатель на функцию, из которой она была вызвана, и любые локальные переменные. поскольку функции вызывают другие функции и затем возвращаются, стек увеличивается и сжимается, чтобы хранить информацию от функций дальше по стеку вызовов. программа на самом деле не имеет контроля над ней во время выполнения; это определяется языком программирования, ос и даже архитектурой системы.</p> <p>куча - это общий термин, используемый для любой памяти, которая выделяется динамически и случайным образом; то есть не в порядке. память обычно выделяется ос, при этом приложение вызывает функции api для этого. при управлении динамически распределяемой памятью требуются значительные накладные расходы, которые обычно обрабатываются ос.</p></li> <li><p>какова их сфера применения?</p> <p>стек вызовов является настолько низкоуровневой концепцией, что он не имеет отношения к «объему» в смысле программирования. если вы разберете некоторый код, вы увидите относительные ссылки на стиль указателя на части стека, но, что касается языка более высокого уровня, язык налагает свои собственные правила области видимости. однако одним важным аспектом стека является то, что, как только функция возвращается, все, что является локальным для этой функции, немедленно освобождается из стека. это работает так, как вы и ожидаете, учитывая работу ваших языков программирования. в куче это тоже сложно определить. область действия - это то, что доступно операционной системе, но ваш язык программирования, вероятно, добавляет свои правила о том, что такое «область действия» в вашем приложении. архитектура процессора и ос используют виртуальную адресацию, которую процессор преобразует в физические адреса, имеются сбои страниц и т.д. они отслеживают, какие страницы принадлежат каким приложениям. однако вам никогда не нужно беспокоиться об этом, потому что вы просто используете любой метод, используемый вашим языком программирования, для выделения и освобождения памяти, и проверяете на наличие ошибок (если по какой-либо причине распределение/освобождение не удается).</p></li> <li><p>от чего зависит размер каждого из них?</p> <p>опять же, это зависит от языка, компилятора, операционной системы и архитектуры. стек обычно предварительно выделяется, потому что по определению он должен быть смежной памятью (подробнее об этом в последнем абзаце). компилятор языка или ос определяют его размер. вы не храните огромные порции данных в стеке, поэтому они будут достаточно большими, чтобы никогда не использовать их полностью, за исключением случаев нежелательной бесконечной рекурсии (отсюда «переполнение стека») или других необычных программных решений.</p> <p>куча - это общий термин для всего, что может быть динамически выделено. в зависимости от того, как вы на это смотрите, размер постоянно меняется. в современных процессорах и операционных системах точный способ его работы в любом случае очень абстрагирован, поэтому обычно вам не нужно сильно беспокоиться о том, как он работает в глубине, за исключением того, что (в языках, где это позволяет) вы не должны использовать память, которая вы еще не распределили или память, которую вы освободили.</p></li> <li><p>что делает быстрее?</p> <p>стек быстрее, потому что вся свободная память всегда смежна. не нужно поддерживать список всех сегментов свободной памяти, только один указатель на текущую вершину стека. для этого компиляторы обычно хранят этот указатель в специальном быстром <a href="http://en.wikipedia.org/wiki/stack\_register">регистре</a> . более того, последующие операции над стеком обычно сосредоточены в очень близких областях памяти, что на очень низком уровне хорошо для оптимизации кэш-памятью процессора.</p></li> </ul>

<p>(я переместил этот ответ из другого вопроса, который был более или менее обманчивым.)</p><p>ответ на ваш вопрос зависит от конкретной реализации и может варьироваться в зависимости от компилятора и архитектуры процессора. однако вот упрощенное объяснение.</p><ul> <li>и стек, и куча являются областями памяти, выделенными из базовой операционной системы (часто это виртуальная память, которая отображается по требованию на физическую память).</li> <li>в многопоточной среде каждый поток будет иметь свой собственный полностью независимый стек, но они будут совместно использовать кучу. параллельный доступ должен контролироваться в куче и невозможен в стеке.</li> </ul><h2>куча</h2><ul> <li>куча содержит связанный список используемых и свободных блоков. новые выделения в куче (с помощью <code>new</code> или <code>malloc</code>) выполняются путем создания подходящего блока из одного из свободных блоков. это требует обновления списка блоков в куче. эта<em> метаинформация </em>о блоках в куче также хранится в куче часто в небольшой области перед каждым блоком.</li> <li>по мере роста кучи новые блоки часто распределяются от более низких адресов к более высоким адресам. таким образом, вы можете думать о куче как<em> heap </em>блоков памяти, размер которых увеличивается по мере выделения памяти. если куча слишком мала для выделения, ее размер часто можно увеличить, получая больше памяти из базовой операционной системы.</li> <li>выделение и освобождение многих маленьких блоков может оставить кучу в состоянии, когда между используемыми блоками расположено много маленьких свободных блоков. запрос на выделение большого блока может потерпеть неудачу, поскольку ни один из свободных блоков не является достаточно большим, чтобы удовлетворить запрос на выделение, даже если объединенный размер свободных блоков может быть достаточно большим. это называется<em> фрагментация кучи </em>.</li> <li>когда используемый блок, который смежен со свободным блоком, освобожден, новый свободный блок может быть объединен со смежным свободным блоком, чтобы создать больший свободный блок, эффективно уменьшающий фрагментацию кучи.</li> </ul><p><img src="https://i.stack.imgur.com/0obi0.png" alt="the heap"></p><h2>стек</h2><ul> <li>стек часто работает в тесном тандеме со специальным регистром на процессоре, называемым<em> указатель стека </em>. первоначально указатель стека указывает на вершину стека (самый высокий адрес в стеке).</li> <li>cpu имеет специальные инструкции для<em> помещать </em>значения в стек и<em> выталкивать </em>их обратно из стека. каждый<em> push </em>сохраняет значение в текущем местоположении указателя стека и уменьшает указатель стека. a<em> pop </em>извлекает значение, на которое указывает указатель стека, и затем увеличивает указатель стека (не смущайтесь тем фактом, что<em> добавление </em>значение в стек<em> уменьшается </em>указатель стека и<em> удаление </em>значение<em> увеличение </em>это. помните, что стек увеличивается до дна). сохраненные и извлеченные значения являются значениями регистров цп.</li> <li>когда функция вызывается, процессор использует специальные инструкции, которые передают текущий<em> указатель инструкции </em>, то есть адрес кода, выполняемого в стеке. затем cpu переходит к функции, устанавливая указатель инструкции на адрес вызываемой функции. позже, когда функция возвращается, старый указатель инструкции извлекается из стека, и выполнение возобновляется в коде сразу после вызова функции.</li> <li>когда функция вводится, указатель стека уменьшается, чтобы выделить больше места в стеке для локальных (автоматических) переменных. если функция имеет одну локальную 32-битную переменную, в стеке выделяются четыре байта. когда функция возвращается, указатель стека перемещается назад, чтобы освободить выделенную область.</li> <li>если функция имеет параметры, они помещаются в стек перед вызовом функции. затем код в функции может перемещаться вверх по стеку от текущего указателя стека, чтобы найти эти значения.</li> <li>вызов функции вложенности работает как шарм. каждый новый вызов будет выделять параметры функции, адрес возврата и пространство для локальных переменных, и эти<em> записи активации </em>могут быть сложены для вложенных вызовов и будут корректно разматываться при возврате функций.</li> <li>поскольку стек является ограниченным блоком памяти, вы можете вызвать<em> переполнение стека </em>, вызвав слишком много вложенных функций и/или выделив слишком много места для локальных переменных. часто область памяти, используемая для стека, настраивается таким образом, что запись ниже дна (самый низкий адрес) стека вызовет ловушку или исключение в цп. это исключительное условие может быть перехвачено средой выполнения и преобразовано в некое исключение переполнения стека.</li> </ul><p><img src="https://i.stack.imgur.com/9ushp.png" alt="the stack"></p><blockquote> <p>может ли функция быть размещена в куче вместо стека?</p> </blockquote><p>нет, записи активации для функций (то есть локальных или автоматических переменных) размещаются в стеке, который используется не только для хранения этих переменных, но и для отслеживания вызовов вложенных функций.</p><p>как управлять кучей, действительно зависит от среды выполнения. c использует <code>malloc</code> и c++ использует <code>new</code>, но многие другие языки имеют сборку мусора.</p><p>тем не менее, стек является более низкоуровневой функцией, тесно связанной с архитектурой процессора. растить кучу, когда не хватает места, не так уж сложно, так как это может быть реализовано в вызове библиотеки, которая обрабатывает кучу. однако увеличение стека часто невозможно, так как переполнение стека обнаруживается только тогда, когда это слишком поздно; и закрытие потока выполнения - единственно возможный вариант.</p>

<p>в следующем коде c #</p><pre class="lang-cs prettyprint-override"><code>public void method1() { int i = 4; int y = 2; class1 cls1 = new class1(); } </code></pre><p>вот как управляется память</p><p><img src="https://i.stack.imgur.com/ns0k7.jpg" alt="picture of variables on the stack"></p><p><code>local variables</code>, который должен длиться до тех пор, пока вызов функции идет в стеке. куча используется для переменных, время жизни которых мы на самом деле не знаем заранее, но мы ожидаем, что они продлятся некоторое время. в большинстве языков важно, чтобы мы знали во время компиляции, насколько велика переменная, если мы хотим сохранить ее в стеке. </p><p>объекты (которые меняются по размеру по мере их обновления) попадают в кучу, потому что мы не знаем во время создания, как долго они будут длиться. во многих языках куча мусора собирается для поиска объектов (таких как объект cls1), на которые больше нет ссылок. </p><p>в java большинство объектов попадают прямо в кучу. в таких языках, как c/c++, структуры и классы часто могут оставаться в стеке, когда вы не имеете дело с указателями.</p><p>более подробную информацию можно найти здесь:</p><p> <a href="http://timmurphy.org/2010/08/11/the-difference-between-stack-and-heap-memory-allocation/">разница между распределением стека и кучи памяти «timmurphy.org</a> </p><p>и здесь: </p><p> <a href="https://root.cern.ch/root/htmldoc/guides/users-guide/alittlec++.html#creating-objects-on-the-stack-and-heap">создание объектов в стеке и куче</a> </p><p>эта статья является источником изображения выше: <a href="http://www.codeproject.com/articles/76153/six-important-net-concepts-stack-heap-value-types#stack%20and%20heap">шесть важных концепций .net: стек, куча, типы значений, ссылочные типы, упаковка и распаковка - codeproject</a> </p><p>но имейте в виду, что это может содержать некоторые неточности. </p>

<p><strong> стек </strong> когда вы вызываете функцию, аргументы этой функции плюс некоторые другие накладные расходы помещаются в стек. там также хранится некоторая информация (например, куда возвращаться). когда вы объявляете переменную внутри вашей функции, эта переменная также размещается в стеке. </p><p>распределение стека довольно просто, потому что вы всегда освобождаете в обратном порядке, в котором вы размещаете. стек вещи добавляются при вводе функций, соответствующие данные удаляются при выходе из них. это означает, что вы склонны оставаться в небольшой области стека, если вы не вызываете много функций, которые вызывают множество других функций (или не создаете рекурсивное решение).</p><p><strong> куча </strong> куча - это общее имя для хранения данных, которые вы создаете на лету. если вы не знаете, сколько космических кораблей собирается создать ваша программа, вы, вероятно, будете использовать оператор new (или malloc или эквивалентный) для создания каждого космического корабля. это распределение останется на некоторое время, поэтому, скорее всего, мы освободим вещи в другом порядке, чем мы их создали. </p><p>таким образом, куча намного более сложна, потому что в конечном итоге возникают области памяти, которые не используются, чередуются с фрагментами, которые - фрагментация памяти. поиск свободной памяти нужного вам размера - сложная проблема. вот почему следует избегать кучи (хотя она все еще часто используется).</p><p><strong> реализация </strong> реализация как стека, так и кучи обычно зависит от времени выполнения/ос. часто игры и другие приложения, критически важные для производительности, создают свои собственные решения для памяти, которые захватывают большой кусок памяти из кучи и затем распределяют ее изнутри, чтобы не полагаться на ос для памяти. </p><p>это практично только в том случае, если использование вашей памяти сильно отличается от нормы - то есть для игр, в которых вы загружаете уровень за одну огромную операцию и можете отбросить все это за другую огромную операцию.</p><p><strong> физическое расположение в памяти </strong> это менее важно, чем вы думаете, из-за технологии под названием <a href="http://en.wikipedia.org/wiki/virtual\_memory">виртуальная память</a> , которая заставляет вашу программу думать, что у вас есть доступ к определенному адресу, где физические данные находится где-то еще (даже на жестком диске!). адреса, которые вы получаете для стека, растут по мере того, как дерево вызовов становится глубже. адреса для кучи непредсказуемы (т. е. специфичны для имплиментации) и, честно говоря, не важны.</p>

<p>чтобы уточнить, <a href="https://stackoverflow.com/a/13308092/1763801">этот ответ</a> имеет неверную информацию ( <a href="https://stackoverflow.com/a/662454/1763801">томас</a> исправил свой ответ после комментариев, круто :)). другие ответы просто не объясняют, что означает статическое распределение. итак, ниже я объясню три основных формы распределения и их связь с кучей, стеком и сегментом данных. я также покажу некоторые примеры на c/c++ и python, чтобы помочь людям понять.</p><p>«статические» (статически распределенные aka) переменные не размещаются в стеке. не думайте так - многие люди делают только потому, что «статический» очень похож на «стек». они на самом деле не существуют ни в стеке, ни в куче. являются частью того, что называется <a href="http://en.wikipedia.org/wiki/data\_segment">сегмент данных</a> .</p><p>тем не менее, как правило, лучше рассматривать «<strong> scope </strong>» и «<strong> времён жизни </strong>», а не «stack» и «heap».</p><p>область действия относится к тому, какие части кода могут обращаться к переменной. обычно мы думаем о<strong> локальной области видимости </strong>(доступ к которой может получить только текущая функция) по сравнению с<strong> глобальной области видимости </strong>(можно получить доступ где угодно), хотя область действия может стать намного более сложной.</p><p>время жизни относится к тому, когда переменная выделяется и освобождается во время выполнения программы. обычно мы думаем о<strong> статическом распределении </strong>(переменная будет сохраняться в течение всей продолжительности программы, что делает ее полезной для хранения одной и той же информации при нескольких вызовах функций) по сравнению с<strong> автоматическое распределение </strong>(переменная сохраняется только во время одного вызова функции, что делает ее полезной для хранения информации, которая используется только во время вашей функции и может быть отброшена, когда вы закончите) по сравнению с<strong> динамическое выделение </strong>(переменные, продолжительность которых определяется во время выполнения, вместо время компиляции как статическое или автоматическое).</p><p>хотя большинство компиляторов и интерпретаторов реализуют это поведение аналогично с точки зрения использования стеков, куч и т.д., компилятор может иногда нарушать эти соглашения, если он хочет, пока поведение корректно. например, из-за оптимизации локальная переменная может существовать только в регистре или может быть полностью удалена, даже если большинство локальных переменных существует в стеке. как было отмечено в нескольких комментариях, вы можете свободно реализовать компилятор, который даже не использует стек или кучу, а вместо этого использует некоторые другие механизмы хранения (редко делается, так как стеки и кучи отлично подходят для этого).</p><p>я приведу простой аннотированный c-код для иллюстрации всего этого. лучший способ научиться - это запускать программу под отладчиком и наблюдать за ее поведением. если вы предпочитаете читать python, перейдите к концу ответа :)</p><pre class="lang-cpp prettyprint-override"><code>// statically allocated in the data segment when the program/dll is first loaded // deallocated when the program/dll exits // scope - can be accessed from anywhere in the code int someglobalvariable; // statically allocated in the data segment when the program is first loaded // deallocated when the program/dll exits // scope - can be accessed from anywhere in this particular code file static int somestaticvariable; // "someargument" is allocated on the stack each time myfunction is called // "someargument" is deallocated when myfunction returns // scope - can be accessed only within myfunction() void myfunction(int someargument) { // statically allocated in the data segment when the program is first loaded // deallocated when the program/dll exits // scope - can be accessed only within myfunction() static int somelocalstaticvariable; // allocated on the stack each time myfunction is called // deallocated when myfunction returns // scope - can be accessed only within myfunction() int somelocalvariable; // a *pointer* is allocated on the stack each time myfunction is called // this pointer is deallocated when myfunction returns // scope - the pointer can be accessed only within myfunction() int* somedynamicvariable; // this line causes space for an integer to be allocated in the heap // when this line is executed. note this is not at the beginning of // the call to myfunction(), like the automatic variables // scope - only code within myfunction() can access this space // *through this particular variable*. // however, if you pass the address somewhere else, that code // can access it too somedynamicvariable = new int; // this line deallocates the space for the integer in the heap. // if we did not write it, the memory would be "leaked". // note a fundamental difference between the stack and heap // the heap must be managed. the stack is managed for us. delete somedynamicvariable; // in other cases, instead of deallocating this heap space you // might store the address somewhere more permanent to use later. // some languages even take care of deallocation for you... but // always it needs to be taken care of at runtime by some mechanism. // when the function returns, someargument, somelocalvariable // and the pointer somedynamicvariable are deallocated. // the space pointed to by somedynamicvariable was already // deallocated prior to returning. return; } // note that someglobalvariable, somestaticvariable and // somelocalstaticvariable continue to exist, and are not // deallocated until the program exits. </code></pre><p>особенно острым примером того, почему важно различать время жизни и область видимости, является то, что переменная может иметь локальную область видимости, но статическое время жизни - например, «somelocalstaticvariable» в приведенном выше примере кода. такие переменные могут сделать наши общие, но неформальные привычки именования очень запутанными. например, когда мы говорим «<em>local</em>», мы обычно имеем в виду «<em>локально распределенная переменная с автоматически назначаемой областью</em>», а когда мы говорим «global», мы обычно имеем в виду «<em>статически распределенная переменная с глобальной областью действия</em> ». к сожалению, когда дело доходит до таких вещей, как "<em>статически распределенные переменные в области файла</em>", многие просто говорят ... "<em>да ???</em>".</p><p>некоторые из вариантов синтаксиса в c/c++ усугубляют эту проблему - например, многие люди думают, что глобальные переменные не являются «статическими» из-за синтаксиса, показанного ниже.</p><pre class="lang-cpp prettyprint-override"><code>int var1; // has global scope and static allocation static int var2; // has file scope and static allocation int main() {return 0;} </code></pre><p>обратите внимание, что добавление ключевого слова «static» в объявлении выше предотвращает глобальную область видимости var2. тем не менее, глобальное var1 имеет статическое размещение. это не интуитивно понятно! по этой причине я стараюсь никогда не использовать слово «статический» при описании области действия, а вместо этого говорю что-то вроде «файл» или «ограниченный файл» область. однако многие люди используют фразу «статический» или «статический объем» для описания переменной, доступ к которой возможен только из одного файла кода. в контексте времени жизни «статический» <em>всегда</em> означает, что переменная выделяется при запуске программы и освобождается при выходе из программы.</p><p>некоторые люди считают эти понятия специфичными для c/c++. они не. например, приведенный ниже пример python иллюстрирует все три типа размещения (в интерпретируемых языках возможны некоторые тонкие различия, о которых я не буду здесь говорить).</p><pre class="lang-py prettyprint-override"><code>from datetime import datetime class animal: \_favoritefood = 'undefined' # \_favoritefood is statically allocated def petanimal(self): curtime = datetime.time(datetime.now()) # curtime is automatically allocatedion print("thank you for petting me. but it's " + str(curtime) + ", you should feed me. my favorite food is " + self.\_favoritefood) class cat(animal): \_favoritefood = 'tuna' # note since we override, cat class has its own statically allocated \_favoritefood variable, different from animal's class dog(animal): \_favoritefood = 'steak' # likewise, the dog class gets its own static variable. important to note - this one static variable is shared among all instances of dog, hence it is not dynamic! if \_\_== "\_\_main\_\_": whiskers = cat() # dynamically allocated fido = dog() # dynamically allocated rintintin = dog() # dynamically allocated whiskers.petanimal() fido.petanimal() rintintin.petanimal() dog.\_favoritefood = 'milkbones' whiskers.petanimal() fido.petanimal() rintintin.petanimal() # output is: # thank you for petting me. but it's 13:05:02.255000, you should feed me. my favorite food is tuna # thank you for petting me. but it's 13:05:02.255000, you should feed me. my favorite food is steak # thank you for petting me. but it's 13:05:02.255000, you should feed me. my favorite food is steak # thank you for petting me. but it's 13:05:02.255000, you should feed me. my favorite food is tuna # thank you for petting me. but it's 13:05:02.255000, you should feed me. my favorite food is milkbones # thank you for petting me. but it's 13:05:02.256000, you should feed me. my favorite food is milkbones </code></pre>

<p>другие довольно хорошо ответили на широкие удары, поэтому я добавлю несколько деталей.</p><ol> <li><p>стек и куча не обязательно должны быть единичными. распространенная ситуация, когда у вас есть более одного стека, если у вас есть более одного потока в процессе. в этом случае каждый поток имеет свой собственный стек. вы также можете иметь более одной кучи, например, некоторые dll конфигурации могут привести к тому, что разные библиотеки dll будут выделяться из разных куч, поэтому обычно плохая идея освобождать память, выделенную другой библиотекой.</p></li> <li><p>в c вы можете получить преимущество распределения переменной длины с помощью <a href="https://www.freebsd.org/cgi/man.cgi?alloca">alloca</a> , который выделяет в стеке, в отличие от alloc, который выделяет в куче. эта память не выдержит вашего оператора return, но она полезна для чистого буфера.</p></li> <li><p>создание огромного временного буфера в windows, который вы не используете, не является бесплатным. это связано с тем, что компилятор будет генерировать цикл проверки стека, который вызывается каждый раз при вводе вашей функции, чтобы убедиться, что стек существует (поскольку windows использует одну защитную страницу в конце стека, чтобы определить, когда ему нужно увеличить стек. если вы обращаетесь к памяти более чем на одну страницу с конца стека, вы потерпите крах). пример:</p></li> </ol><pre class="lang-cpp prettyprint-override"><code>void myfunction() { char big[10000000]; // do something that only uses for first 1k of big 99% of the time. } </code></pre>

<p>другие прямо ответили на ваш вопрос, но, пытаясь понять стек и кучу, я думаю, что полезно рассмотреть структуру памяти традиционного процесса unix (без потоков и распределителей на основе <code>mmap()</code>). <a href="http://www.memorymanagement.org/glossary/b.html#term-brk">глоссарий управления памятью</a> веб-страница содержит диаграмму этого макета памяти.</p><p>стек и куча традиционно расположены на противоположных концах виртуального адресного пространства процесса. при доступе к стеку размер автоматически увеличивается до размера, установленного ядром (который можно настроить с помощью <code>setrlimit(rlimit\_stack, ...)</code>). куча увеличивается, когда распределитель памяти вызывает системный вызов <code>brk()</code> или <code>sbrk()</code>, отображая дополнительные страницы физической памяти в виртуальное адресное пространство процесса. </p><p>в системах без виртуальной памяти, таких как некоторые встроенные системы, часто применяется одна и та же базовая схема, за исключением того, что размер стека и кучи фиксирован. однако в других встроенных системах (например, основанных на микроконтроллерах pic microchip) программный стек представляет собой отдельный блок памяти, который не может быть адресован инструкциями перемещения данных, и может быть изменен или прочитан только косвенно с помощью инструкций потока программы (вызов, возврат и т. д.). другие архитектуры, такие как процессоры intel itanium, имеют <a href="http://blogs.msdn.com/oldnewthing/archive/2005/04/21/410397.aspx">несколько стеков</a> . в этом смысле стек является элементом архитектуры цп.</p>

<p>стек - это часть памяти, которой можно манипулировать с помощью нескольких ключевых инструкций языка ассемблера, таких как «pop» (удаление и возврат значения из стека) и «push» (перемещение значения в стек), но также вызов ( вызвать подпрограмму - это толкает адрес для возврата в стек) и return (возврат из подпрограммы - это извлекает адрес из стека и переходит к нему). это область памяти ниже регистра указателя стека, который может быть установлен по мере необходимости. стек также используется для передачи аргументов подпрограммам, а также для сохранения значений в регистрах перед вызовом подпрограмм.</p><p>куча - это часть памяти, которая предоставляется приложению операционной системой, обычно через системный вызов типа malloc. в современных ос эта память представляет собой набор страниц, к которым имеет доступ только вызывающий процесс.</p><p>размер стека определяется во время выполнения и, как правило, не увеличивается после запуска программы. в программе на си стек должен быть достаточно большим, чтобы вместить каждую переменную, объявленную внутри каждой функции. куча будет динамически расти по мере необходимости, но ос в конечном итоге сделает вызов (она часто будет увеличивать кучу более чем на значение, запрошенное malloc, так что по крайней мере некоторым будущим malloc не придется возвращаться к ядру для получить больше памяти. такое поведение часто настраивается)</p><p>поскольку вы выделили стек перед запуском программы, вам никогда не понадобится malloc, прежде чем вы сможете использовать стек, так что это небольшое преимущество. на практике очень трудно предсказать, что будет быстрым, а что медленным, в современных операционных системах с подсистемами виртуальной памяти, потому что то, как страницы реализованы и где они хранятся, является деталью реализации. </p>

<p>я думаю, что многие другие люди дали вам в основном правильные ответы по этому вопросу.</p><p>одна деталь, которая была упущена, однако, состоит в том, что «куча» на самом деле должна, вероятно, называться «бесплатным магазином». причина этого различия заключается в том, что исходное бесплатное хранилище было реализовано со структурой данных, известной как «биномиальная куча». по этой причине выделение из ранних реализаций malloc ()/free () было выделением из кучи. однако в наши дни большинство бесплатных магазинов реализованы с очень сложными структурами данных, которые не являются биномиальными кучами.</p>

<p><strong>что такое стек?</strong></p><p>стек - это куча объектов, обычно аккуратно расположенных.</p><p> <a href="https://i.stack.imgur.com/gta97.jpg"> <img src="https://i.stack.imgur.com/gta97.jpg" alt="enter image description here"> </a> </p><blockquote> <blockquote> <p>стеки в вычислительных архитектурах - это области памяти, в которые данные добавляются или удаляются в порядке поступления. <br/> в многопоточном приложении каждый поток будет иметь свой собственный стек.</p> </blockquote> </blockquote><p><strong>что такое куча?</strong></p><p>куча - это неопрятная коллекция беспорядочно скопившихся вещей.</p><p> <a href="https://i.stack.imgur.com/rz43z.jpg"> <img src="https://i.stack.imgur.com/rz43z.jpg" alt="enter image description here"> </a> </p><blockquote> <blockquote> <p>в вычислительных архитектурах куча - это область динамически выделяемой памяти, которая автоматически управляется операционной системой или библиотекой диспетчера памяти. <br/> память в куче выделяется, освобождается и регулярно изменяется во время выполнения программы, что может привести к проблеме, называемой фрагментацией. <br/> фрагментация происходит, когда объекты памяти выделяются небольшими пробелами между ними, которые слишком малы для хранения дополнительных объектов памяти. <br/> чистый результат - это процент пространства кучи, который не может быть использован для дальнейшего выделения памяти.</p> </blockquote> </blockquote><p><strong>оба вместе</strong></p><blockquote> <blockquote> <p>в многопоточном приложении каждый поток будет иметь свой собственный стек. но все разные потоки будут разделять кучу. <br/> поскольку разные потоки совместно используют кучу в многопоточном приложении, это также означает, что должна быть некоторая координация между потоками, чтобы они не пытались получить доступ и манипулировать одним и тем же фрагментом (ами) память в куче одновременно.</p> </blockquote> </blockquote><p><strong>что быстрее - стек или куча? и почему?</strong></p><blockquote> <blockquote> <p>стек намного быстрее, чем куча. <br/> это из-за того, как память распределяется в стеке. <br/> выделение памяти в стеке так же просто, как перемещение указателя стека вверх.</p> </blockquote> </blockquote><p>для новичков в программировании, вероятно, будет хорошей идеей использовать стек, поскольку он проще. <br/> поскольку стек небольшой, вы можете использовать его, когда точно знаете, сколько памяти вам понадобится для ваших данных, или если вы знаете, что размер ваших данных очень мал. <br/> лучше использовать кучу, когда вы знаете, что вам понадобится много памяти для ваших данных, или вы просто не уверены, сколько памяти вам понадобится (например, с динамическим массивом).</p><h3>модель памяти java</h3><p> <a href="https://i.stack.imgur.com/yzk6t.png"> <img src="https://i.stack.imgur.com/yzk6t.png" alt="enter image description here"> </a> </p><p>стек - это область памяти, в которой хранятся локальные переменные (включая параметры метода). когда дело доходит до переменных объекта, это всего лишь ссылки (указатели) на реальные объекты в куче.<br> каждый раз, когда создается экземпляр объекта, часть памяти кучи откладывается для хранения данных (состояния) этого объекта. поскольку объекты могут содержать другие объекты, некоторые из этих данных могут фактически содержать ссылки на эти вложенные объекты.</p>

<p>вы можете сделать некоторые интересные вещи со стеком. например, у вас есть такие функции, как <a href="http://everything2.com/title/alloca%2528%2529">alloca</a> (при условии, что вы можете обойти обильные предупреждения относительно его использования), что является формой malloc, которая специально использует стек, а не кучу памяти.</p><p>тем не менее, ошибки памяти на основе стека являются одними из худших, которые я испытал. если вы используете кучную память и выходите за границы выделенного блока, у вас есть хороший шанс вызвать ошибку сегмента. (не 100%: ваш блок может быть случайно смежным с другим, который вы ранее разместили.) но так как переменные, созданные в стеке, всегда смежны друг с другом, выписывание границ может изменить значение другой переменной. я узнал, что всякий раз, когда я чувствую, что моя программа перестала подчиняться законам логики, это, вероятно, переполнение буфера.</p>

<p>просто в стеке создаются локальные переменные. кроме того, каждый раз, когда вы вызываете подпрограмму, счетчик программы (указатель на следующую машинную инструкцию) и любые важные регистры, а иногда и параметры помещаются в стек. затем любые локальные переменные внутри подпрограммы помещаются в стек (и используются оттуда). когда подпрограмма заканчивается, все эти вещи возвращаются из стека. пк и регистр данных получаются и возвращаются туда, где они были, как сейчас, чтобы ваша программа могла продолжать свой веселый путь.</p><p>куча - это область динамического выделения памяти (явные вызовы «new» или «allocate»). это специальная структура данных, которая может отслеживать блоки памяти разных размеров и их статус распределения.</p><p>в «классических» системах ram было расположено так, что указатель стека начинался с нижней части памяти, указатель кучи начинался сверху, и они росли друг к другу. если они перекрываются, у вас недостаточно оперативной памяти. это не работает с современными многопоточными ос, хотя. каждый поток должен иметь свой собственный стек, и они могут создаваться динамически.</p>

<p>из wikianwser.</p><h3>стек</h3><p>когда функция или метод вызывает другую функцию, которая, в свою очередь, вызывает другую функцию и т.д., выполнение всех этих функций приостанавливается до тех пор, пока самая последняя функция не вернет свое значение.</p><p>эта цепочка приостановленных вызовов функций является стеком, поскольку элементы в стеке (вызовы функций) зависят друг от друга.</p><p>стек важно учитывать при обработке исключений и выполнении потоков.</p><h3>отвал</h3><p>куча - это просто память, используемая программами для хранения переменных. элемент кучи (переменные) не имеет зависимостей друг от друга и всегда может быть доступен произвольно в любое время.</p>

<p><strong> стек </strong></p><ul> <li>очень быстрый доступ</li> <li>не нужно явно перераспределять переменные</li> <li>процессор эффективно управляет пространством, память не фрагментируется</li> <li>только локальные переменные</li> <li>ограничение на размер стека (в зависимости от ос)</li> <li>переменные не могут быть изменены</li> </ul><p><strong> куча </strong></p><ul> <li>переменные могут быть доступны по всему миру</li> <li>нет ограничений на объем памяти</li> <li>(относительно) медленный доступ</li> <li>не гарантируется эффективное использование пространства, память может фрагментироваться со временем, так как блоки памяти выделяются, а затем освобождаются</li> <li>вы должны управлять памятью (вы отвечаете за распределение и освобождение переменных)</li> <li>размер переменных можно изменить с помощью realloc ()</li> </ul>

<p><strong> ок, </strong>просто и в двух словах, они означают<strong> упорядочено </strong>и<strong> не упорядочено </strong>...!</p><p><strong> стек </strong>: в элементах стека вещи оказываются друг на друге, что означает, что обработка будет быстрее и эффективнее! ... </p><p>таким образом, всегда есть индекс, указывающий на конкретный элемент, также обработка будет быстрее, также есть связь между элементами! ...</p><p><strong> куча </strong>: нет порядка, обработка будет медленнее, а значения перепутаны без какого-либо определенного порядка или индекса ... есть случайные и нет никакой связи между ними ... поэтому время выполнения и использования может быть меняться ...</p><p>я также создаю изображение ниже, чтобы показать, как они могут выглядеть:</p><p> <a href="https://i.stack.imgur.com/9c2vh.png"> <img src="https://i.stack.imgur.com/9c2vh.png" alt="enter image description here"> </a> </p>

<h2>короче</h2><p>стек используется для статического выделения памяти и куча для динамического выделения памяти, которые хранятся в оперативной памяти компьютера.</p><hr><h2>в деталях</h2><p><strong>the stack</strong></p><p>стек представляет собой структуру данных «lifo» (последний пришел, первый вышел), которая управляется и оптимизируется центральным процессором довольно близко. каждый раз, когда функция объявляет новую переменную, она «помещается» в стек. затем каждый раз при выходе из функции все переменные, помещенные в стек этой функцией, освобождаются (то есть они удаляются). после освобождения переменной стека эта область памяти становится доступной для других переменных стека.</p><p>преимущество использования стека для хранения переменных заключается в том, что память управляется за вас. вам не нужно выделять память вручную или освобождать ее, если она вам больше не нужна. более того, поскольку процессор так эффективно организует стековую память, чтение и запись в переменные стека происходит очень быстро.</p><p>больше можно найти <strong> <a href="https://en.wikipedia.org/wiki/stack\_(abstract\_data\_type)">здесь</a> </strong>.</p><hr><p><strong>куча</strong></p><p>куча - это область памяти вашего компьютера, которая не управляется автоматически и не так жестко управляется процессором. это более свободно плавающая область памяти (и больше). чтобы выделить память в куче, вы должны использовать malloc () или calloc (), которые являются встроенными функциями c. после выделения памяти в куче вы несете ответственность за использование free () для освобождения этой памяти, когда она вам больше не нужна.</p><p>если вы этого не сделаете, ваша программа будет иметь то, что известно как утечка памяти. то есть память в куче все равно будет выделена (и не будет доступна другим процессам). как мы увидим в разделе отладки, есть инструмент под названием <a href="http://en.wikipedia.org/wiki/valgrind">valgrind</a> , который может помочь вам обнаружить утечки памяти.</p><p>в отличие от стека, куча не имеет ограничений по размеру переменного размера (кроме очевидных физических ограничений вашего компьютера). память кучи немного медленнее для чтения и записи, потому что для доступа к памяти в куче нужно использовать указатели. мы поговорим об указателях в ближайшее время.</p><p>в отличие от стека, переменные, созданные в куче, доступны любой функции в любой точке вашей программы. переменные кучи по сути являются глобальными.</p><p>больше можно найти <strong> <a href="https://en.wikipedia.org/wiki/memory\_management">здесь</a> </strong>.</p><hr><p>переменные, размещенные в стеке, сохраняются непосредственно в памяти, и доступ к этой памяти очень быстрый, и его распределение решается при компиляции программы. когда функция или метод вызывает другую функцию, которая, в свою очередь, вызывает другую функцию и т.д., выполнение всех этих функций приостанавливается до тех пор, пока самая последняя функция не вернет свое значение. стек всегда резервируется в порядке lifo, последний зарезервированный блок всегда является следующим блоком, который должен быть освобожден. это действительно упрощает отслеживание стека, освобождение блока из стека - всего лишь настройка одного указателя.</p><p>переменным, выделенным в куче, выделяется память во время выполнения, и доступ к этой памяти немного медленнее, но размер кучи ограничен только размером виртуальной памяти. элементы кучи не имеют зависимостей друг от друга и всегда могут быть доступны случайным образом в любое время. вы можете выделить блок в любое время и освободить его в любое время. это значительно усложняет отслеживание того, какие части кучи выделены или свободны в любой момент времени.</p><p> <a href="https://i.stack.imgur.com/kdbpf.png"> <img src="https://i.stack.imgur.com/kdbpf.png" alt="enter image description here"> </a> </p><p>вы можете использовать стек, если точно знаете, сколько данных вам нужно выделить до компиляции, и он не слишком велик. вы можете использовать кучу, если вы точно не знаете, сколько данных вам потребуется во время выполнения или если вам нужно выделить много данных.</p><p>в многопоточной ситуации каждый поток будет иметь свой собственный полностью независимый стек, но они будут совместно использовать кучу. стек зависит от потока, а куча зависит от приложения. стек важно учитывать при обработке исключений и выполнении потоков.</p><p>каждый поток получает стек, в то время как для приложения обычно есть только одна куча (хотя весьма часто иметь несколько куч для разных типов размещения).</p><p> <a href="https://i.stack.imgur.com/j0teh.gif"> <img src="https://i.stack.imgur.com/j0teh.gif" alt="enter image description here"> </a> </p><p>во время выполнения, если приложению требуется больше кучи, оно может выделить память из свободной памяти, а если стеку требуется память, оно может выделить память из свободной памяти, выделенной для приложения.</p><p>даже более подробно дается <a href="http://net-informations.com/faq/net/stack-heap.htm"><strong>здесь</strong></a> и <a href="http://gribblelab.org/cbootcamp/7\_memory\_stack\_vs\_heap.html"><strong>здесь</strong></a> .</p><hr><p>теперь приходите к <strong>ответы на ваш вопрос</strong>.</p><blockquote> <p><strong>в какой степени они контролируются ос или языковой средой выполнения?</strong></p> </blockquote><p>ос выделяет стек для каждого потока системного уровня при создании потока. обычно ос вызывается языковой средой выполнения для выделения кучи для приложения.</p><p>больше можно найти <strong> <a href="https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap/80113#80113">здесь</a> </strong>.</p><blockquote> <p><strong>какова их сфера применения?</strong></p> </blockquote><p>уже дано в топе.</p><blockquote> <p>«вы можете использовать стек, если точно знаете, сколько данных вам нужно выделить до компиляции, и он не слишком велик. вы можете использовать кучу, если точно не знаете, сколько данных вам потребуется во время выполнения или если вам нужно выделить много данных. "</p> </blockquote><p>больше можно найти в <a href="https://stackoverflow.com/questions/408670/stack-static-and-heap-in-c">здесь</a> .</p><blockquote> <p><strong>от чего зависит размер каждого из них?</strong></p> </blockquote><p>размер стека задается с помощью <a href="https://en.wikipedia.org/wiki/operating\_system">os</a> при создании потока. размер кучи устанавливается при запуске приложения, но может увеличиваться по мере необходимости в пространстве (распределитель запрашивает больше памяти у операционной системы).</p><blockquote> <p><strong>что делает быстрее?</strong></p> </blockquote><p>распределение стека происходит намного быстрее, поскольку все, что он на самом деле делает, - это перемещает указатель стека. используя пулы памяти, вы можете получить сопоставимую производительность за счет распределения кучи, но это связано с небольшой дополнительной сложностью и собственными головными болями.</p><p>кроме того, стек против кучи - это не только вопрос производительности; он также многое говорит об ожидаемом времени жизни объектов.</p><p>подробности можно найти в <strong> <a href="https://stackoverflow.com/questions/161053/which-is-faster-stack-allocation-or-heap-allocation">здесь</a> </strong>.</p>

<p>в 1980-х годах unix распространялся как кролики, а крупные компании катались на своих собственных. у exxon был такой же, как и у десятков торговых марок, утерянных в истории. то, как создавалась память, было на усмотрение многих реализаторы.</p><p>типичная программа на c была расположена в памяти с возможностью увеличить ее, изменив значение brk (). как правило, heap была чуть ниже этого значения brk и увеличивалась brk увеличил количество доступной кучи.</p><p>один stack, как правило, представлял собой область ниже heap, представляющую собой участок памяти , в котором не было ничего ценного до начала следующего фиксированного блока памяти. этот следующий блок часто представлял собой code, который можно было перезаписать по данным стека в одном из известных хаков своей эпохи.</p><p>одним типичным блоком памяти был bss (блок нулевых значений) , который случайно не был обнулен в предложении одного производителя. другой был data, содержащий инициализированные значения, включая строки и числа. третьим был code, содержащий crt (время выполнения c), main, функции и библиотеки.</p><p>появление виртуальной памяти в unix меняет многие ограничения. нет никакой объективной причины, по которой эти блоки должны быть смежными, или фиксированного размера, или заказывать определенным образом сейчас. конечно, до того, как unix был multics, который не страдал от этих ограничений. вот схема, показывающая один из макетов памяти той эпохи.</p><p><img src="https://i.stack.imgur.com/eeefv.png" alt="a typical 1980s style unix c program memory layout"></p>

<p><strong> стек </strong>,<strong> куча </strong>и<strong> данные </strong>каждого процесса в виртуальной памяти:</p><p> <a href="https://bayanbox.ir/view/581244719208138556/virtual-memory.jpg"> <img src="https://bayanbox.ir/view/581244719208138556/virtual-memory.jpg" alt="stack, heap and static data"> </a> </p>

<p>пара центов: я думаю, будет хорошо нарисовать память графически и проще:</p><p> <a href="https://i.stack.imgur.com/nlb7a.jpg"> <img src="https://i.stack.imgur.com/nlb7a.jpg" alt="this is my vision of process memory construction with simplification for more easy understanding wht happening"> </a> </p><p><br> стрелки - показывают, где растут стек и куча, размер стека процесса имеет ограничение, определенное в ос, ограничения размера стека потока по параметрам в api создания потока обычно. обычно размер кучи ограничивается максимальным размером виртуальной памяти процесса, например, для 32-разрядных 2-4 гб.</p><p>таким простым способом: куча процесса является общей для процесса и всех потоков внутри, используя для распределения памяти в общем случае что-то вроде<strong> malloc () </strong>.</p><p>стек - это быстрая память для хранения в общем случае указателей и переменных возврата функций, которые обрабатываются как параметры в вызове функции, локальные переменные функции.</p>

<p>так как некоторые ответы стали придирчивыми, я собираюсь внести свою лепту.</p><p>удивительно, но никто не упомянул, что несколько (то есть не связанных с количеством запущенных потоков на уровне ос) стеков вызовов можно найти не только в экзотических языках (postscript) или платформах (intel itanium), но и в <a href="http://en.wikipedia.org/wiki/fiber\_(computer\_science)"><em>волокна</em></a> , <a href="http://en.wikipedia.org/wiki/green\_threads"><em>зеленые нити</em></a> и некоторые реализации <a href="http://en.wikipedia.org/wiki/coroutine"><em>сопрограммы</em></a> .</p><p>волокна, зеленые нити и сопрограммы во многом похожи, что приводит к путанице. разница между волокнами и зелеными нитями заключается в том, что первые используют кооперативную многозадачность, в то время как последние могут иметь либо кооперативную, либо вытесняющую (или даже обе). различия между волокнами и сопрограммами см. в <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf">here</a> .</p><p>в любом случае, назначение обоих волокон, зеленых нитей и сопрограмм состоит в том, чтобы несколько функций выполнялись одновременно, но <strong>не</strong> параллельно (различие в <a href="https://stackoverflow.com/questions/1050222/concurrency-vs-parallelism-what-is-the-difference">this so вопросе</a> ) внутри единый поток на уровне ос, организованно передающий управление взад и вперед друг от друга.</p><p>при использовании волокон, зеленых нитей или сопрограмм у вас <em>обычно</em> есть отдельный стек для каждой функции. (технически, для каждой функции используется не просто стек, а целый контекст выполнения. самое главное, регистры цп.) для каждого потока существует столько стеков, сколько имеется одновременно выполняемых функций, и поток переключается между выполнением каждой функции. в соответствии с логикой вашей программы. когда функция запускается до конца, ее стек уничтожается. таким образом, <strong>количество и время жизни стеков</strong> являются динамическими и <strong>не определяются количеством потоков уровня ос!</strong></p><p>обратите внимание, что я сказал, что «<em>обычно</em> имеет отдельный стек для каждой функции». существуют обе реализации {<em>stackful</em> и <em>stackless</em> реализации процедур. наиболее заметными стековыми реализациями c++ являются <a href="http://www.boost.org/doc/libs/1\_53\_0/libs/coroutine/doc/html/index.html">boost.coroutine</a> и <a href="https://msdn.microsoft.com/en-us/library/dd492418.aspx">microsoft ppl</a> <code>async/await</code>. (тем не менее, функции <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4134.pdf">resumable c++</a> (a.k.a. "<code>async</code> и <code>await</code>"), которые были предложены для c++ 17, могут использовать сопрограммы без стеков.)</p><p>предложение fibers к стандартной библиотеке c++ ожидается. также есть сторонние <a href="https://stackoverflow.com/questions/1285714/lightweight-portable-c-fibers-mit-license">библиотеки</a> . зеленые темы чрезвычайно популярны в таких языках, как python и ruby.</p>

<p>мне есть чем поделиться, хотя основные моменты уже освещены.</p><p><strong> стек </strong> </p><ul> <li>очень быстрый доступ.</li> <li>хранится в оперативной памяти.</li> <li>здесь загружаются вызовы функций, а также передаются локальные переменные и параметры функций.</li> <li>пространство освобождается автоматически, когда программа выходит из области видимости.</li> <li>хранится в последовательной памяти.</li> </ul><p><strong> куча </strong></p><ul> <li>медленный доступ по сравнению со стеком.</li> <li>хранится в оперативной памяти.</li> <li>динамически созданные переменные хранятся здесь, что позже требует освобождения выделенной памяти после использования.</li> <li>хранится везде, где выполняется выделение памяти, доступ к нему осуществляется всегда по указателю.</li> </ul><p><strong> интересная заметка: </strong></p><ul> <li>если бы вызовы функций были сохранены в куче, это привело бы к двум беспорядочным точкам: <ol> <li>благодаря последовательному хранению в стеке выполнение выполняется быстрее. хранение в куче привело бы к огромным затратам времени и замедлению работы всей программы.</li> <li>если бы функции хранились в куче (грязное хранилище, на которое указывает указатель), не было бы никакого способа вернуться обратно к адресу вызывающей стороны (который стек дает из-за последовательного хранения в памяти).</li> </ol></li> </ul>

<p>многие ответы верны как концепции, но мы должны отметить, что аппаратному обеспечению необходим стек (то есть микропроцессор), чтобы разрешить вызов подпрограмм (call на языке ассемблера ..). (ооп ребята будут называть это<em> методы </em>)</p><p>в стеке вы сохраняете обратные адреса, а вызов → push/ret → pop управляется напрямую аппаратно.</p><p>вы можете использовать стек для передачи параметров ... даже если он медленнее, чем регистры (скажет гуру микропроцессора или хорошая книга по bios 1980-х годов ...)</p><ul> <li>без стека<strong> нет </strong>микропроцессор может работать. (мы не можем представить программу, даже на языке ассемблера, без подпрограмм/функций)</li> <li>без кучи это может. (программа на языке ассемблера может работать без, так как куча - это понятие ос, как malloc, то есть вызов os/lib.</li> </ul><p>использование стека происходит быстрее:</p><ul> <li>это аппаратное обеспечение, и даже push/pop очень эффективны.</li> <li>malloc требует входа в режим ядра, использования блокировки/семафора (или других примитивов синхронизации), выполнения некоторого кода и управления некоторыми структурами, необходимыми для отслеживания распределения.</li> </ul>

<p>вот это да! так много ответов, и я не думаю, что один из них понял это правильно ...</p><p>1) где и что они (физически в памяти реального компьютера)?</p><p>стек - это память, которая начинается с наивысшего адреса памяти, выделенного для образа вашей программы, и затем уменьшается в этом значении. он зарезервирован для параметров вызываемой функции и для всех временных переменных, используемых в функциях.</p><p>есть две кучи: государственная и частная.</p><p>частная куча начинается с 16-байтовой границы (для 64-битных программ) или 8-байтовой границы (для 32-битных программ) после последнего байта кода в вашей программе, а затем увеличивается в значении оттуда. это также называется кучей по умолчанию.</p><p>если частная куча становится слишком большой, она перекрывает область стека, как и стек, перекрывающий кучу, если она становится слишком большой. поскольку стек начинается с более высокого адреса и работает до более низкого адреса, при правильном взломе вы можете сделать стек настолько большим, что он будет переполнять область приватной кучи и перекрывать область кода. хитрость заключается в том, чтобы перекрыть достаточно области кода, которую вы можете подключить к коду. это немного сложно сделать, и вы рискуете сбой программы, но это легко и очень эффективно.</p><p>общедоступная куча находится в собственном пространстве памяти за пределами пространства образов вашей программы. именно эта память будет перекачана на жесткий диск, если ресурсы памяти станут недостаточными.</p><p>2) в какой степени они контролируются ос или языковой средой выполнения?</p><p>стек управляется программистом, частная куча управляется ос, а общедоступная куча никем не контролируется, потому что это служба ос - вы делаете запросы, и они либо удовлетворяются, либо отклоняются.</p><p>2б) какова их сфера применения?</p><p>все они являются глобальными для программы, но их содержимое может быть частным, общедоступным или глобальным.</p><p>2с) от чего зависит размер каждого из них?</p><p>размер стека и частная куча определяются параметрами времени выполнения вашего компилятора. общая куча инициализируется во время выполнения с помощью параметра размера.</p><p>2d) что делает быстрее?</p><p>они не предназначены для быстрой работы, они предназначены для того, чтобы быть полезными. то, как их использует программист, определяет, являются ли они «быстрыми» или «медленными»</p><p>ref:</p><p> <a href="https://norasandler.com/2019/02/18/write-a-compiler-10.html">https://norasandler.com/2019/02/18/write-a-compiler-10.html</a> </p><p> <a href="https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-getprocessheap">https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-getprocessheap</a> </p><p> <a href="https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-heapcreate">https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-heapcreate</a> </p>

<p>стратегии выделения памяти по языкам программирования </p><p>память в с - стек, горка и статический</p><p> <a href="https://i.stack.imgur.com/khsxk.jpg"> <img src="https://i.stack.imgur.com/khsxk.jpg" alt="enter image description here"> </a> <a href="https://i.stack.imgur.com/domsp.jpg"> <img src="https://i.stack.imgur.com/domsp.jpg" alt="memory in c – the stack, the heap, and static"> </a> </p><ol start="2"> <li>оп: в какой степени они контролируются ос или языковой средой исполнения?</li> </ol><p>я хочу добавить несколько слов об этом важном вопросе: </p><p>ос и общеязыковая среда выполнения </p><p>ключевые компоненты .net framework <a href="https://i.stack.imgur.com/rzbzb.jpg"> <img src="https://i.stack.imgur.com/rzbzb.jpg" alt="enter image description here"> </a> архитектура net framework 4.5 <a href="https://i.stack.imgur.com/ycoah.png"> <img src="https://i.stack.imgur.com/ycoah.png" alt="enter image description here"> </a> </p><p>компоненты clr <a href="https://i.stack.imgur.com/roong.gif"> <img src="https://i.stack.imgur.com/roong.gif" alt="components of clr"> </a> <a href="https://i.stack.imgur.com/2bxq7.jpg"> <img src="https://i.stack.imgur.com/2bxq7.jpg" alt="enter image description here"> </a> <a href="https://i.stack.imgur.com/dbayq.jpg"> <img src="https://i.stack.imgur.com/dbayq.jpg" alt="enter image description here"> </a> <a href="https://i.stack.imgur.com/618s7.jpg"> <img src="https://i.stack.imgur.com/618s7.jpg" alt="enter image description here"> </a> </p>