Some JMX information (from developerworks)

Virtual Machine Detection

JMX and Virtual Machine Detection

The proposal of JMX provides a Java-layer detection mechanism for Java virtual machines. In j2se, the newly proposedjava.lang.managementA package is an application of JMX in JDK. It provides a large number of useful interfaces. Through mbean, it provides remote monitoring and detection methods for Java virtual machines and runtime, to help users detect the running status of local or remote virtual machines. With JMX, we can design a client, to detect the number of threads in a running virtual machine at the far end, the current stack of the thread, memory management, the time occupied by GC, the objects in the Virtual Machine and the parameters of the current virtual machine, and other important parameters and runtime information.. Another important function of JMX is to detect and reconfigure configuration information. For example, we can view and modify the verbose parameter of the current JVM at the remote end to achieve dynamic management. We can even run a GC command on the remote JVM, which is described in detail below.

Virtual Machine detection API provided by JMX

The current status of virtual machines is always concerned by Java openers. Because of this, a large number of profiler tools are available to detect the current status of virtual machines. After Java SE 5, in JDK, we have some Java Virtual Machine detection APIs, that isjava.lang.managementPackage. The management package includes many mxbean interface classes and lockinfo, memoryusage, monitorinfo, and threadinfo classes. It can be seen from the name that the package provides a detection mechanism for VM memory allocation, garbage collection (GC), operating system layer, thread scheduling, shared locks, and even compilation. In this way, Java developers can easily perform lightweight system detection for themselves to determine the status of the current program, so that they can adjust it at any time.

To obtain this information, we first usejava.lang.management.ManagementFactoryThis factory class gets a series of mxbeans. Including:

• Classloadingmxbean

  Classloadmxbean includes some class loading information, such as how many classes have been loaded/uninstalled (unloaded), and the verbose option for Virtual Machine class loading (that is, the Java-verbose: Class option in the command line) whether to enable or disable this option.

• Compilationmxbean

  Compilationmxbean helps you understand the current compiler and compilation conditions. The mxbean does not provide much information.

• Garbagecollectormxbean

  Compared with the degree of attention of the open personnel on GC, The mxbean provides very limited information, and only provides an approximate value of the number of GC times and total GC time. However, this package also provides three memory management detection classes: memorymanagermxbean, memorymxbean, and memorypoolmxbean.

  • Memorymanagermxbean

    This class is relatively simple and provides the name information of the memory management class and Memory Pool (memory pool.

  • Memorymxbean

    This class provides the memory usage of the entire virtual machine, including the memory occupied by Java heap and non-Java heap, and the number of objects waiting for finalize, it can even be used for GC (actually calling system. GC ).

  • Memorypoolmxbean

    This information provides a large amount of information. In JVM, there may be several memory pools, so there is the corresponding memory pool information. Therefore, in the factory class, getmemorypoolmxbean () gets a list of memorypoolmxbeans. Each memorypoolmxbean contains detailed information about the memory pool, such as availability, memory in use/maximum memory usage, and setting the maximum memory value.

• Operatingsystemmxbean

  This class provides simple information about the operating system, such as the architecture name, current CPU count, and recent system load.

• Runtimemxbean

  The runtime information includes the name, provider, version number, classpath, bootclasspath, and system parameters of the current virtual machine.

• Threadmxbean

  In the multi-threaded Java System, thread monitoring is very important. Threadmxbean plays this role. Threadmxbean can provide information including various states of each thread, CPU usage, and thread status throughout the system. Obtain the threadinfo object of a thread from threadmxbean. This object contains all information about this thread.

Relationship between Java. Lang. Management and virtual machines

We know that the relationship between management and underlying virtual machines is very close. In fact, some of them rely directly on public APIs provided by virtual machines, such as jvmti; others do not, A large part is provided by the underlying Virtual Machine with some undisclosed APIs/native code. This design ensures that the management package can provide sufficient information and make the provision of such information more efficient. It also makes the management package very closely linked with the underlying layer.

Back to Top

API improvement in Java 6

Management was welcomed after Java SE 5 was proposed. In Java 6, this package provides more APIs to better provide information.

Operatingsystemmxbean. getsystemloadaverage ()

Java programs usually focus on the load and memory conditions inside the virtual machine, regardless of the overall system status. However, in many cases, the system load of the entire computer system will also have a certain impact on the virtual machine during the running of Java programs. With the development of Java, Java programs have covered various industries, and this point must also be noted. In the past, using native code to detect system loads was often the only option, but in Java 6, JDK itself provided a lightweight system load detection API, that isOperatingSystemMXBean.getSystemLoadAverage().

Of course, this API actually only returns a simple estimation of the system load for the previous minute. The main purpose of its design is to estimate the current system load in a simple and fast manner, so it first ensures that the efficiency of this API is very high; because of this, this API is actually not applicable to all systems.

Lock Detection

We know that synchronization is an important feature of the Java language. In Java SE, the primary synchronization mechanism relies on the synchronize keyword to lock an object. In Versions later than Java SE 5, the concurrent package is added, the synchronization capability of Java is greatly enhanced. Concurrent provides many different types of lock mechanisms for extension. Therefore, it is necessary to better observe the status of the current virtual machine and the running state of different threads, observe various locks in the virtual machine, and the relationship between threads and locks. Unfortunately, in the past JDK, we did not have very convenient APIs for use. A direct detection method is to view the stack trace of a thread. A more powerful and comprehensive (but more complex and inefficient) solution is to get a snapshot of all the VM objects and find them, these policies are costly and often require complex native code.

JDK 6 provides some simple APIs to provide this service. First, we understand two new classes: lockinfo and monitorinfo, which carry the lock information. Lockinfo can be any Java lock, including simple Java locks andjava.util.concurrentThe lock used in the package (including the implementation class/subclass of abstractownablesynchronizer and condition), while monitorinfo is the lock represented by a simple Java object. To detect the locks and waiting locks owned by a thread, first obtain the threadinfo of a thread, and then you can simply call:

• getLockedMonitors()

  Returns a list of lock objects that the current thread has mastered.

• getLockedSynchronizers()

  For threads using the concurrent package, return a list of "ownable synchronizer" (I .e., abstractownablesynchronizer and its subclass) owned by the thread.

• getLockInfo()

  The information of the lock object that the current thread is waiting for can be used to know all the lock information of the thread. With the lock information, we can easily know the lock information of all threads of the current virtual machine. As a result, we can export more information.

Deadlock Detection

Deadlock Detection has always been a concern of software engineers. Obviously, a deadlock system is always the biggest nightmare of engineers. Java program Deadlock Detection has always been a headache for Java programmers. To solve the deadlock problem between threads, there are generally two methods: Prevention (code implementation phase) and recovery (runtime) after deadlock. In the past, Java programmers paid attention to the former, because it was quite troublesome to detect and restore the system in the running state and lacked a lot of necessary information. However, for some complicated systems, it is also very important to take the latter or debug the deadlock information during runtime. As mentioned above, we can now know the locks owned and waited by every thread, so it is feasible to calculate whether there is a deadlock in the current system. Of course, Java 6 also provides an API to complete this function, namely:

• ThreadMXBean.findDeadlockedThreads()

  This function is used to detect deadlocked threads in the current system. Of course, this function is complex and therefore time-consuming. Basically, it is only used for debugging to improve the calling of complex system threads.

Future Development

JMX's functions in Java SE 5/6 are quite powerful, but there is still some distance from the requirements of Java program developers. Therefore, Sun has proposed JSR 255 (jmx api 2.0) to JCP) to expand and further develop JMX, and hope this JSR will be implemented in Java SE 7. The new JMX 2.0 will focus on:

• Optimize the management model and provide better support; Add new features such as annotation;
• Optimization of the definition of JMX, while further strengthening the advantages of good mbean scalability, tries its best to change the disadvantages that mbean is hard to implement (which is widely recognized by users;
• Support for non-Java platform clients. This will be an exciting new feature;

Specific extensions may include:

• Hierarchical namespace );
• New event service functions;
• New support for locales;
• Enable annotation service for mbean;
• You can also use user-type mapping;

As you can see, the further development of JMX focuses on the aspects that Java users are very concerned about, such as scalability, dynamic nature, and ease of use.