Troubleshooting guide for java

Troubleshooting Java SE

The Java Platform, Standard Edition (Java SE) allows the development and deployment of a large variety of complex applications.

This web page contains pointers to information to help you troubleshoot problems you encounter with applications developed with Java SE release 8.

(For troubleshooting information for J2SE release 7, see Troubleshooting J2SE 7)

Contents of This Page

Troubleshooting Guide

The Java Troubleshooting guide is available (in English only) to help you diagnose and solve problems that occur in applications running on Java SE 8:

  • Troubleshooting Guide for Java SE 8
    • Describes the Java SE troubleshooting tools, how to develop your own tools using the APIs provided with the platform, several suggested troubleshooting procedures, how to submit bug reports, and detailed reference information.
    • Describes common issues which can occur with Java SE desktop technologies, such as Swing, AWT, Java 2D, and so forth, as well as suggestions for troubleshooting these issues.
    • Document last updated August 2014

    Quick Tips!

    For a few quick tips, consult these tables of typical troubleshooting needs, with corresponding commands, by platform.

    Troubleshooting Tools

    The Troubleshooting Guide for Java SE 8 contains a list of monitoring and debugging tools in Java SE 8. Note that these tools are unsupported and experimental in nature, and they might not be available in future JDK versions.

    Pertinent Articles for Troubleshooting

    • Monitoring and Managing Java SE 6 Platform Applications — by Mandy Chung — How to use several monitoring and management tools to troubleshoot common problems with Java SE applications.
    • Introduction to Java VisualVM — Overview of Java VisualVM, the all-in-one graphical and extensible troubleshooting tool.

    Pertinent Blogs for Troubleshooting

    The Planet JDK site represents an aggregation of JDK developers’ blogs.

    The following is a (non-exhaustive) list of bloggers’ helpful information and tips for troubleshooting Java SE applications.

    • Frank Kieviet’s blog: «OutOfMemoryError: PermGen space» exception
    • A. Sundararajan’s (Sundar) blog:
      • Serviceability Agent, command-line arguments, creating binary heap dumps, using DTrace, JConsole, all troubleshooting tools
      • viewing heap histogram
      • Querying Java heap with OQL (Object Query Language)
      • Perm gen analysis with OQL
      • jrunscript, heapViewer demo, attach-on-demand API

      Pertinent Forum Sites for Troubleshooting

      Visit the various forum sites, where you can browse for information and post your own questions. Perhaps someone else has already encountered your problem! Use the Search facility on the forum site to specify your problem area.

      This is a very brief list of pointers to the high-level entries into some of these sites.

      Источник

      Troubleshooting guide for java

      This chapter provides some guidelines for setting up both Java and a Java application for better troubleshooting techniques. These proactive Java setups help debug and narrow down issues with Java and the application. Not all suggestions apply to every application.

      This chapter contains the following sections:

      Set Up Java for Troubleshooting

      Set up the Java environment and command-line options to enable gathering relevant data for troubleshooting.

      To set up Java, perform the following:

      1. Update the Java version: Use the latest Java version to avoid spending time on troubleshooting issues in Java that were fixed. Often, a problem caused by a bug in the Java runtime is fixed in the latest update release. Working with the latest Java version helps avoid some known and common issues.
      2. Set up the Java environment to debug: Consider the following scenarios while setting up a bigger Java application, starting an application with a launcher script, or running distributed Java on several machines.
        1. Make it easy to change the Java version: Using the latest Java version helps avoid many runtime issues. If your application starts by running a script, ensure that you have to update the Java path in only one place. If you run in a distributed system, then think about easy ways to change the Java versions across all of the machines.
        2. Make it easy to change the Java command-line options: Sometimes, while troubleshooting, you may want to change Java options; for example, to add a verbose output, to turn off a feature, or to tune Java for better performance. Prepare your systems for these changes.

        In a Java application that is running remotely, for example in a testing framework or a cloud solution, ensure that you can still change the Java flags easily. Sometimes, the application takes command-line parameters, or you may want to try a flag quickly to reproduce a problem. Prepare the systems to make these changes easy.

        Enable Options and Flags for JVM Troubleshooting

        Set up JVM options and flags to enable gathering relevant data for troubleshooting.

        The data you gather depends on the system and what data you would use in case you run into problems. Consider gathering the following data.

        1. Enable core files: If Java crashes, for example due to a segmentation fault, the OS saves to disk a core file (complete dump of the memory). On Linux, core files are sometimes disabled by default. To enable core files on Linux, it is usually enough to run the ulimit -c unlimited before starting the application command. Some systems may have different ways to handle these limits.

        To decide whether to enable core files, consider what you would do if you had a crash in your system. Would you want to see a core file? Many Java users won’t have much use for a core file. However, if you would want to debug a possible crash either in a native debugger such as gdb or by using the Serviceability Agent, then ensure that you enable core files before the starting the application. Many times, crashes are hard to reproduce; therefore, enable core files before the starting the application.

        Like core files, heap dumps can be very large, especially when run with a big Java heap. Again, think about what you would do if the application runs into an OutOfMemoryError . Would you want to inspect the heap at the time of the error? In that case, enable this option so that you get this data if the application runs into an unexpected OutOfMemoryError . (The option is disabled by default.)

        Continuous flight recordings are a circular buffer of Flight Recorder events. If the application runs into an issue, you can dump the data from the last hour of the run. The Flight Recorder events can be helpful to debug a wide range of issues from memory leaks to network errors, high CPU usage, thread blocks, and so on. The overhead of running with a continuous flight recording is very low. See Produce a Flight Recording.

        The garbage collector log helps diagnose issues when the application throws an OutOFMemoryError or the application runs into performance issues; therefore, turning on the -verbosegc flag helps troubleshoot issues.

        Use log rotation so that an application restart doesn’t delete the previous logs. Since JDK7, the flags UseGClogFileRotation and NumberOfGCLogFiles can be used to set up for log rotation. For a description of these flags, see Debugging Options for Java HotSpot VM.

        If your application starts with a script, run java -version to print the Java version and print the command line before running it. Another alternative is to add -XX+PrintCommandLineFlags and -showversion to the JVM arguments.

        Another alternative, is to enable JMX after a Java application has started is to use the diagnostic command ManagementAgent.start . Run jcmd help ManagementAgent.start for a list of flags that can be sent with the command. See The jcmd Utility.

        Gather Relevant Data

        If your application runs into a problem and you want to debug the problem further, ensure that you collect any relevant data before restarting the system, especially if restarting will remove previous files.

          It is important to gather the following files:

        • Core files for crash issues.
        • hs_err printed text file for Java crashes.
        • Log files: Java and application logs.
        • Java heap dumps for -XX:+HeapDumpOnOutOfMemoryError .
        • Flight recordings (if enabled). If the problem didn’t terminate the application, dump the continuous recordings.
        • Stack traces: Take several stack traces using jcmd Thread.print before restarting the system.
        • Dump flight recordings (if enabled).
        • Force a core file: If the application can’t be closed properly, then stop the application, and force a core file using kill -6 on Linux systems.

        Make a Java Application Easier to Debug

        Using a logging framework is a good way to enable future debugging.

        If you run into problems in a specific module, you should be able to enable logging in that module. It is also good to specify different levels of logging, for example info, debug, and trace. For more information about Java logging, see Java Logging Overview.

        Источник

        Contents

        4 Troubleshoot Performance Issues Using JFR

        Part II Debug JVM Issues

        5 Troubleshoot System Crashes

Оцените статью