I'm not sure if this is possible or not, but I have an application running that has failed in an unusual way, and I now want to see the console. Is it possible to open the Java console once an application is already running? If so, how on Windows 7? Agree with AlexR. I would use something like log4j to do your logging. Saves a LOT of hassle. I don't think you can. What you can do is run your application from the Command Prompt and check for the errors appearing. The best solution is to try to run your application from Eclipse or Netbeans so you can have a better understanding of the error causing your application to fail.
If your application does not have console on windows it was executed using javaw that does not have console by definition. Stack Overflow for Teams — Collaborate and share knowledge with a private group.
Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. How do I open a Java console for an application already running? Ask Question. Asked 10 years ago. Active 10 years ago. Viewed times. Add a comment. Active Oldest Votes. The screen captures presented in this document were taken from an instance of the interface running on Windows XP. If this directory is in your system path, you can start JConsole by simply typing jconsole in a command shell prompt.
Otherwise, you have to type the full path to the executable file. You can use JConsole to monitor both local applications, namely those running on the same system as JConsole, as well as remote applications, namely those running on other systems. Note - Using JConsole to monitor a local application is useful for development and for creating prototypes, but is not recommended for production environments, because JConsole itself consumes significant system resources.
Remote monitoring is recommended to isolate the JConsole application from the platform being monitored. For a complete reference on the syntax of the jconsole command, see the manual page for the jconsole command: Java Monitoring and Management Console.
When JConsole starts, you will be given a choice of all the Java applications that are running locally that JConsole can connect to. If you want to monitor a specific application, and you know that application's process ID, then you can also start JConsole so that it connects to that application.
This application must be running with the same user ID as JConsole. The command syntax to start JConsole for local monitoring of a specific application is the following. You can determine an application's PID in the following ways:. You can also use the jps command-line utility to determine PIDs. For example, if you determined that the process ID of the Notepad application is , then you would start JConsole with the following command.
Both JConsole and the application must by executed by the same user. The management and monitoring system uses the operating system's file permissions.
If you do not specify a process ID, JConsole will automatically detect all local Java applications, and display a dialog box that lets you select which one you want to monitor see Connecting to a JMX Agent. In the command above, hostName is the name of the system running the application and portNum is the port number you specified when you enabled the JMX agent when you started the Java VM. For more information, see Remote Monitoring and Management.
You can connect to a different host at any time by choosing Connection New Connection and entering the necessary information. Otherwise, if you do not provide any arguments when you start JConsole, the first thing you see is the connection dialog box. This dialog box has two options, allowing connections to either Local or Remote processes. Under previous releases of the Java SE platform, applications that you wanted to monitor with JConsole needed to be started with the following option.
In other words, any application that is started in the Java SE 6 HotSpot VM is detected automatically by JConsole, and does not need to be started using the above command-line option. If you start JConsole without providing a specific JMX agent to connect to, you will see the following dialog window. To connect JConsole to your application, select the application you want to monitor, then click the Connect button. The list of local processes includes applications running in the following types of Java VM.
Applications with the management agent enabled. In addition, the list also includes any applications that were started on the Java SE 6 platform without any management properties but which are later attached to by JConsole, which enables the management agent at runtime. Applications that are attachable, with the management agent disabled. An attachable application supports loading the management agent at runtime. Applications which support dynamic attach do not require the management agent to be started by specifying the com.
If you select this application, you will be informed in a note onscreen that the management agent will be enabled when the connection is made. Both appear in normal text, meaning that JConsole can connect to them.
In Figure , JConsole is selected, and the note is visible. Applications that are not attachable, with the management agent disabled. These include applications started on a J2SE 1. These applications appear grayed-out in the table and JConsole cannot connect to them. In the example connection dialog shown in Figure , the Anagrams application was started with a J2SE 5.
In the example connection dialog shown in Figure , you can see that the Anagrams application has been selected by clicking on it, but the Connect button remains grayed-out and a note has appeared informing you that the management agent is not enabled for this process.
JConsole cannot connect to Anagrams because it was not started with the correct Java VM or with the correct options. When the connection dialog opens, you are also given the option of connecting to a remote process. User name and password: the user name and password to use required only if monitoring a Java VM through a JMX agent that requires password authentication. For information about user names and passwords, see Using Password and Access Files.
The syntax of a JMX service URL requires that you provide the transport protocol used to make the connection, as well as a service access point. If the JMX agent uses a connector which is not included in the Java platform, you need to add the connector classes to the class path when you run the jconsole command, as follows. In the command above, connector-path is the directory or the Java archive Jar file containing the connector classes that are not included in the JDK, that are to be used by JConsole.
You can use the green connection status icon in the upper right-hand corner of JConsole at any time, to disconnect from or reconnect to a running Java VM. You can connect to any number of running Java VMs at a time by selecting Connection then New Connection from the drop-down menu.
The Overview tab displays graphical monitoring information about CPU usage, memory usage, thread counts, and the classes loaded in the Java VM, all in a single screen. The Overview tab provides an easy way to correlate information that was previously only available by switching between multiple tabs.
To save data from a chart, simply right-click on any chart, select Save data as You can save the data from any of the charts displayed in any of JConsole's different tabs in this way. The CSV format is commonly used for data exchange between spreadsheet applications.
The CSV file can be imported into spreadsheet applications and can be used to create diagrams in these applications. The data is presented as two or more named columns, where the first column represents the time stamps. The chart shows the memory use of the Java VM over time, for heap and non-heap memory, as well as for specific memory pools.
The memory pools available depend on which version of the Java VM is being used. Survivor Space heap : The pool containing objects that have survived the garbage collection of the Eden space. Tenured Generation heap : The pool containing objects that have existed for some time in the survivor space. Permanent Generation non-heap : The pool containing all the reflective data of the virtual machine itself, such as class and method objects.
With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas. Code Cache non-heap : The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.
You can display different charts for charting the consumption of these memory pools by choosing from the options in the Chart drop-down menu. Also, clicking on either of the Heap or Non-Heap bar charts in the bottom right-hand corner will switch the chart displayed.
Finally, you can specify the time range over which you track memory usage by selecting from the options in the Time Range drop-down menu.
For more information about these memory pools, see Garbage Collection below. Used : the amount of memory currently used, including the memory occupied by all objects, both reachable and unreachable.
Committed : the amount of memory guaranteed to be available for use by the Java VM. The amount of committed memory may change over time. The Java virtual machine may release memory to the system and the amount of committed memory could be less than the amount of memory initially allocated at start up.
The amount of committed memory will always be greater than or equal to the amount of used memory. Max : the maximum amount of memory that can be used for memory management. Its value may change or be undefined.
A memory allocation may fail if the Java VM attempts to increase the used memory to be greater than committed memory, even if the amount used is less than or equal to max for example, when the system is low on virtual memory.
GC time : the cumulative time spent on garbage collection and the total number of invocations. It may have multiple rows, each of which represents one garbage collector algorithm used in the Java VM.
The bar chart on the lower right-hand side shows the memory consumed by the memory pools in heap and non-heap memory. The bar will turn red when the memory used exceeds the memory usage threshold.
You can set the memory usage threshold through an attribute of the MemoryMXBean. Heap memory is the runtime data area from which the Java VM allocates memory for all class instances and arrays. The heap may be of a fixed or variable size. The garbage collector is an automatic memory management system that reclaims heap memory for objects.
Non-heap memory includes a method area shared among all threads and memory required for the internal processing or optimization for the Java VM. It stores per-class structures such as a runtime constant pool, field and method data, and the code for methods and constructors. The method area is logically part of the heap but, depending on the implementation, a Java VM may not garbage collect or compact it.
Like the heap memory, the method area may be of a fixed or variable size. The memory for the method area does not need to be contiguous. In addition to the method area, a Java VM may require memory for internal processing or optimization which also belongs to non-heap memory. A memory pool represents a memory area that the Java VM manages. The Java VM has at least one memory pool and it may create or remove memory pools during execution.
A memory pool can belong either to heap or to non-heap memory. A memory manager manages one or more memory pools. The garbage collector is a type of memory manager responsible for reclaiming memory used by unreachable objects. A Java VM may have one or more memory managers. It may add or remove memory managers during execution. A memory pool can be managed by more than one memory manager.
Garbage collection GC is how the Java VM frees memory occupied by objects that are no longer referenced. It is common to think of objects that have active references as being "alive" and non-referenced or unreachable objects as "dead. The algorithms and parameters used by GC can have dramatic effects on performance. Generational GC takes advantage of the observation that most programs conform to the following generalizations. Generational GC divides memory into several generations, and assigns one or more memory pools to each.
When a generation uses up its allotted memory, the VM performs a partial GC also called a minor collection on that memory pool to reclaim memory used by dead objects. This partial GC is usually much faster than a full GC. The Java HotSpot VM defines two generations: the young generation sometimes called the "nursery" and the old generation. The young generation consists of an "Eden space" and two "survivor spaces.
When it performs a minor GC, the VM moves any remaining objects from the Eden space to one of the survivor spaces. The VM moves objects that live long enough in the survivor spaces to the "tenured" space in the old generation. When the tenured generation fills up, there is a full GC that is often much slower because it involves all live objects.
The permanent generation holds all the reflective data of the virtual machine itself, such as class and method objects. The default arrangement of generations looks something like Figure If the garbage collector has become a bottleneck, you can improve performance by customizing the generation sizes.
Using JConsole, you can investigate the sensitivity of your performance metric by experimenting with the garbage collector parameters. For more information, see Tuning Garbage Collection with the 5.
The Threads list in the lower left corner lists all the active threads. If you enter a string in the Filter field, the Threads list will show only those threads whose name contains the string you enter.
Click on the name of a thread in the Threads list to display information about that thread to the right, including the thread name, state, and stack trace. The Threading MXBean provides several other useful operations that are not covered by the Threads tab.
This operation returns an array of deadlocked thread IDs. This includes the name, stack trace, and the monitor lock that the thread is currently blocked on, if any, and which thread is holding that lock, as well as thread contention statistics.
This MXBean lists all the attributes and operations for accessing threading information in the Java VM being monitored. See Monitoring and Managing MBeans. To check if your application has run into a deadlock for example, your application seems to be hanging , deadlocked threads can be detected by clicking on the "Detect Deadlock" button.
If any deadlocked threads are detected, these are displayed in a new tab that appears next to the "Threads" tab, as shown in Figure The Detect Deadlock button will detect deadlock cycles involving object monitors and java.
Monitoring support for java.
0コメント