When dealing with third-party Java applications where startup parameters are hard to verify, using the jps
tool to confirm the actually effective JVM parameters is one of the most effective diagnostic methods. Here's a step-by-step guide:
1. Basic Process Identification
jps -l -m -v
- Output Example:
12345 app.jar -Xmx2g -Dspring.profiles.active=prod
67890 com.example.MainClass -Dconfig.path=/opt/conf
-
Parameter Breakdown:
-
-l
: Displays the full package name or JAR path. -
-m
: Outputs parameters passed to the main method. -
-v
: Shows JVM arguments.
-
2. Comparing Key Parameters
Expected Parameter | JPS Verification Command | Common Issue Scenarios |
---|---|---|
Heap Memory Configuration | `jps -v | grep -E 'Xmx |
GC Algorithm Selection | {% raw %}`jps -v | grep 'Use.*GC'` |
System Properties | `jps -v | grep 'Dproperty='` |
Logging Configuration | `jps -v | grep 'logging.config'` |
3. Advanced Diagnostic Techniques
3.1 Process Filtering
# Finding a specific application process
jps -v | grep 'app-name-pattern'
# Real-time monitoring with pipes
watch -n 1 "jps -l -v | grep -v sun.tools.jps"
3.2 Parameter Tracing
# Locate the startup script path
ps -ef | grep java | grep -v grep | awk '{print $NF}'
3.3 Dynamic Verification
jinfo -flags <PID> 2>/dev/null | grep 'specific_param'
- Requires permissions to the JDK installation path.
- Supports viewing non-standard parameters like CMS collector settings.
4. Handling Common Issues
Case 1: No Output from JPS
-
Cause: Missing
tools.jar
in JRE environment. - Solution: Install a full JDK instead of just JRE.
Case 2: Incomplete Parameter Display
- Use combined commands:
jrunscript -e 'java.lang.management.ManagementFactory.getRuntimeMXBean().getInputArguments().forEach(print)'
Case 3: Container Environment Limitations
- Inside containers, run:
docker exec -it <container> /path/to/jps -v
- For Kubernetes:
kubectl exec <pod> -- jps -v
5. Verification of Parameter Effectiveness
- Memory Verification:
jstat -gc <PID> 1000 5 # Monitor heap memory changes
- GC Verification:
jstat -gcutil <PID> | awk '{print $6}' # Observe GC type
- System Properties Verification:
jinfo -sysprops <PID> | grep 'property.key'
By deeply utilizing the jps
tool chain, you can accurately identify issues like:
- Parameter typos (e.g.,
-Xmx2048m
misspelled as-Xmx2048
). - Multi-level parameter overriding in startup scripts (environment variables > command-line args > config files).
- Parameter invalidation due to container
cgroup
limits (like-Xmx
exceeding container memory). - Framework default parameters overriding custom settings (common in Spring Boot's
application.properties
).
References:
tag
OOM
OutOfMemory
Top comments (0)