PrintCommandLineFlags

最新推荐文章于 2023-09-06 09:59:15 发布
原创 最新推荐文章于 2023-09-06 09:59:15 发布 · 3.7k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #runtime

PrintCommandLineFlags 打印HotSpotVM 采用的自动优化参数

11:21 [cafe@a01.crond.uc.zhaowei.youku]$ java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=526651072 -XX:MaxHeapSize=8426417152 -XX:ParallelGCThreads=18 -XX:+PrintCommandLineFlags -XX:+UseCompressedOops -XX:+UseParallelGC 
java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)




11:48 [cafe@a01.crond.uc.zhaowei.youku]$ java -XX:+PrintGCDetails -version
java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)
Heap
 PSYoungGen      total 150080K, used 2574K [0x00000007588b0000, 0x0000000763020000, 0x0000000800000000)
  eden space 128704K, 2% used [0x00000007588b0000,0x0000000758b33860,0x0000000760660000)
  from space 21376K, 0% used [0x0000000761b40000,0x0000000761b40000,0x0000000763020000)
  to   space 21376K, 0% used [0x0000000760660000,0x0000000760660000,0x0000000761b40000)
 PSOldGen        total 342912K, used 0K [0x0000000609a00000, 0x000000061e8e0000, 0x00000007588b0000)
  object space 342912K, 0% used [0x0000000609a00000,0x0000000609a00000,0x000000061e8e0000)
 PSPermGen       total 21248K, used 2318K [0x0000000604800000, 0x0000000605cc0000, 0x0000000609a00000)
  object space 21248K, 10% used [0x0000000604800000,0x0000000604a43b68,0x0000000605cc0000)
Python | 使用argparse解析命令行参数
TechFlow的博客
09-08 2182
今天是Python专题第27篇文章，我们来聊聊Python当中的命令行参数工具argparse。 命令行参数工具是我们非常常用的工具，比如当我们做实验希望调节参数的时候，如果参数都是通过硬编码写在代码当中的话，我们每次修改参数都需要修改对应的代码和逻辑显然这不太方便。比较好的办法就是把必要的参数设置成通过命令行传入的形式，这样我们只需要在运行的时候修改参数就可以了。 sys.argv 解析命令行传入参数最简单的办法就是通过sys.argv，sys.argv可以获取到我们通过命令行传入的参数。 import
-XX:+PrintCommandLineFlags
张紫娃的博客
07-06 606
【代码】-XX:+PrintCommandLineFlags。
Command-Line Flags
aeoluspu的专栏
02-01 843
package main import "flag" import "fmt" func main() {     wordptr := flag.String("word", "foo", "a string")     numbptr := flag.Int("numb", 42, "an int")     boolprr := flag.Bool("fork",
使用-XX:+PrintCommandLineFlags展示JVM启动参数
Eric_qiushui的博客
01-03 1446
导语: 近期在学习周志明老师的<<深入理解Java虚拟机: JVM高级特性与最佳实践(第3版)>>, 在IDEA中测试老师的示例代码时, 发现程序的输出和老师的输出不一样, 想到可能是我的JVM启动参数与老师的不一样, 有没有什么办法来查看JVM启动参数呢? 一. 背景 1. Java版本 # 使用 java -verison 命令查看 java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-.
【jvm jdk】查看jvm默认参数 PrintFlagsFinal & PrintFlagsInitial & PrintCommandLineFlags
m0_45406092的博客
12-06 5630
-XX:+PrintFlagsInitial 是打印所有的默认参数设置 -XX:+PrintFlagsFinal 是打印最终值，如果某个默认值被新值覆盖，显示新值 -XX:+PrintCommandLineFlags 是打印那些被新值覆盖的项 参考：《JVM实用参数（三）打印所有XX参数及值》 ...
JVM调优：-XX:+PrintCommandLineFlags 查看程序使用的默认JVM参数
学亮编程手记
04-29 6599
idea通过PrintCommandLineFlags无法显示默认GC收集
NULL
01-11 722
通过命令 java -XX:+PrintCommandLineFlags -version 结果 JDK1.8无法显示 UseParallelGC (并行GC) 原因是JDK版本是 32位,默认是client模式,所以无法显示垃圾收集器 解决办法 1),通过 java -version 命名查看jdk的版本 2),重新下载新的jdk的64位版本 ,然后重新执行上面的命令,这样就解决了问题 ...
java -XX:+PrintCommandLineFlags -version 输出结果解析
低调的码农-博客
09-08 1794
这里写自定义目录标题1.cmd执行命令2.JVM（HotSpot）参数选项提供了三大类第一类：“-”开头，标准参数，JVM（HotSpot）都支持。第二类：“-X”开头，非标准参数，各自版本的JVM（HotSpot）支持各自命令。第三类：“-XX”开头，不稳定参数，也许JVM（HotSpot）下个版本会取消。回归正题 1.cmd执行命令 java -XX:+PrintCommandLineFlags -version 输出如下： 2.JVM（HotSpot）参数选项提供了三大类 第一类：“-”开头，标准
怎么理解java -XX:+PrintCommandLineFlags -version输出的结果
u013343616的博客
04-30 1796
cmd执行命令： java -XX:+PrintCommandLineFlags -version 输出如下 输出的东西，怎么理解？ JVM提供以下三大类选项： 标准选项 这类选项的功能是很稳定的，在后续版本中也不太会发生变化。 运行java或者 java -help 可以看到所有的标准选项。 语法： 所有的标准选项都是以 - 开头，比如-version，-server等。 X选项 这类选项的功能还是很稳定，但官方的说法是它们的行为可能会在后续版本中改变，也有可能不在后续版本中提供了. 运行 java -
JVM - 列出JVM默认参数及运行时生效参数
小工匠
07-06 2万+
文章目录Pre-XX:+PrintFlagsInitial 列出JVM参数的默认值-XX:+PrintFlagsFinal 列出运行程序时生效的值-XX:+PrintCommandLineFlags 列出被用户或者JVM优化设置过的详细的XX参数的名称和值列举附加隐藏参数 Pre 有的时候，想看下自己没有设置的JVM参数的值， 或者有的时候想看下JVM某个参数的默认值 ，亦或想看下用户或者JVM修改的JVM参数 ？ 咋办 ？ JVM在1.6.0_14以后提供了几个参数可以打印出来所有XX参数和对应的值
三种方式查看 JVM 垃圾收集器
快乐的小三菊的博客
09-06 4307
111
3.2、查看 JVM 垃圾回收器类型的三个方式
༺ bestcxx的专栏 ༻
08-02 1707
文章目录引题前言——参数信息命名上的差异查看 垃圾回收器类型 的三个方法方法一 PrintCommandLineFlags方法二(通过GC日志和堆信息)方法三(通过 jmap -heap vmid)JDK 版本和默认垃圾回收器 引题 不同版本 JVM 默认使用的 垃圾回收器是不同的，可以通过一些参数进行选择，那么我们如何得知 JVM 使用的是那些垃圾回收器呢？ 前言——参数信息命名上的差异 本文介绍通过 JVM 的参数信息来识别垃圾回收器，这里特别强调的是参数信息中命名和垃圾回收器的名字不是完全对应的。
JAVA面试题整理
weixin_40383674的博客
05-16 344
Java基础(33) 面向对象 什么是面向对象？对比面向过程，是两种不同的处理问题的角度，面向过程更注重事情的每一个步骤及顺序，面向对象更注重事情有哪些参与者（对象）、及各自需要什么，比如洗衣机洗衣服： 面向过程：会将任务拆解成一系列的步骤：打开洗衣机----->放衣服----->放洗衣粉----->清洗----->烘干 面向对象：会拆出人和洗衣机两个对象： 人：打开洗衣机 放衣服 放洗衣粉 洗衣机：清洗 烘干 从以上例子能看出，面向过...
JVM基础知识---JVM常见的参数配置
07-11 3072
JVM参数调优一. JVM参数类型①. 标配参数②. X参数（了解）③. XX参数（重点）二. 查看运行的Java程序，JVM参数是否开启，具体值为多少？①. 编写阻塞Java程序②. jps -l 得到进程号③. jinfo -flag④. 运行程序的时候配置JVM参数⑤. jinfo -flags *** 命令⑥. JVM的XX参数之Xms，Xmx三. 查看JVM默认参数①. XX:+PrintFlagsInitial 主要是查看初始默认值②. -XX:+PrintFlagsFinal：表示
查看Java命令行初始化堆和最大堆空间的大小
码农UP2U
12-05 1515
通过 -XX:+PrintCommandLineFlags 参数可以查看 Java 命令行初始堆大小以及最大堆大小： java -XX:+PrintCommandLineFlags -version -XX:InitialHeapSize=197070528 -XX:MaxHeapSize=3153128448 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePa
JVM 中打印设置的 XX 选项及值
实践求真知
09-05 313
一点睛 下面是常用打印设置方法，另外还可以配合jinfo使用。 -XX:+PrintCommandLineFlags 可以让在程序运行前打印出用户手动设置或 JVM 自动设置的 XX 选项 -XX:+PrintFlagsInitial 打印所有 XX 选项的默认值 -XX:+PrintFlagsFinal 打印所有 XX 选项在运行时生效的值 -XX:+PrintVMOptions 打印 JVM 的参数 二 实战 E:\JVMDemo3>jps 7300 Remot...
Java虚拟机|JVM知识点汇总及简述-＞JVM运行时参数及如何分析GC日志
光看不点赞的博客
06-12 1367
Java虚拟机|JVM知识点汇总及简述-＞JVM运行时参数及如何分析GC日志
Java程序员必学的Hotspot JVM选项
热门推荐
jewes的专栏
12-26 2万+
本文将介绍Hotspot JVM的常用选项。 选项的分类 Hotspot JVM提供以下三大类选项： 1. 标准选项：这类选项的功能是很稳定的，在后续版本中也不太会发生变化。运行java或者java -help可以看到所有的标准选项。所有的标准选项都是以-开头，比如-version， -server等。 2. X选项：比如-Xms。这类选项都是以-X开头，可能由于这个原因它们被称为X
java 打印机设置参数设置_JVM参数（三）打印所有XX参数及值
weixin_35681614的博客
02-13 859
$ java -client -XX:+PrintFlagsFinal Benchmark[Global flags]uintx AdaptivePermSizeWeight = 20 {product}uintx AdaptiveSizeDecrementScaleFactor = 4 {product...
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:6100 IACP UPLOAD FILE SERVICE starting... -XX:ConcGCThreads=1 -XX:+CrashOnOutOfMemoryError -XX:+ExplicitGCInvokesConcurrent -XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:+eapDumpOnOutOfMemoryError -XX:InitialHeapSize=536870912 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=536870912 -XX:MinHeapSize=536870912 -XX:-OmitStacTraceInFastThrow -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseComressedOops -XX:+UseG1GC [0.097s][info][gc] Using G1 Listening for transport dt_socket at address: 6100 Exception in thread "main" java.lang.NoSuchMethodError: 'void ch.qos.logback.classic.LoggerContext.setMDCAdapter(org.slf4j.spi.MDCAdapter)' at ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:43) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:201) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:187) at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:511) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:497) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:446) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:472) at cn.com.truthvision.iacp.biz.file.storage.FileStorageServiceApplication.<clinit>(FileStorageServiceApplication.java:22) failed to start IACP UPLOAD FILE SERVICE!
最新发布
08-07
<think>我们面对的问题有两个关键点： 1. SLF4J报告发现了多个绑定（两个不同的SLF4J实现：logback-classic和slf4j-nop） 2. 在初始化Logback时出现了AbstractMethodError，这是因为Spring Boot的LogLevelConfigurator与当前Logback版本不兼容 根本原因分析： 根据异常信息，`org.springframework.boot.logging.logback.RootLogLevelConfigurator`没有实现`ch.qos.logback.classic.spi.Configurator`接口的`configure`方法。 这通常是因为Spring Boot的日志自动配置与当前使用的Logback版本不兼容。 另外，SLF4J在类路径中发现了两个绑定（logback-classic和slf4j-nop），这会导致不可预测的行为，因为SLF4J只能使用一个绑定。 解决方案： 步骤1：解决多个SLF4J绑定的问题 我们需要排除掉其中一个绑定。通常，`slf4j-nop`是一个空实现（不记录任何日志），而`logback-classic`是Logback的实现。我们通常希望使用Logback，所以应该排除`slf4j-nop`。 在Maven项目中，我们可以通过排除依赖来实现： 查找哪个依赖引入了`slf4j-nop`，然后排除它。 例如，如果依赖树显示某个依赖引入了`slf4j-nop`，我们可以这样排除： ```xml <dependency> <groupId>some.group</groupId> <artifactId>some-artifact</artifactId> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-nop</artifactId> </exclusion> </exclusions> </dependency> ``` 步骤2：解决AbstractMethodError 这个错误表明Spring Boot的日志配置器与Logback版本不兼容。Spring Boot的每个版本都对Logback有特定的版本要求。 我们可以尝试以下方法： a) 确保Spring Boot版本与Logback版本兼容。例如，Spring Boot 2.x通常要求Logback 1.2.x（但具体要看Spring Boot的版本）。 b) 如果项目中显式声明了Logback版本，尝试移除显式声明，让Spring Boot管理版本。 c) 如果项目中没有显式声明，可能是某个依赖引入了不兼容的Logback版本。我们需要排除旧版本的Logback，并确保使用Spring Boot兼容的版本。 例如，在Maven中，我们可以通过以下方式查看依赖树： ``` mvn dependency:tree ``` 然后，排除旧版本的Logback依赖（比如logback-classic和logback-core）： ```xml <dependency> <groupId>some.group</groupId> <artifactId>some-artifact</artifactId> <exclusions> <exclusion> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> </exclusion> <exclusion> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> </exclusion> </exclusions> </dependency> ``` 步骤3：确保依赖管理 如果是Spring Boot项目，最好使用Spring Boot的依赖管理（BOM）来控制版本。在pom.xml中，我们通常会有： ```xml <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>你的Spring Boot版本</version> </parent> ``` 或者 ```xml <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>你的Spring Boot版本</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ``` 步骤4：验证 运行`mvn dependency:tree`，确保： - 没有`slf4j-nop` - 只有一个Logback版本，并且与Spring Boot版本兼容 补充：Spring Boot与Logback版本的对应关系（部分） - Spring Boot 1.5.x -> Logback 1.1.x - Spring Boot 2.0.x -> Logback 1.2.x（注意：Spring Boot 2.0要求Logback 1.2.0以上） - Spring Boot 2.1.x -> Logback 1.3.x（但实际Spring Boot 2.1.x默认还是1.2.x，具体看官方文档） - Spring Boot 2.3.x -> Logback 1.2.11（默认） - Spring Boot 2.4.x -> Logback 1.2.3（但可以通过覆盖属性升级） 注意：异常中提到的`logback-classic-1.2.12.jar`，这个版本是1.2.x，应该是兼容Spring Boot 2.x的。但是为什么会出现`AbstractMethodError`呢？可能是因为同时存在了不同版本的Logback核心类（比如logback-core版本不一致）或者Spring Boot的日志初始化类与Logback版本不匹配。 另外，异常堆栈中显示`StaticLoggerBinder`来自`logback-classic-1.2.12`和`slf4j-nop-1.7.25`，所以第一步排除`slf4j-nop`是必须的。 步骤5：如果问题仍然存在 检查项目中是否有自定义的`logback.xml`或`logback-spring.xml`？如果有，尝试暂时移除，看是否问题消失。因为可能是配置文件中使用了新版本Logback的特性，而实际运行时加载了旧版本的Logback类。 或者，尝试清理Maven本地仓库中与Logback相关的jar包，重新下载。 总结： 1. 排除多余的SLF4J绑定（slf4j-nop） 2. 确保Logback版本一致且与Spring Boot兼容 3. 排除其他依赖引入的旧版本Logback 根据上述步骤，应该能解决启动问题。</think>### 解决 Java 应用启动失败问题：SLF4J 绑定冲突与 Logback 配置错误 #### 问题分析 根据日志信息，存在两个核心问题： 1. **SLF4J 多绑定冲突** ```log SLF4J: Found binding in [jar:file:/usr/file-storage-service/lib/logback-classic-1.2.12.jar!...] SLF4J: Found binding in [jar:file:/usr/file-storage-service/lib/slf4j-nop-1.7.25.jar!...] ``` SLF4J 要求类路径中只能有一个日志实现绑定[^1]，当前存在两个冲突绑定： - `logback-classic`（实际日志实现） - `slf4j-nop`（空实现，会禁用所有日志） 2. **Logback 版本兼容性错误** ```log Exception in thread "main" java.lang.AbstractMethodError: Receiver class org.springframework.boot.logging.logback.RootLogLevelConfigurator does not define... ``` 表明 Spring Boot 的日志配置器与当前 Logback 版本存在接口不兼容（常见于 Logback 1.2.x 与 Spring Boot 2.x 组合）。 --- ### 解决方案分步指南 #### 步骤 1：排除冗余 SLF4J 绑定 删除冲突的 `slf4j-nop` 依赖（空实现会抑制日志输出）： ```xml <!-- Maven 排除示例 --> <dependency> <groupId>your.project.group</groupId> <artifactId>file-storage-service</artifactId> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-nop</artifactId> </exclusion> </exclusions> </dependency> ``` ```gradle // Gradle 排除示例 implementation('your.project.group:file-storage-service') { exclude group: 'org.slf4j', module: 'slf4j-nop' } ``` #### 步骤 2：统一 Logback 版本 确保 Logback 与 Spring Boot 版本兼容（Spring Boot 2.5+ 需 Logback ≥1.3.0）： ```xml <!-- 在 pom.xml 中显式声明兼容版本 --> <properties> <logback.version>1.3.0</logback.version> <!-- 修复 AbstractMethodError --> </properties> <dependencies> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logback.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>${logback.version}</version> </dependency> </dependencies> ``` #### 步骤 3：验证依赖树 运行依赖分析命令确认冲突已解决： ```bash # Maven mvn dependency:tree -Dincludes=ch.qos.logback,org.slf4j # Gradle gradle dependencies --configuration runtimeClasspath | grep -E 'ch.qos.logback|org.slf4j' ``` **期望输出**：仅保留一个 SLF4J 绑定（如 `logback-classic`），无 `slf4j-nop` 和旧版 Logback。 #### 步骤 4：清理并重建项目 ```bash # Maven mvn clean install -U # Gradle gradle clean build --refresh-dependencies ``` #### 步骤 5：添加诊断配置（可选） 在 `application.properties` 中启用日志初始化详情： ```properties # 显示 Logback 初始化过程 logging.level.ch.qos.logback=TRACE # 禁用 Spring Boot 默认日志配置（疑难排查时使用） logging.config=classpath:logback-spring.xml ``` --- ### 关键原理说明 1. **SLF4J 绑定机制** SLF4J 在启动时扫描 `org/slf4j/impl/StaticLoggerBinder.class`，多个实现会导致不可预测行为[^1]。 2. **AbstractMethodError 根源** Spring Boot 的 `RootLogLevelConfigurator` 实现了 Logback 的 `Configurator` 接口，当 Logback 版本低于 1.3.0 时，接口方法不匹配引发该错误。 3. **依赖优先级** Maven/Gradle 使用 **最短路径优先** 原则解析依赖，显式声明可覆盖传递依赖版本[^3]。 --- ### 验证成功的标志 应用启动日志应显示： ```log SLF4J: Actual binding is of type [ch.qos.logback.classic.LoggerContext] Logback initialized successfully Listening for transport dt_socket at address: 6100 ``` --- ### 相关问题 1. 如何诊断 Maven 项目中其他依赖冲突问题？ 2. Spring Boot 3.x 需要哪个最低版本的 Logback？ 3. 除了 Logback，Spring Boot 还支持哪些日志框架？如何切换？ 4. 生产环境中如何配置 Logback 实现日志自动归档和清理[^2]？ 5. 微服务架构下如何统一管理多个服务的日志配置？ 通过上述步骤，您应该能解决 SLF4J 绑定冲突和 Logback 版本兼容性问题，确保应用正常启动。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值