проектное решение jvm
Все объекты в Java неявно расширяют Object, поэтому я бы сказал, что это избыточно.
6 ответов
Думаю, одна из причин заключается в том, что Java должна делать все сама (еще один аспект независимости от платформы). Например, Swing рисует свои собственные компоненты с нуля, он не полагается на ОС для их рисования. Это все должно происходить в памяти. Многие вещи, которые могут делать окна, но Linux не (или делает иначе), должны быть полностью включены в Java, чтобы он работал одинаково на обоих.
Java также всегда настаивает на том, чтобы вся ее библиотека была «связанной» и доступной , Поскольку он не использует библиотеки DLL (они не будут доступны на каждой платформе), все должно быть загружено и отслежено с помощью java.
Java даже выполняет много собственных операций с плавающей запятой, поскольку FPU часто дают разные результаты, которые было признано неприемлемым.
Итак, если вы подумаете обо всем, что C # может делегировать ОС, к которой он привязан, по сравнению со всем, что Java должна делать для ОС, чтобы компенсировать другие, разницы следовало ожидать.
Я использовал java. приложения на 2 встроенных платформах сейчас. Один был анализатором спектра, на котором он действительно проводил трассировки, другой - приставками для кабельных телеприставок.
В обоих случаях этот минимальный объем памяти не был проблемой - были проблемы, специфичные для Java, которые просто не были не был одним. Количество созданных объектов и скорость рисования Swing были более серьезными проблемами в этих случаях.
другой - кабельные приставки.В обоих случаях этот минимальный объем памяти не был проблемой - были проблемы, специфические для Java, но их просто не было. Количество созданных объектов и скорость рисования Swing были более серьезными проблемами в этих случаях.
другой - кабельные приставки.В обоих случаях этот минимальный объем памяти не был проблемой - были проблемы, специфические для Java, но их просто не было. Количество созданных объектов и скорость рисования Swing были более серьезными проблемами в этих случаях.
JVM считает все свои общие библиотеки, используют ли они память или нет.
Диспетчер задач довольно ненадежен когда дело доходит до создания отчетов о потреблении памяти программ. Необходимо взять его в качестве руководства.
CLR считается как часть ОС, таким образом, диспетчер задач не сообщает, что это - потребление памяти при процессе приложения.
Похоже, java просто использует больше виртуальной памяти.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
amwise 20598 0.0 0.5 22052 5624 pts/3 Sl+ 14:59 0:00 mono Test.exe
amwise 20601 0.0 0.7 214312 7284 pts/2 Sl+ 15:00 0:00 java Program
Я сделал тестовую программу на C # и Java, которая печатает строку "test" и ждет ввода , Я считаю, что значение размера резидентного набора (RSS) более точно показывает использование памяти. Использование виртуальной памяти (VSZ) менее значимо.
Насколько я понимаю, приложения могут резервировать тонны виртуальной памяти, фактически не используя никакой реальной памяти. Например, вы можете попросить функцию VirtualAlloc в Windows зарезервировать или зафиксировать виртуальную память.
РЕДАКТИРОВАТЬ:
Вот красивая картинка из окна моего окна: alt text http://awise.us/images/mem.png
Каждое приложение представляло собой простой printf, за которым следовало getchar. Java и CLR много используют виртуальную память. Версия C практически ни от чего не зависит, поэтому использование памяти относительно невелико.
Я сомневаюсь, что это действительно имеет значение. Просто выберите ту платформу, с которой вы больше знакомы, и не пишите ужасный, бесполезный код. Я уверен, что это сработает.
РЕДАКТИРОВАТЬ:
Этот инструмент VMMap от Microsoft может быть полезен для определения того, куда уходит память.
JVM загружает множество ненужных основных классов при каждом запуске из rt.jar. К сожалению, внутренние перекрестные зависимости (java.lang <-> java.io) пакетов java затрудняют выполнение частичной инициализации во время выполнения. Не говоря уже о том, что сам rt.jar имеет размер более 40 МБ, требует много времени для поиска и распаковки.
Post Java 6u10, кажется, загружает вещи немного умнее (у него есть служба быстрого запуска jqs.exe = java для хранения необходимых данных в памяти и быстрее запускается), все же Java 7 считается лучше.
Обозреватель процессов в Windows правильно сообщает о байтах личного пользования (байты личного пользования - это те области памяти, которые не используются совместно какой-либо DLL).
Немного большее раздражение вызывает то, что спустя 10 лет JVM по-прежнему использует по умолчанию 64 МБ памяти.
Я не знаю, важен ли начальный объем памяти или размер приложения Hello World. Разница может быть связана с количеством и размерами библиотек, загружаемых JVM / CLR. Также может быть объем памяти, предварительно выделенный для пулов сборки мусора.
Каждое приложение, которое я знаю, использует гораздо больше, чем функциональность Hello World. Это будет загружать и освобождать память тысячи раз на протяжении всего выполнения приложения. Если вас интересуют различия в использовании памяти JVM и CLR, вот пара ссылок с полезной информацией
http://benpryor.com/blog/2006/05/04/jvm-vs-clr-memory-allocation /
Пример управления памятью (JVM и CLR)
Пример управления памятью находится в Power Point. Очень интересная презентация.