Язык программирования Java

Виртуальная Java-машина

Java Virtual Machine, сокращенно Java VM, JVM — виртуальная машина Java — основная часть исполняющей системы Java, так называемой Java Runtime Environment (JRE). Виртуальная машина Java интерпретирует и исполняет байт-код Java, предварительно созданный из исходного текста Java-программы компилятором Java.

Достоинство подобного способа  выполнения программ — в полной независимости байт-кода от ОС и  оборудования, что позволяет выполнять  Java приложения на любом устройстве, которое поддерживает виртуальную машину. Другой важной особенностью технологии Java является весьма гибкая система безопасности, благодаря тому, что исполнение программы полностью контролируется виртуальной машиной. Любые операции, которые превышают установленные полномочия программы (например попытка несанкционированного доступа к данным или соединения с другим компьютером) вызывают немедленное прерывание. Это позволяет пользователям легко загружать программы, написанные на Java на их компьютеры (или другие устройства, например мобильные телефоны) из неизвестных источников, при этом, не опасаясь заражения вирусами, пропажи ценной информации, и т. п.

Часто к недостаткам этого  подхода относят то, что исполнение байт-кода виртуальной машиной может  снижать производительность программ и алгоритмов, реализованных на языке Java. Данное утверждение справедливо для первых версий виртуальной машины Java, однако в последнее время оно практически потеряло актуальность. Этому способствовал ряд усовершенствований: применение технологий JITs (Just-In-Time compilers) позволяющая переводить байт-код в машинный код во время исполнения программы с возможностью сохранения версий класса в машинном коде, широкое использование native-кода в стандартных библиотеках, а также аппаратные средства, обеспечивающие ускоренную обработку байт-кода.

В начале развития платформы  Java существовали две конкурирующие реализации Java VM — одна от фирмы Sun Microsystems, создателя языка Java, для различных платформ (Windows, Mac OS, Unix), и другая — от фирмы Microsoft, ориентированная только на платформу Windows и, по утверждениям Microsoft, «специально оптимизированная для быстрого выполнения Java-кода на платформе Microsoft Windows».

Однако Microsoft JVM была не полностью совместима со стандартом Java, введенным Sun, а также имела существенные проблемы с производительностью при работе под большими нагрузками (при большом числе одновременно выполняемых потоков) и с безопасностью. Фирма Sun посчитала такую ситуацию недопустимой и решила, что Microsoft занимается намеренной дискредитацией и профанацией платформы Java, распространяя свою версию виртуальной машины Java. На этом основании Sun неоднократно подавала в суд на Microsoft, и последовательно добилась сначала того, что Microsoft потеряла право называть свою реализацию JVM Java VM. С этого момента Microsoft стала называть свой продукт просто Microsoft VM. Затем Microsoft потеряла право встраивать свою VM в браузеры и операционные системы. После этого Microsoft вынуждена была изъять свою VM из поставки Windows и из пакета IE, но могла, согласно решению суда, предлагать ее отдельно для скачивания на сайте. Затем Sun добилась прекращения разработки новых версий Microsoft VM и прекращения выпуска обновлений к ней, а затем и снятия Microsoft VM из списка доступных для скачивания программ на сайте Microsoft. С этого момента Sun стала фактическим монополистом в области Java, предлагая единственную реализацию Java VM.

Сравнение C++ и Java

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

1. Продуктивность программирования

Продуктивность  программирования определяет, насколько  эффективно (т.е. быстро и точно) программист  с определенным опытом и знаниями может решить поставленную перед  ним задачу, используя заданный язык программирования. Так как оклад разработчика является главной составляющей стоимости разработки любого программного проекта, продуктивность программирования имеет большое значение. Также в определенной степени продуктивность программирования определяется доступными инструментальными средствами.

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

Для этого Java наделена некоторыми дополнительными возможностями. Например, в отличие от C++ (или C), программист не должен в явном виде "освобождать" (возвращать) выделенную память операционной системе. Освобождение неиспользуемой памяти (сборка "мусора") автоматически обеспечивается средой выполнения Java в ущерб производительности и эффективности использования памяти (см. далее). Это освобождает программиста от утомительной задачи по слежению за освобождением памяти - главного источника ошибок в приложениях. Одна эта возможность языка должна значительно увеличить продуктивность программирования в сравнении с C++ (или C).

На практике же сборка "мусора" и другие возможности Java не оказывают большого влияния  на продуктивность программирования.

2. Производительность работы приложений

И снова Prechelt предоставляет  интересные сведения. Объем предлагаемой им информации огромен, но в конечном итоге он приходит к заключению, что "Java-программы выполняются, по крайней мере, в 1.22 раза медленнее C/C++ программ". На задачах, ориентированных на интенсивное использование процессора, Java-программы проигрывают еще сильнее.

В случае программ с пользовательским графическим интерфейсом увеличение времени отклика интерфейса является более критичным, чем низкая производительность программы. Проведенные исследования показывают, что пользователи более терпимы к задачам, выполняющимся в течение двух или трех минут, чем к программам, которые не реагируют мгновенно на их воздействия, например, на нажатия кнопок. Эти исследования показывают, что если время отклика программы больше, чем 0,7 секунды, пользователи считают ее медленной. Объяснение того, почему Java-программы медленнее C++ программ, заключается в следующем. C++ программы компилируются компилятором C++ в двоичный формат, который затем исполняется непосредственно процессором; таким образом, выполнение программы осуществляется аппаратными средствами. (Это несколько упрощенно, так как большинство современных процессоров выполняют микрокод, но это не принципиально при обсуждении данного вопроса.) С другой стороны, компилятор Java компилирует исходный код в "байт-код", который непосредственно исполняется не процессором, а с помощью другого программного обеспечения, виртуальной машины Java (JavaVirtualMachine, JVM). В свою очередь, JVM исполняется процессором. Таким образом, выполнение байт-кода Java-программ осуществляется не быстрыми аппаратными средствами, а с помощью более медленной программной эмуляции.

Для повышения производительности работы Java-программ были разработаны "JustinTime" (JIT) компиляторы, но универсального решения этой проблемы не существует.

На первый взгляд, полуинтерпретируемая природа Java-программ обеспечивает выполнение принципа "скомпилированный однажды  код выполняется везде". Однажды  скомпилированная в байт-код Java-программа может выполняться на любой платформе, для которой доступна JVM. На практике же, это не всегда так из-за отличий в реализациях разных JVM и из-за необходимости иногда наряду с Java-программами использовать родной, не-Java код, обычно написанный на C или C++.

Но разве использование  платформенно-независимого байт-кода является верным подходом в создании кросс-платформенных приложений? С  хорошим кросс-платформенным инструментарием, наподобие Qt, и хорошими компиляторами  для различных платформ программисты могут достичь почти той же цели компиляцией своего исходного кода один раз для каждой из платформ: "написанный однажды код компилируется везде". Можно возразить, что для этого разработчикам потребуется доступ ко всем поддерживаемым платформам, в то время, как с Java, теоретически, разработчикам необходим доступ только к одной из платформ, имеющей средства разработки для Java и JVM. На практике же ни один из ответственных производителей программного обеспечения не будет сертифицировать свои программные продукты для платформ без предварительного их тестирования, поэтому в любом случае производителям будет необходим доступ ко всем поддерживаемым платформам.

Возникает вопрос, зачем использовать программную  реализацию виртуальной машины Java, если такую же функциональность можно  получить с помощью аппаратной реализации? Именно так рассуждали разработчики при создании языка Java; они предполагали, что вопрос низкой производительности будет решен, когда станет доступной аппаратная реализация JVM в виде Java-процессоров. Однако даже по прошествии пяти лет Java-процессоры не получили широкого распространения. Существуют проектные экземпляры и даже работающие прототипы Java-процессоров, однако понадобится еще немало времени, чтобы стало возможным их приобрести.

3. Эффективность  использования памяти

Java и C++ используют  различные подходы в управлении  памятью. В C++ управление памятью  полностью осуществляется программистом, т.е. по мере необходимости распределение и освобождение памяти должно выполняться программистом. Если программист забывает освободить ранее полученную память, возникает "утечка памяти". Если во время работы приложения произойдет лишь одна такая утечка, проблем не возникнет, так как после завершения работы приложения операционная система освободит всю ранее использованную им память. Но если утечки памяти будут происходить постоянно (например, если пользователь будет периодически выполнять определенные действия), использование памяти приложением будет расти вплоть до полного ее расхода с последующим возможным отказом системы.

Java обеспечивает  автоматическое освобождение неиспользуемой  памяти. Наряду с распределением  памяти программистом JVM ведет  учет всех используемых блоков памяти и указателей на них. Если блок памяти больше не используется, он может быть освобожден. Это обеспечивает процесс, который называется "сборкой мусора". Он периодически вызывается JVM, проверяет все используемые блоки памяти и освобождает те из них, на которые отсутствуют указатели.

Сборка мусора очень удобна, но за ее использование  приходится расплачиваться большим  потреблением памяти и низкой производительностью. Программисты C++ могут (и должны) освобождать блоки памяти сразу после того, как они перестали быть нужны. С Java блоки не освобождаются до очередного вызова сборщика мусора, периодичность работы которого зависит от используемой реализации JVM. Prechtelt предоставляет цифровые данные, утверждая, что в среднем, (...) и с вероятностью 80% Java-программы используют на 32 MB (или 297%) памяти больше, чем C/C++ программы (...). Вдобавок к большому расходу памяти процесс сборки мусора требует дополнительной процессорной мощности, которая в результате становится недоступной приложению, и это приводит к замедлению его работы. Поэтому периодическая работа сборщика мусора может приводить к "замораживанию" Java-программы на несколько секунд. Лучшие реализации JVM минимизируют такие замораживания, но не устраняют их полностью.

При работе с  внешними программами и устройствами, например, во время ввода/вывода или  при взаимодействии с базой данных, желательно закрыть файл или соединение с базой данных сразу же после  того, как они перестали быть нужны. Благодаря деструкторам C++ это происходит сразу после вызова delete. В Java закрытие произойдет лишь во время следующего цикла работы сборщика мусора. В лучшем случае это может привести к излишней блокировке ресурсов, в худшем - к нарушению целостности открытых ресурсов.

Тот факт, что Java-программы используют блоки памяти большие, чем необходимо, является особенно критичным для встраиваемых устройств, объемы памяти которых невелики.

Главная причина, по которой сборка мусора является более дорогостоящей, чем непосредственное управление памятью программистом, - это утрата информации. В C++ программе программист знает и местонахождение своих блоков памяти (сохраняя указатели на них), и когда они перестанут быть ему нужными. В Java-программе последняя информация недоступна для JVM (даже если она известна программисту), поэтому JVM должна перебирать все блоки на предмет отсутствующих указателей. Для того, чтобы вызвать сборку мусора вручную, Java-программист может удалить все указатели на больше ненужные ему блоки памяти. Но со стороны программиста это потребует больше усилий, чем непосредственное управление памятью в C++; и тем не менее, во время сборки мусора JVM все равно придется проверить все блоки памяти, чтобы освободить неиспользуемые.

С технической  точки зрения, нет ничего такого, что бы мешало реализовать сборку мусора в C++ программах. Существуют обеспечивающие это коммерческие программы и библиотеки. Но из-за перечисленных выше недостатков немногие C++ программисты используют их. Инструментарий Qt использует более эффективный подход для упрощения задачи управления памятью: при удалении объекта все зависящие от него объекты также автоматически удаляются. Подход Qt не мешает программистам по желанию самостоятельно удалять объекты.

В результате этого  обсуждения мы убедились в том, что при сравнимой продуктивности программирования C++ обеспечивает приложениям гораздо лучшие, чем Java, производительность работы и эффективность использования памяти.

4. Доступные  библиотеки и инструментарий

Java-платформа  предлагает внушительное число  пакетов, насчитывающих сотни классов для любых задач, включая пользовательский графический интерфейс, безопасность, поддержку сети и прочие. Это несомненное преимущество Java-платформы. Любому Java-пакету соответствует, как минимум, одна C++ библиотека, хотя иногда бывает очень трудно собрать в одном C++ проекте множество библиотек и заставить их вместе правильно работать.