Runtime в java это
У каждого приложения Java есть единственный экземпляр класса Runtime это позволяет приложению взаимодействовать через интерфейс со средой, в которой работает приложение. Текущее время выполнения может быть получено из getRuntime метод.
Приложение не может создать свой собственный экземпляр этого класса.
Сводка метода
Модификатор и Тип | Метод и Описание |
---|---|
void | addShutdownHook(Thread hook) |
Завершает в настоящий момент рабочую виртуальную машину Java, инициируя ее последовательность завершения работы.
С JDK 1.1, привилегированный способ преобразовать поток байтов в локальном кодировании в символьный поток в Unicode через InputStreamReader и BufferedReader классы.
С JDK 1.1, привилегированный способ преобразовать поток символа Unicode в поток байтов в локальном кодировании через OutputStreamWriter , BufferedWriter , и PrintWriter классы.
Этот метод по сути опасен. Это может привести к финализаторам, вызываемым на живых объектах, в то время как другие потоки одновременно управляют теми объектами, приводя к ошибочному поведению или мертвой блокировке.
Методы java.lang унаследованный от класса. Объект
Деталь метода
getRuntime
Возвращает объект периода выполнения, связанный с текущим приложением Java. Большинство методов класса Runtime методы экземпляра и должны быть вызваны относительно текущего объекта периода выполнения.
выход
Завершает в настоящий момент рабочую виртуальную машину Java, инициируя ее последовательность завершения работы. Этот метод никогда обычно не возвращается. Параметр служит кодом состояния; условно, ненулевой код состояния указывает на аварийное завершение.
Если этот метод вызывается после того, как виртуальная машина начала свою последовательность завершения работы тогда, если рычаги завершения работы будут выполнены, то этот метод блокирует неопределенно. Если рычаги завершения работы были уже выполнены, и завершение на выходе было включено тогда, этот метод останавливает виртуальную машину с данным кодом состояния, если состояние является ненулевым; иначе, это блокирует неопределенно.
System.exit метод является стандартными и удобными средствами вызова этого метода.
addShutdownHook
Виртуальная машина Java завершает работу в ответ на два вида событий:
Как только последовательность завершения работы началась, она может быть остановлена только, вызывая halt метод, который насильственно завершает виртуальную машину.
Рычаги завершения работы, выполненные в тонкое время в жизненном цикле виртуальной машины и, должны поэтому быть кодированы защитно. Они должны, в частности быть записаны, чтобы быть ориентированными на многопотоковое исполнение и избежать мертвых блокировок поскольку возможный. Они не должны также положиться вслепую на службы, которые, возможно, зарегистрировали их собственные рычаги завершения работы, и поэтому может самостоятельно в процессе завершения работы. Попытки использовать другие основанные на потоке службы, такие как событие AWT - диспетчеризируют поток, например, может привести к мертвым блокировкам.
Рычаги завершения работы должны также закончить свою работу быстро. Когда программа вызывает exit ожидание состоит в том, что виртуальная машина быстро завершит работу и выйдет. Когда виртуальная машина завершается из-за пользовательского выхода из системы или завершения работы системы, базовая операционная система может только позволить установленную сумму времени, в которое можно завершить работу и выйти. Это поэтому нецелесообразно, чтобы делать попытку любого взаимодействия с пользователем или выполнить продолжительное вычисление в рычаге завершения работы.
Непойманные исключения обрабатываются в рычагах завершения работы так же, как в любом другом потоке, вызывая uncaughtException метод потока ThreadGroup объект. Реализация по умолчанию этого метода печатает трассировку стека исключения к System.err и завершает поток; это не заставляет виртуальную машину выходить или останавливаться.
При редких обстоятельствах виртуальная машина может прерваться, то есть, прекратите работать, не завершая работу чисто. Это происходит, когда виртуальная машина завершается внешне, например с сигналом SIGKILL на Unix или запросе TerminateProcess к Microsoft Windows. Виртуальная машина может также прерваться, если собственный метод спутывается, например, повреждая внутренние структуры данных или пытаясь получить доступ к несуществующей памяти. Если виртуальная машина прерывается тогда, никакая гарантия не может быть сделана о том, будут ли какие-либо рычаги завершения работы выполнены.
removeShutdownHook
останов
Насильственно завершает в настоящий момент рабочую виртуальную машину Java. Этот метод никогда обычно не возвращается.
Этот метод должен использоваться с экстремальным предостережением. В отличие от этого exit метод, этот метод не заставляет рычаги завершения работы быть запущенными и не выполняет невызванные финализаторы, если завершение на выходе было включено. Если последовательность завершения работы уже инициировалась тогда, этот метод не ожидает никаких рабочих рычагов завершения работы или финализаторов, чтобы закончить их работу.
runFinalizersOnExit
Осуждаемый. Этот метод по сути опасен. Это может привести к финализаторам, вызываемым на живых объектах, в то время как другие потоки одновременно управляют теми объектами, приводя к ошибочному поведению или мертвой блокировке.
Включение или завершение отключения на выходе; выполнение так определяет, что финализаторы всех объектов, у которых есть финализаторы, которые еще не были автоматически вызваны, должны быть выполнены перед выходами Среды выполнения Java. По умолчанию завершение на выходе отключается.
Если есть менеджер безопасности, checkExit метод сначала вызывают с 0 как его параметр, чтобы гарантировать, что выход позволяется. Это могло привести к SecurityException.
Это - метод удобства. Вызов формы exec(command) ведет себя точно таким же образом как вызов exec (command, null, null).
Это - метод удобства. Вызов формы exec(command, envp) ведет себя точно таким же образом как вызов exec (command, envp, null).
Это - метод удобства. Вызов формы exec(command, envp, dir) ведет себя точно таким же образом как вызов exec (cmdarray, envp, dir), где cmdarray массив всех маркеров в command .
Более точно, command строка повреждается в маркеры, используя a StringTokenizer создаваемый вызовом new StringTokenizer (command) без дальнейшей модификации символьных категорий. Маркеры, произведенные токенизатором, тогда помещаются в новый строковый массив cmdarray , в том же самом порядке.
Это - метод удобства. Вызов формы exec(cmdarray) ведет себя точно таким же образом как вызов exec (cmdarray, null, null).
Это - метод удобства. Вызов формы exec(cmdarray, envp) ведет себя точно таким же образом как вызов exec (cmdarray, envp, null).
Учитывая массив строк cmdarray , представление маркеров командной строки, и массива строк envp , представляя настройки переменной "среды", этот метод создает новый процесс, в котором можно выполнить указанную команду.
Этот метод проверяет это cmdarray допустимая команда операционной системы. То, какие команды допустимы, системно-зависимо, но по крайней мере команда должна быть непустым списком непустых строк.
Если envp является null, подпроцесс наследовал настройки среды текущего процесса.
Минимальный набор системно-зависимых переменных окружения может быть обязан запускать процесс на некоторых операционных системах. В результате подпроцесс может наследовать дополнительные настройки переменной окружения вне тех в указанной среде.
ProcessBuilder.start() теперь привилегированный способ запустить процесс с измененной среды.
Рабочий каталог нового подпроцесса определяется dir. Если dir является null, подпроцесс наследовал текущий рабочий каталог текущего процесса.
Если менеджер безопасности существует, checkExec метод вызывается с первым компонентом массива cmdarray как его параметр. Это может привести к a SecurityException быть брошенным.
- Программный файл операционной системы не был найден.
- Доступ к программному файлу был лишен.
- Рабочий каталог не существует.
В таких случаях будет выдано исключение. Точный характер исключения системно-зависим, но это всегда будет подкласс IOException .
availableProcessors
Это значение может измениться во время определенного вызова виртуальной машины. Приложения, которые чувствительны к числу доступных процессоров, должны поэтому иногда опрашивать это свойство и корректировать их использование ресурсов соответственно.
freeMemory
Возвращает количество свободной памяти в виртуальной машине Java. Вызов gc метод может привести к увеличению значения, возвращенного freeMemory.
totalMemory
Возвращает общую сумму памяти в виртуальной машине Java. Значение, возвращенное этим методом, может измениться в течение долгого времени, в зависимости от среды узла.
Отметьте, что объем памяти, требуемый содержать объект любого данного типа, может быть зависящим от реализации.
maxMemory
Возвращает максимальный объем памяти, который виртуальная машина Java попытается использовать. Если нет никакого свойственного предела тогда значения Long.MAX_VALUE будет возвращен.
Выполняет сборщик "мусора". Вызов этого метода предлагает, чтобы виртуальная машина Java израсходовала усилие к рециркуляции неиспользованных объектов, чтобы сделать память, которую они в настоящий момент занимают доступный для быстрого повторного использования. Когда возвраты управления из вызова метода, виртуальная машина сделала свои максимальные усилия, чтобы переработать все отброшенные объекты.
Имя gc стенды для "сборщика"мусора"". Виртуальная машина выполняет этот процесс рециркуляции автоматически как необходимый, в отдельном потоке, даже если gc метод не вызывается явно.
Метод System.gc() стандартные и удобные средства вызова этого метода.
runFinalization
Выполняет методы завершения любых объектов завершение на ожидании. Вызов этого метода предлагает, чтобы виртуальная машина Java израсходовала усилие к выполнению finalize методы объектов, которые, как находили, были отброшены, но чей finalize методы еще не были выполнены. Когда возвраты управления из вызова метода, виртуальная машина сделала максимальные усилия, чтобы завершить все выдающиеся завершения.
Виртуальная машина выполняет процесс завершения автоматически как необходимый, в отдельном потоке, если runFinalization метод не вызывается явно.
traceInstructions
Трассировка включений/Отключений инструкций. Если boolean параметр true , этот метод предлагает, чтобы виртуальная машина Java испустила отладочную информацию для каждой инструкции в виртуальной машине, поскольку это выполняется. Формат этой информации, и файл или другой поток вывода, к которому это испускается, зависит от среды узла. Виртуальная машина может проигнорировать этот запрос, если это не поддерживает эту функцию. Место назначения вывода трассировки системно-зависимо.
Если boolean параметр false , этот метод заставляет виртуальную машину прекращать выполнять подробную трассировку инструкции, которую это выполняет.
traceMethodCalls
Трассировка включений/Отключений вызовов метода. Если boolean параметр true , этот метод предлагает, чтобы виртуальная машина Java испустила отладочную информацию для каждого метода в виртуальной машине, как это вызывают. Формат этой информации, и файл или другой поток вывода, к которому это испускается, зависит от среды узла. Виртуальная машина может проигнорировать этот запрос, если это не поддерживает эту функцию.
Вызов этого метода с ложью параметра предлагает, чтобы виртуальная машина прекратила испускать отладочную информацию на вызов.
загрузка
Загружает указанное имя файла как динамическую библиотеку. Параметром имени файла должно быть имя полного пути, (например Runtime.getRuntime().load("/home/avh/lib/libX11.so"); ).
Во-первых, если есть менеджер безопасности, checkLink метод вызывают с filename как его параметр. Это может привести к исключению безопасности.
Это подобно методу loadLibrary(String) , но это принимает общее имя файла как параметр, а не только имя библиотеки, позволяя любой файл собственного кода быть загруженным.
Метод System.load(String) стандартные и удобные средства вызова этого метода.
loadLibrary
Загружает динамическую библиотеку указанным именем библиотеки. Файл, содержащий собственный код, загружается из локальной файловой системы от места, где файлы библиотеки традиционно получаются. Детали этого процесса являются зависящими от реализации. Отображение от имени библиотеки до определенного имени файла делается специфичным для системы способом.
Во-первых, если есть менеджер безопасности, checkLink метод вызывают с libname как его параметр. Это может привести к исключению безопасности.
Метод System.loadLibrary(String) стандартные и удобные средства вызова этого метода. Если собственные методы должны использоваться в реализации класса, стандартная стратегия состоит в том, чтобы поместить собственный код в файл библиотеки (вызовите это LibFile ) и затем помещать статический инициализатор:
в пределах объявления класса. Когда класс будет загружен и инициализируется, необходимая собственная реализация кода для собственных методов будет тогда загружена также.
Если этот метод вызывают не раз с тем же самым именем библиотеки, вторые и последующие вызовы игнорируются.
getLocalizedInputStream
Осуждаемый. С JDK 1.1, привилегированный способ преобразовать поток байтов в локальном кодировании в символьный поток в Unicode через InputStreamReader и BufferedReader классы.
Создает локализованную версию входного потока. Этот метод берет InputStream и возвраты InputStream эквивалентный параметру во всех отношениях за исключением того, что это локализуется: поскольку символы в локальном наборе символов читаются из потока, они автоматически преобразовываются от локального набора символов до Unicode.
Если параметром уже является локализованный поток, он может быть возвращен как результат.
getLocalizedOutputStream
Осуждаемый. С JDK 1.1, привилегированный способ преобразовать поток символа Unicode в поток байтов в локальном кодировании через OutputStreamWriter , BufferedWriter , и PrintWriter классы.
Создает локализованную версию потока вывода. Этот метод берет OutputStream и возвраты OutputStream эквивалентный параметру во всех отношениях за исключением того, что это локализуется: поскольку символы Unicode пишутся потоку, они автоматически преобразовываются в локальный набор символов.
Если параметром уже является локализованный поток, он может быть возвращен как результат.
- Сводка:
- Вложенный |
- Поле |
- Constr |
- Деталь:
- Поле |
- Constr |
Представьте ошибку или функцию
Для дальнейшей ссылки API и документации разработчика, см. Java Документация SE . Та документация содержит более подробные, предназначенные разработчиком описания, с концептуальными краткими обзорами, определениями сроков, обходных решений, и рабочих примеров кода.
Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Every Java application has a single instance of class Runtime that allows the application to interface with the environment in which the application is running. The current runtime can be obtained from the getRuntime method.
An application cannot create its own instance of this class.
Method Summary
Modifier and Type | Method and Description |
---|---|
void | addShutdownHook (Thread hook) |
Executes the specified command and arguments in a separate process with the specified environment and working directory.
Executes the specified string command in a separate process with the specified environment and working directory.
As of JDK 1.1, the preferred way to translate a byte stream in the local encoding into a character stream in Unicode is via the InputStreamReader and BufferedReader classes.
As of JDK 1.1, the preferred way to translate a Unicode character stream into a byte stream in the local encoding is via the OutputStreamWriter , BufferedWriter , and PrintWriter classes.
This method is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.
Methods inherited from class java.lang.Object
Method Detail
getRuntime
Returns the runtime object associated with the current Java application. Most of the methods of class Runtime are instance methods and must be invoked with respect to the current runtime object.
Terminates the currently running Java virtual machine by initiating its shutdown sequence. This method never returns normally. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks , if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts .
If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely. If shutdown hooks have already been run and on-exit finalization has been enabled then this method halts the virtual machine with the given status code if the status is nonzero; otherwise, it blocks indefinitely.
The System.exit method is the conventional and convenient means of invoking this method.
addShutdownHook
- The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit ) method is invoked, or
- The virtual machine is terminated in response to a user interrupt, such as typing ^C, or a system-wide event, such as user logoff or system shutdown.
A shutdown hook is simply an initialized but unstarted thread. When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently. When all the hooks have finished it will then run all uninvoked finalizers if finalization-on-exit has been enabled. Finally, the virtual machine will halt. Note that daemon threads will continue to run during the shutdown sequence, as will non-daemon threads if shutdown was initiated by invoking the exit method.
Once the shutdown sequence has begun it can be stopped only by invoking the halt method, which forcibly terminates the virtual machine.
Once the shutdown sequence has begun it is impossible to register a new shutdown hook or de-register a previously-registered hook. Attempting either of these operations will cause an IllegalStateException to be thrown.
Shutdown hooks run at a delicate time in the life cycle of a virtual machine and should therefore be coded defensively. They should, in particular, be written to be thread-safe and to avoid deadlocks insofar as possible. They should also not rely blindly upon services that may have registered their own shutdown hooks and therefore may themselves in the process of shutting down. Attempts to use other thread-based services such as the AWT event-dispatch thread, for example, may lead to deadlocks.
Shutdown hooks should also finish their work quickly. When a program invokes exit the expectation is that the virtual machine will promptly shut down and exit. When the virtual machine is terminated due to user logoff or system shutdown the underlying operating system may only allow a fixed amount of time in which to shut down and exit. It is therefore inadvisable to attempt any user interaction or to perform a long-running computation in a shutdown hook.
Uncaught exceptions are handled in shutdown hooks just as in any other thread, by invoking the uncaughtException method of the thread's ThreadGroup object. The default implementation of this method prints the exception's stack trace to System.err and terminates the thread; it does not cause the virtual machine to exit or halt.
In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly. This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run.
removeShutdownHook
This method should be used with extreme caution. Unlike the exit method, this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled. If the shutdown sequence has already been initiated then this method does not wait for any running shutdown hooks or finalizers to finish their work.
runFinalizersOnExit
Deprecated. This method is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.
Enable or disable finalization on exit; doing so specifies that the finalizers of all objects that have finalizers that have not yet been automatically invoked are to be run before the Java runtime exits. By default, finalization on exit is disabled.
If there is a security manager, its checkExit method is first called with 0 as its argument to ensure the exit is allowed. This could result in a SecurityException.
This is a convenience method. An invocation of the form exec(command) behaves in exactly the same way as the invocation exec (command, null, null).
This is a convenience method. An invocation of the form exec(command, envp) behaves in exactly the same way as the invocation exec (command, envp, null).
Executes the specified string command in a separate process with the specified environment and working directory.
This is a convenience method. An invocation of the form exec(command, envp, dir) behaves in exactly the same way as the invocation exec (cmdarray, envp, dir), where cmdarray is an array of all the tokens in command .
More precisely, the command string is broken into tokens using a StringTokenizer created by the call new StringTokenizer (command) with no further modification of the character categories. The tokens produced by the tokenizer are then placed in the new string array cmdarray , in the same order.
This is a convenience method. An invocation of the form exec(cmdarray) behaves in exactly the same way as the invocation exec (cmdarray, null, null).
This is a convenience method. An invocation of the form exec(cmdarray, envp) behaves in exactly the same way as the invocation exec (cmdarray, envp, null).
Executes the specified command and arguments in a separate process with the specified environment and working directory.
Given an array of strings cmdarray , representing the tokens of a command line, and an array of strings envp , representing "environment" variable settings, this method creates a new process in which to execute the specified command.
This method checks that cmdarray is a valid operating system command. Which commands are valid is system-dependent, but at the very least the command must be a non-empty list of non-null strings.
If envp is null, the subprocess inherits the environment settings of the current process.
A minimal set of system dependent environment variables may be required to start a process on some operating systems. As a result, the subprocess may inherit additional environment variable settings beyond those in the specified environment.
ProcessBuilder.start() is now the preferred way to start a process with a modified environment.
The working directory of the new subprocess is specified by dir. If dir is null, the subprocess inherits the current working directory of the current process.
If a security manager exists, its checkExec method is invoked with the first component of the array cmdarray as its argument. This may result in a SecurityException being thrown.
- The operating system program file was not found.
- Access to the program file was denied.
- The working directory does not exist.
In such cases an exception will be thrown. The exact nature of the exception is system-dependent, but it will always be a subclass of IOException .
availableProcessors
This value may change during a particular invocation of the virtual machine. Applications that are sensitive to the number of available processors should therefore occasionally poll this property and adjust their resource usage appropriately.
freeMemory
Returns the amount of free memory in the Java Virtual Machine. Calling the gc method may result in increasing the value returned by freeMemory.
totalMemory
Returns the total amount of memory in the Java virtual machine. The value returned by this method may vary over time, depending on the host environment.
Note that the amount of memory required to hold an object of any given type may be implementation-dependent.
maxMemory
Returns the maximum amount of memory that the Java virtual machine will attempt to use. If there is no inherent limit then the value Long.MAX_VALUE will be returned.
Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects.
The name gc stands for "garbage collector". The virtual machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.
The method System.gc() is the conventional and convenient means of invoking this method.
runFinalization
Runs the finalization methods of any objects pending finalization. Calling this method suggests that the Java virtual machine expend effort toward running the finalize methods of objects that have been found to be discarded but whose finalize methods have not yet been run. When control returns from the method call, the virtual machine has made a best effort to complete all outstanding finalizations.
The virtual machine performs the finalization process automatically as needed, in a separate thread, if the runFinalization method is not invoked explicitly.
traceInstructions
Enables/Disables tracing of instructions. If the boolean argument is true , this method suggests that the Java virtual machine emit debugging information for each instruction in the virtual machine as it is executed. The format of this information, and the file or other output stream to which it is emitted, depends on the host environment. The virtual machine may ignore this request if it does not support this feature. The destination of the trace output is system dependent.
If the boolean argument is false , this method causes the virtual machine to stop performing the detailed instruction trace it is performing.
traceMethodCalls
Enables/Disables tracing of method calls. If the boolean argument is true , this method suggests that the Java virtual machine emit debugging information for each method in the virtual machine as it is called. The format of this information, and the file or other output stream to which it is emitted, depends on the host environment. The virtual machine may ignore this request if it does not support this feature.
Calling this method with argument false suggests that the virtual machine cease emitting per-call debugging information.
Loads the native library specified by the filename argument. The filename argument must be an absolute path name. (for example Runtime.getRuntime().load("/home/avh/lib/libX11.so"); ). If the filename argument, when stripped of any platform-specific library prefix, path, and file extension, indicates a library whose name is, for example, L, and a native library called L is statically linked with the VM, then the JNI_OnLoad_L function exported by the library is invoked rather than attempting to load a dynamic library. A filename matching the argument does not have to exist in the file system. See the JNI Specification for more details. Otherwise, the filename argument is mapped to a native library image in an implementation-dependent manner.
First, if there is a security manager, its checkLink method is called with the filename as its argument. This may result in a security exception.
This is similar to the method loadLibrary(String) , but it accepts a general file name as an argument rather than just a library name, allowing any file of native code to be loaded.
The method System.load(String) is the conventional and convenient means of invoking this method.
loadLibrary
Loads the native library specified by the libname argument. The libname argument must not contain any platform specific prefix, file extension or path. If a native library called libname is statically linked with the VM, then the JNI_OnLoad_ libname function exported by the library is invoked. See the JNI Specification for more details. Otherwise, the libname argument is loaded from a system library location and mapped to a native library image in an implementation- dependent manner.
First, if there is a security manager, its checkLink method is called with the libname as its argument. This may result in a security exception.
The method System.loadLibrary(String) is the conventional and convenient means of invoking this method. If native methods are to be used in the implementation of a class, a standard strategy is to put the native code in a library file (call it LibFile ) and then to put a static initializer:
within the class declaration. When the class is loaded and initialized, the necessary native code implementation for the native methods will then be loaded as well.
If this method is called more than once with the same library name, the second and subsequent calls are ignored.
getLocalizedInputStream
Deprecated. As of JDK 1.1, the preferred way to translate a byte stream in the local encoding into a character stream in Unicode is via the InputStreamReader and BufferedReader classes.
Creates a localized version of an input stream. This method takes an InputStream and returns an InputStream equivalent to the argument in all respects except that it is localized: as characters in the local character set are read from the stream, they are automatically converted from the local character set to Unicode.
If the argument is already a localized stream, it may be returned as the result.
getLocalizedOutputStream
Deprecated. As of JDK 1.1, the preferred way to translate a Unicode character stream into a byte stream in the local encoding is via the OutputStreamWriter , BufferedWriter , and PrintWriter classes.
Creates a localized version of an output stream. This method takes an OutputStream and returns an OutputStream equivalent to the argument in all respects except that it is localized: as Unicode characters are written to the stream, they are automatically converted to the local character set.
If the argument is already a localized stream, it may be returned as the result.
- Summary:
- Nested |
- Field |
- Constr |
- Detail:
- Field |
- Constr |
Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2022, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.
Every Java application has a single instance of class Runtime that allows the application to interface with the environment in which the application is running. The current runtime can be obtained from the getRuntime method.
An application cannot create its own instance of this class.
Nested Class Summary
Method Summary
Executes the specified command and arguments in a separate process with the specified environment and working directory.
Executes the specified string command in a separate process with the specified environment and working directory.
Methods declared in class java.lang.Object
Method Detail
getRuntime
Returns the runtime object associated with the current Java application. Most of the methods of class Runtime are instance methods and must be invoked with respect to the current runtime object.
Terminates the currently running Java virtual machine by initiating its shutdown sequence. This method never returns normally. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
All registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. Once this is done the virtual machine halts.
If this method is invoked after all shutdown hooks have already been run and the status is nonzero then this method halts the virtual machine with the given status code. Otherwise, this method blocks indefinitely.
The System.exit method is the conventional and convenient means of invoking this method.
addShutdownHook
- The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit ) method is invoked, or
- The virtual machine is terminated in response to a user interrupt, such as typing ^C , or a system-wide event, such as user logoff or system shutdown.
A shutdown hook is simply an initialized but unstarted thread. When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently. When all the hooks have finished it will then halt. Note that daemon threads will continue to run during the shutdown sequence, as will non-daemon threads if shutdown was initiated by invoking the exit method.
Once the shutdown sequence has begun it can be stopped only by invoking the halt method, which forcibly terminates the virtual machine.
Once the shutdown sequence has begun it is impossible to register a new shutdown hook or de-register a previously-registered hook. Attempting either of these operations will cause an IllegalStateException to be thrown.
Shutdown hooks run at a delicate time in the life cycle of a virtual machine and should therefore be coded defensively. They should, in particular, be written to be thread-safe and to avoid deadlocks insofar as possible. They should also not rely blindly upon services that may have registered their own shutdown hooks and therefore may themselves in the process of shutting down. Attempts to use other thread-based services such as the AWT event-dispatch thread, for example, may lead to deadlocks.
Shutdown hooks should also finish their work quickly. When a program invokes exit the expectation is that the virtual machine will promptly shut down and exit. When the virtual machine is terminated due to user logoff or system shutdown the underlying operating system may only allow a fixed amount of time in which to shut down and exit. It is therefore inadvisable to attempt any user interaction or to perform a long-running computation in a shutdown hook.
Uncaught exceptions are handled in shutdown hooks just as in any other thread, by invoking the uncaughtException method of the thread's ThreadGroup object. The default implementation of this method prints the exception's stack trace to System.err and terminates the thread; it does not cause the virtual machine to exit or halt.
In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly. This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run.
removeShutdownHook
This method should be used with extreme caution. Unlike the exit method, this method does not cause shutdown hooks to be started. If the shutdown sequence has already been initiated then this method does not wait for any running shutdown hooks to finish their work.
This is a convenience method. An invocation of the form exec(command) behaves in exactly the same way as the invocation exec (command, null, null) .
This is a convenience method. An invocation of the form exec(command, envp) behaves in exactly the same way as the invocation exec (command, envp, null) .
Executes the specified string command in a separate process with the specified environment and working directory.
This is a convenience method. An invocation of the form exec(command, envp, dir) behaves in exactly the same way as the invocation exec (cmdarray, envp, dir) , where cmdarray is an array of all the tokens in command .
More precisely, the command string is broken into tokens using a StringTokenizer created by the call new (command) with no further modification of the character categories. The tokens produced by the tokenizer are then placed in the new string array cmdarray , in the same order.
This is a convenience method. An invocation of the form exec(cmdarray) behaves in exactly the same way as the invocation exec (cmdarray, null, null) .
This is a convenience method. An invocation of the form exec(cmdarray, envp) behaves in exactly the same way as the invocation exec (cmdarray, envp, null) .
Executes the specified command and arguments in a separate process with the specified environment and working directory.
Given an array of strings cmdarray , representing the tokens of a command line, and an array of strings envp , representing "environment" variable settings, this method creates a new process in which to execute the specified command.
This method checks that cmdarray is a valid operating system command. Which commands are valid is system-dependent, but at the very least the command must be a non-empty list of non-null strings.
If envp is null , the subprocess inherits the environment settings of the current process.
A minimal set of system dependent environment variables may be required to start a process on some operating systems. As a result, the subprocess may inherit additional environment variable settings beyond those in the specified environment.
ProcessBuilder.start() is now the preferred way to start a process with a modified environment.
The working directory of the new subprocess is specified by dir . If dir is null , the subprocess inherits the current working directory of the current process.
If a security manager exists, its checkExec method is invoked with the first component of the array cmdarray as its argument. This may result in a SecurityException being thrown.
- The operating system program file was not found.
- Access to the program file was denied.
- The working directory does not exist.
In such cases an exception will be thrown. The exact nature of the exception is system-dependent, but it will always be a subclass of IOException .
If the operating system does not support the creation of processes, an UnsupportedOperationException will be thrown.
availableProcessors
This value may change during a particular invocation of the virtual machine. Applications that are sensitive to the number of available processors should therefore occasionally poll this property and adjust their resource usage appropriately.
freeMemory
Returns the amount of free memory in the Java Virtual Machine. Calling the gc method may result in increasing the value returned by freeMemory.
totalMemory
Returns the total amount of memory in the Java virtual machine. The value returned by this method may vary over time, depending on the host environment.
Note that the amount of memory required to hold an object of any given type may be implementation-dependent.
maxMemory
Returns the maximum amount of memory that the Java virtual machine will attempt to use. If there is no inherent limit then the value Long.MAX_VALUE will be returned.
Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects.
The name gc stands for "garbage collector". The virtual machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.
The method System.gc() is the conventional and convenient means of invoking this method.
runFinalization
Runs the finalization methods of any objects pending finalization. Calling this method suggests that the Java virtual machine expend effort toward running the finalize methods of objects that have been found to be discarded but whose finalize methods have not yet been run. When control returns from the method call, the virtual machine has made a best effort to complete all outstanding finalizations.
The virtual machine performs the finalization process automatically as needed, in a separate thread, if the runFinalization method is not invoked explicitly.
traceInstructions
This method was intended to control instruction tracing. It has been superseded by JVM-specific tracing mechanisms. This method is subject to removal in a future version of Java SE.
traceMethodCalls
This method was intended to control method call tracing. It has been superseded by JVM-specific tracing mechanisms. This method is subject to removal in a future version of Java SE.
Loads the native library specified by the filename argument. The filename argument must be an absolute path name. (for example Runtime.getRuntime().load("/home/avh/lib/libX11.so"); ). If the filename argument, when stripped of any platform-specific library prefix, path, and file extension, indicates a library whose name is, for example, L, and a native library called L is statically linked with the VM, then the JNI_OnLoad_L function exported by the library is invoked rather than attempting to load a dynamic library. A filename matching the argument does not have to exist in the file system. See the JNI Specification for more details. Otherwise, the filename argument is mapped to a native library image in an implementation-dependent manner.
First, if there is a security manager, its checkLink method is called with the filename as its argument. This may result in a security exception.
This is similar to the method loadLibrary(String) , but it accepts a general file name as an argument rather than just a library name, allowing any file of native code to be loaded.
The method System.load(String) is the conventional and convenient means of invoking this method.
loadLibrary
Loads the native library specified by the libname argument. The libname argument must not contain any platform specific prefix, file extension or path. If a native library called libname is statically linked with the VM, then the JNI_OnLoad_ libname function exported by the library is invoked. See the JNI Specification for more details. Otherwise, the libname argument is loaded from a system library location and mapped to a native library image in an implementation- dependent manner.
First, if there is a security manager, its checkLink method is called with the libname as its argument. This may result in a security exception.
The method System.loadLibrary(String) is the conventional and convenient means of invoking this method. If native methods are to be used in the implementation of a class, a standard strategy is to put the native code in a library file (call it LibFile ) and then to put a static initializer:
within the class declaration. When the class is loaded and initialized, the necessary native code implementation for the native methods will then be loaded as well.
If this method is called more than once with the same library name, the second and subsequent calls are ignored.
version
Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
Every Java application has a single instance of class Runtime that allows the application to interface with the environment in which the application is running. The current runtime can be obtained from the getRuntime method.
An application cannot create its own instance of this class.
Nested Class Summary
Method Summary
Executes the specified command and arguments in a separate process with the specified environment and working directory.
Executes the specified string command in a separate process with the specified environment and working directory.
Methods declared in class java.lang.Object
Method Detail
getRuntime
Returns the runtime object associated with the current Java application. Most of the methods of class Runtime are instance methods and must be invoked with respect to the current runtime object.
Terminates the currently running Java virtual machine by initiating its shutdown sequence. This method never returns normally. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks , if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts .
If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely. If shutdown hooks have already been run and on-exit finalization has been enabled then this method halts the virtual machine with the given status code if the status is nonzero; otherwise, it blocks indefinitely.
The System.exit method is the conventional and convenient means of invoking this method.
addShutdownHook
- The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit ) method is invoked, or
- The virtual machine is terminated in response to a user interrupt, such as typing ^C , or a system-wide event, such as user logoff or system shutdown.
A shutdown hook is simply an initialized but unstarted thread. When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently. When all the hooks have finished it will then run all uninvoked finalizers if finalization-on-exit has been enabled. Finally, the virtual machine will halt. Note that daemon threads will continue to run during the shutdown sequence, as will non-daemon threads if shutdown was initiated by invoking the exit method.
Once the shutdown sequence has begun it can be stopped only by invoking the halt method, which forcibly terminates the virtual machine.
Once the shutdown sequence has begun it is impossible to register a new shutdown hook or de-register a previously-registered hook. Attempting either of these operations will cause an IllegalStateException to be thrown.
Shutdown hooks run at a delicate time in the life cycle of a virtual machine and should therefore be coded defensively. They should, in particular, be written to be thread-safe and to avoid deadlocks insofar as possible. They should also not rely blindly upon services that may have registered their own shutdown hooks and therefore may themselves in the process of shutting down. Attempts to use other thread-based services such as the AWT event-dispatch thread, for example, may lead to deadlocks.
Shutdown hooks should also finish their work quickly. When a program invokes exit the expectation is that the virtual machine will promptly shut down and exit. When the virtual machine is terminated due to user logoff or system shutdown the underlying operating system may only allow a fixed amount of time in which to shut down and exit. It is therefore inadvisable to attempt any user interaction or to perform a long-running computation in a shutdown hook.
Uncaught exceptions are handled in shutdown hooks just as in any other thread, by invoking the uncaughtException method of the thread's ThreadGroup object. The default implementation of this method prints the exception's stack trace to System.err and terminates the thread; it does not cause the virtual machine to exit or halt.
In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly. This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run.
removeShutdownHook
This method should be used with extreme caution. Unlike the exit method, this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled. If the shutdown sequence has already been initiated then this method does not wait for any running shutdown hooks or finalizers to finish their work.
runFinalizersOnExit
This method is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. This method is subject to removal in a future version of Java SE.
Enable or disable finalization on exit; doing so specifies that the finalizers of all objects that have finalizers that have not yet been automatically invoked are to be run before the Java runtime exits. By default, finalization on exit is disabled.
If there is a security manager, its checkExit method is first called with 0 as its argument to ensure the exit is allowed. This could result in a SecurityException.
This is a convenience method. An invocation of the form exec(command) behaves in exactly the same way as the invocation exec (command, null, null) .
This is a convenience method. An invocation of the form exec(command, envp) behaves in exactly the same way as the invocation exec (command, envp, null) .
Executes the specified string command in a separate process with the specified environment and working directory.
This is a convenience method. An invocation of the form exec(command, envp, dir) behaves in exactly the same way as the invocation exec (cmdarray, envp, dir) , where cmdarray is an array of all the tokens in command .
More precisely, the command string is broken into tokens using a StringTokenizer created by the call new (command) with no further modification of the character categories. The tokens produced by the tokenizer are then placed in the new string array cmdarray , in the same order.
This is a convenience method. An invocation of the form exec(cmdarray) behaves in exactly the same way as the invocation exec (cmdarray, null, null) .
This is a convenience method. An invocation of the form exec(cmdarray, envp) behaves in exactly the same way as the invocation exec (cmdarray, envp, null) .
Executes the specified command and arguments in a separate process with the specified environment and working directory.
Given an array of strings cmdarray , representing the tokens of a command line, and an array of strings envp , representing "environment" variable settings, this method creates a new process in which to execute the specified command.
This method checks that cmdarray is a valid operating system command. Which commands are valid is system-dependent, but at the very least the command must be a non-empty list of non-null strings.
If envp is null , the subprocess inherits the environment settings of the current process.
A minimal set of system dependent environment variables may be required to start a process on some operating systems. As a result, the subprocess may inherit additional environment variable settings beyond those in the specified environment.
ProcessBuilder.start() is now the preferred way to start a process with a modified environment.
The working directory of the new subprocess is specified by dir . If dir is null , the subprocess inherits the current working directory of the current process.
If a security manager exists, its checkExec method is invoked with the first component of the array cmdarray as its argument. This may result in a SecurityException being thrown.
- The operating system program file was not found.
- Access to the program file was denied.
- The working directory does not exist.
In such cases an exception will be thrown. The exact nature of the exception is system-dependent, but it will always be a subclass of IOException .
If the operating system does not support the creation of processes, an UnsupportedOperationException will be thrown.
availableProcessors
This value may change during a particular invocation of the virtual machine. Applications that are sensitive to the number of available processors should therefore occasionally poll this property and adjust their resource usage appropriately.
freeMemory
Returns the amount of free memory in the Java Virtual Machine. Calling the gc method may result in increasing the value returned by freeMemory.
totalMemory
Returns the total amount of memory in the Java virtual machine. The value returned by this method may vary over time, depending on the host environment.
Note that the amount of memory required to hold an object of any given type may be implementation-dependent.
maxMemory
Returns the maximum amount of memory that the Java virtual machine will attempt to use. If there is no inherent limit then the value Long.MAX_VALUE will be returned.
Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects.
The name gc stands for "garbage collector". The virtual machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.
The method System.gc() is the conventional and convenient means of invoking this method.
runFinalization
Runs the finalization methods of any objects pending finalization. Calling this method suggests that the Java virtual machine expend effort toward running the finalize methods of objects that have been found to be discarded but whose finalize methods have not yet been run. When control returns from the method call, the virtual machine has made a best effort to complete all outstanding finalizations.
The virtual machine performs the finalization process automatically as needed, in a separate thread, if the runFinalization method is not invoked explicitly.
traceInstructions
This method was intended to control instruction tracing. It has been superseded by JVM-specific tracing mechanisms. This method is subject to removal in a future version of Java SE.
traceMethodCalls
This method was intended to control method call tracing. It has been superseded by JVM-specific tracing mechanisms. This method is subject to removal in a future version of Java SE.
Loads the native library specified by the filename argument. The filename argument must be an absolute path name. (for example Runtime.getRuntime().load("/home/avh/lib/libX11.so"); ). If the filename argument, when stripped of any platform-specific library prefix, path, and file extension, indicates a library whose name is, for example, L, and a native library called L is statically linked with the VM, then the JNI_OnLoad_L function exported by the library is invoked rather than attempting to load a dynamic library. A filename matching the argument does not have to exist in the file system. See the JNI Specification for more details. Otherwise, the filename argument is mapped to a native library image in an implementation-dependent manner.
First, if there is a security manager, its checkLink method is called with the filename as its argument. This may result in a security exception.
This is similar to the method loadLibrary(String) , but it accepts a general file name as an argument rather than just a library name, allowing any file of native code to be loaded.
The method System.load(String) is the conventional and convenient means of invoking this method.
loadLibrary
Loads the native library specified by the libname argument. The libname argument must not contain any platform specific prefix, file extension or path. If a native library called libname is statically linked with the VM, then the JNI_OnLoad_ libname function exported by the library is invoked. See the JNI Specification for more details. Otherwise, the libname argument is loaded from a system library location and mapped to a native library image in an implementation- dependent manner.
First, if there is a security manager, its checkLink method is called with the libname as its argument. This may result in a security exception.
The method System.loadLibrary(String) is the conventional and convenient means of invoking this method. If native methods are to be used in the implementation of a class, a standard strategy is to put the native code in a library file (call it LibFile ) and then to put a static initializer:
within the class declaration. When the class is loaded and initialized, the necessary native code implementation for the native methods will then be loaded as well.
If this method is called more than once with the same library name, the second and subsequent calls are ignored.
version
Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2018, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
Читайте также: