Зачем нужно указывать размер кучи Java?


Я всегда задавался вопросом, почему Java требует, чтобы вы устанавливали размер кучи вручную? У меня сложилось впечатление, что программы, написанные на других языках, будут выделять ровно столько памяти, сколько нужно для запуска программы, пока ОС не сможет выделить больше.

В мире Java нам нужно установить размер кучи, стека и permgen. Хотя это достаточно просто, забыв увеличить их до" достаточно больших " чисел - Причина № 1, по которой я видел, как серверы падают.

Почему бы и нет можно ли сказать Java, чтобы она со временем вырастила кучу/стек/permgen столько, сколько ей нужно?

4 17

4 ответа:

Моя интерпретация заключается в том, что Sun-это компания, ориентированная на продажу больших коробок, и им нравится, что сисадмины могут делать что-то на этих коробках. Запуск системы для заполнения всей памяти-это хороший способ запустить ее в землю и не иметь возможности эффективно выполнять действия по восстановлению работы, потому что вы не можете выделить память для создания оболочки входа, например.

Три причины:

  1. потому что Java был задуман как язык для написания веб-приложений. Как правило, не считается хорошей идеей позволить веб-приложению взять на себя все ресурсы компьютера.
  2. потому что Java-это собранный мусор. Помимо указания верхнего предела памяти, размер кучи также запускает сборку мусора. По сути, вы говорите: "вы можете использовать это много, но когда вы достигнете этого предела, вы должны привести себя в порядок".
  3. Существует множество классов приложений где вы хотите ограничить объем памяти, используемой процессом Java, например, где более важно, чтобы другие процессы продолжались, когда недостаточно памяти для обоих.
  4. потому что возможность ограничить размер кучи-это особенность. Если вам нравится подход, при котором процесс может иметь неограниченную память (как и в других упомянутых языках), то вы всегда можете установить предел кучи, чтобы он был больше, чем он может получить. Если вы хотите ограничить размер кучи, вы можете это сделать. Другой языки имеют только одно из этих возможных поведений, что делает их менее гибкими.

Я думаю, потому что фактическая память компьютера конечна. Таким образом, в некотором смысле, JVM позволяет обнаружить memleaks до того, как вся память будет потрачена впустую.
Кроме того, что делать, если вы запускаете несколько JVM на одной машине-в этом случае как вы позволяете каждому из этих JVM расти "столько, сколько ему нужно"?

Потому что динамическое увеличение размера кучи, стека и permgen приведет к тому, что сервер все равно будет работать. В таком мире сервер, в конечном счете, утечет все свои ресурсы.

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

Да, это предположения, но разумные; особенно когда вы рассмотрим происхождение Java / Oak от встроенного программирования приставок. Это не похоже на то, что встраиваемая система будет иметь виртуальную память подкачки или диска, поэтому зачем заставлять JVM действовать так, как если бы она была доступна?