Bureaucrats, cc_docs_admin, cc_staff
2,306
edits
Java: Difference between revisions
Jump to navigation
Jump to search
→Pitfalls
No edit summary |
|||
| Line 32: | Line 32: | ||
===Memory Issues=== | ===Memory Issues=== | ||
Java uses an automatic system called ''garbage collection'' to identify variables which are out of scope and return the memory associated with them to the operating system which however doesn't stop many Java programs from requiring significant amounts of memory to run correctly. When a Java virtual machine is launched using the <tt>java</tt> command | Java uses an automatic system called ''garbage collection'' to identify variables which are out of scope and return the memory associated with them to the operating system which however doesn't stop many Java programs from requiring significant amounts of memory to run correctly. When a Java virtual machine is launched using the <tt>java</tt> command by default the initial and maximum heap size are set to 1/64 and 1/4 of the system's physical memory respectively. This amount, particularly the maximum heap size, may well be inadequate and leaves a substantial amount of physical memory unused. To correct this problem, you can tell the Java virtual machine the maximum amount of memory to use with the command line argument <tt>Xmx</tt>, for instance | ||
{{Command|java - | {{Command|java -Xmx8192m -jar file.jar}} | ||
tells the Java virtual machine that it can use up to | tells the Java virtual machine that it can use up to 8192 MB (8 GB) of memory. You can set the initial heap size with the argument <tt>Xms</tt> and you can see all the command line options the JVM is going to run with by specifying the following flag <tt>-XX:+PrintCommandLineFlags</tt>. | ||
Alternatively, you can use the _JAVA_OPTIONS environment variable to set the run-time options rather that passing them on the command line. This is especially convenient if you launch multiple Java calls, or call a Java program from another Java program. Here is an example how to do it: | |||
{{Command|export _JAVA_OPTIONS="-Xms256m -Xmx1g"}} | |||
When your Java program is run, it will produce a diagnostic message like this one "Picked up _JAVA_OPTIONS", verifying that the options have been picked up. | |||
Please remember that the Java virtual machine itself creates a memory usage overhead. We recommend specifying the memory limit for your job as 1-2GB more than your setting on the Java command line option -Xmx. | |||
===Garbage Collection=== | |||
By default, the Java VM uses a parallel garbage collector (GC) and sets a number of GC threads equal to the number of CPU cores on a given node, whether a Java job is threaded or not. Each GC thread consumes memory. Moreover, the amount of memory each GC thread consumes is proportional to the amount of physical memory. Therefore, we highly recommend matching the number of GC threads to the number of CPU cores you requested from the scheduler in your job submission script, like so -XX:ParallelGCThreads=12 for example. You can also use the serial garbage collector by specifying the following option -XX:+UseSerialGC, whether your job is parallel or not. | |||
===The <tt>volatile</tt> Keyword=== | ===The <tt>volatile</tt> Keyword=== | ||
This keyword has a sense very different from that which C/C++ programmers are accustomed to. In Java <tt>volatile</tt> when applied to a variable has the effect of ensuring that its value is always read from and written to main memory, which can help to ensure that modifications of this variable are made visible to other threads. That said, there are contexts in which the use of the <tt>volatile</tt> keyword are not sufficient to avoid race conditions and the <tt>synchronized</tt> keyword is required to ensure program consistency. | This keyword has a sense very different from that which C/C++ programmers are accustomed to. In Java <tt>volatile</tt> when applied to a variable has the effect of ensuring that its value is always read from and written to main memory, which can help to ensure that modifications of this variable are made visible to other threads. That said, there are contexts in which the use of the <tt>volatile</tt> keyword are not sufficient to avoid race conditions and the <tt>synchronized</tt> keyword is required to ensure program consistency. | ||
==Further Reading== | ==Further Reading== | ||
Scott Oaks and Henry Wong, ''Java Threads: Understanding and Mastering Concurrent Programming'' (3rd edition) (O'Reilly, 2012) | Scott Oaks and Henry Wong, ''Java Threads: Understanding and Mastering Concurrent Programming'' (3rd edition) (O'Reilly, 2012) | ||