Зачем вам нужно указывать размер кучи Java?
Я всегда задавался вопросом, почему Java требует, чтобы вы устанавливали размер кучи вручную? У меня сложилось впечатление, что программы, написанные на других языках, будут просто выделять столько памяти, сколько необходимо для выполнения программы, пока ОС не сможет выделить больше.
В мире Java нам нужно установить размер кучи, стека и размера permgen. , Хотя это достаточно просто, забывать увеличивать их до «достаточно больших» чисел - это причина № 1, по которой я видел, как серверы выходили из строя.
Почему невозможно заставить Java увеличивать кучу / стек / permgen настолько, насколько это возможно? нужно со временем?
4 ответа
Я считаю, что Sun - это компания, специализирующаяся на продаже больших ящиков, и им нравится, что системные администраторы могут что-то делать с этими ящиками. Запуск системы для заполнения всей памяти - хороший способ запустить ее в землю и не дать возможности эффективно предпринять действия по восстановлению работы, потому что вы не можете выделить память, например, для создания оболочки входа в систему.
Три причины:
- Потому что Java была задумана как язык для написания веб-приложений. Обычно не считается хорошей идеей позволять веб-приложению брать на себя все ресурсы компьютера.
- Потому что Java - это сборщик мусора. Размер кучи не только указывает верхний предел памяти, но и запускает сборку мусора. По сути, вы говорите: «Вы можете использовать столько, но когда вы достигнете этого предела, вам придется прибраться».
- Есть много классов приложений, в которых вы хотите ограничить объем памяти, используемый процессом Java, например где более важно, чтобы другие процессы продолжались, когда для обоих недостаточно памяти.
- Поскольку возможность ограничивать размер кучи является функцией . Если вам нравится подход, при котором процесс может иметь неограниченную память (как на других упомянутых языках), вы всегда можете установить предел кучи больше, чем он мог бы получить. Если вы хотите ограничить размер кучи, вы можете это сделать. У других языков есть только одно из этих возможных вариантов поведения, что делает их менее гибкими.
Я думаю, потому что фактическая память компьютера конечна. Таким образом, в некотором смысле JVM позволяет обнаруживать утечки памяти до того, как вся память будет потрачена впустую.
Кроме того, что делать, если вы запускаете несколько JVM на одной машине - в этом случае как вы позволяете каждой из этих JVM расти «настолько, насколько ей нужно»?
Потому что динамическое увеличение размера кучи, стека и пермгена просто приведет к остановке сервера. В таком мире сервер в конечном итоге потеряет все свои ресурсы.
Кроме того, разработка автоматического управления памятью не была такой зрелой, как сегодня. Наличие виртуальных ограничений упрощает задачу, если вы выбираете неправильные значения по умолчанию, но это может сделать кодирование немного менее эффективным на внутренней стороне.
Да, это предположения, но разумные; особенно если учесть происхождение Java / Oak программирования встроенных телевизионных приставок. Это не похоже на то, что встроенная система будет иметь виртуальную память подкачки или дисковую резервную копию, так зачем заставлять JVM действовать так, как если бы она была доступна?