1. Почему размер памяти стека фиксирован?

Question

2. Если есть только память стека, нет памяти кучи, какие проблемы будут созданы? Я думаю, что он будет делать программы очень быстро.
3. Я знаю, что объекты создаются в памяти кучи. , но если объекты создаются в стеке памяти, каковы будут проблемы? Почему мы создали память кучи?

Я читал.

Stack

very fast access 
don't have to explicitly de-allocate variables 
space is managed efficiently by CPU, memory will not become fragmented 
limit on stack size (OS-dependent) 

Heap

variables can be accessed globally 
no limit on memory size 
(relatively) slower access 
no guaranteed efficient use of space, memory may become fragmented over time as blocks of memory are allocated, then freed 
you must manage memory (you're in charge of allocating and freeing variables) 
variables can be resized using realloc() 

Answer 1

Я хотел бы начать с преимуществами кучек/недостатков стеков:

1. Выделение порядка независимого освобождения: Это самый важный ответ на ваш вопрос. Если бы была только память на основе стека, вы не могли бы немедленно освободить область памяти e, если она не находится непосредственно поверх стека. Однако с кучей вы можете освободить память независимо от порядка запросов на распределение. Как и в динамическом программном обеспечении, вы не можете ожидать порядка бесплатных запросов на протяжении всего жизненного цикла вашего программного обеспечения, поэтому вы не всегда хотите использовать стек памяти.

2. Определение общесистемного размера стека: Еще одна связанная с этим точка заключается в том, что если бы использовалась только используемая память стека, это означает, что все потоки в системе будут иметь фиксированную память. В этом случае было бы непросто определить идеальный размер стека потоков по умолчанию. Это вызовет чрезмерное потребление памяти. Поэтому это может привести к проблемам с памятью, даже если на самом деле недостаточно памяти. Что касается этого одного я предлагаю посмотреть на этот: http://linuxtips.manki.in/2011/11/tweaking-stack-size-of-linux-processes.html

Области, в которых стек, как куча распределители могут быть полезны: Игровые системы используют эту технику. Хорошим примером является загрузка и выгрузка активов (текстуры, шейдеры, 3d-сетки и т. Д.) во время загрузки уровня и разгрузки. Подобный стек как распределитель является естественным решением, так как порядок разгрузки активов будет обратным для их загрузки. Здесь вы можете увидеть реализацию: https://github.com/davidaug/stackallocator

Другие проблемы с кучами: Вы можете также рассмотреть их как больше плюсов для стека как дополнение к профи вы упомянули в вопросе:

а) многоядерные системы: Что касается распределителей стекол, то еще одно преимущество заключается в том, что было бы гораздо меньше конфликтов конфликтов, так как запросы на резервирование из разных ядер процессора являются важной проблемой для решения задачи распределения кучи. В дополнение к конфликту блокировки вам также приходится иметь дело с такими проблемами, как ложный обмен. Что касается этого, вы можете взглянуть на http://www.drdobbs.com/parallel/understanding-and-avoiding-memory-issues/212400410

б) Фрагментация: Самый первый пункт я упомянул (порядок распределения не зависит освобождение) является обязательным требованием. Однако это также приводит к проблеме фрагментации: What is memory fragmentation?