SonarQube-Java规范之Atomic-".equals()" should not be used to test the values of "Atomic" classes

本文介绍了AtomicInteger和AtomicLong的正确使用方法。这两个类用于支持单个变量的线程安全操作,并且无需锁定。文章强调了比较AtomicInteger或AtomicLong实例时不应直接使用equals方法,而是应该调用get方法获取其值后再进行比较。

AtomicInteger, and AtomicLong extend Number, but they're distinct from Integer and Long and should be handled differently. AtomicInteger and AtomicLong are designed to support lock-free, thread-safe programming on single variables. As such, an AtomicInteger will only ever be "equal" to itself. Instead, you should .get() the value and make comparisons on it.

AtomicInteger类和AtomicLong类继承自Number类,但是它们与Integer类和Long类有不同点,因此在使用上也有不同。AtomicInteger类和AtomicLong类是为支持单个变量的线程安全和无需锁定而设计的。因此,一个AtomicInteger对象的".equals()"方法比较只有在跟自己比较的时候才会返回true。所以,对于比较它们的值是否相等,就应当使用AtomicInteger对象的”.get()“方法,进行取值比较。

This applies to all the atomic, seeming-primitive wrapper classes: AtomicIntegerAtomicLong, and AtomicBoolean.

这条规则适用于所有的atomic类对象,具体参考封装类:AtomicInteger,AtomicLong和AtomicBoolean

Noncompliant Code Example

错误的代码示例
AtomicInteger aInt1 = new AtomicInteger(0);
AtomicInteger aInt2 = new AtomicInteger(0);

if (aInt1.equals(aInt2)) { ... }  // Noncompliant

Compliant Solution

正确的代码示例
AtomicInteger aInt1 = new AtomicInteger(0);
AtomicInteger aInt2 = new AtomicInteger(0);

if (aInt1.get() == aInt2.get()) { ... }
Unable to start the daemon process. This problem might be caused by incorrect configuration of the daemon. For example, an unrecognized jvm option is used.For more details on the daemon, please refer to https://docs.gradle.org/8.4/userguide/gradle_daemon.html in the Gradle documentation. Process command line: C:\Program Files\Huawei\jdk-17.0.12\bin\java.exe -XX:MaxPermSize=4096m --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx12000m -Dfile.encoding=GBK -Duser.country=CN -Duser.language=zh -Duser.variant -cp D:\software\Gradle\wrapper\dists\gradle-8.4-all\wrapper\dists\gradle-8.4-bin\3zpymbixyuq1q0dpx8adwsagz\gradle-8.4\lib\gradle-launcher-8.4.jar -javaagent:D:\software\Gradle\wrapper\dists\gradle-8.4-all\wrapper\dists\gradle-8.4-bin\3zpymbixyuq1q0dpx8adwsagz\gradle-8.4\lib\agents\gradle-instrumentation-agent-8.4.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 8.4 Please read the following process output to find out more: ----------------------- Unrecognized VM option 'MaxPermSize=4096m' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ----------------------- Check the JVM arguments defined for the gradle process in: - gradle.properties in project root directory
最新发布
06-13
<think>我们正在解决GradleDaemon无法启动的问题,错误提示为"UnrecognizedVMoption'MaxPermSize=4096m'"原因分析:该错误是由于在Gradle配置中使用了过时的JVM参数'MaxPermSize'。在较新的JVM版本中,已经移除了PermGen空间,取而代之的是Metaspace,因此'MaxPermSize'参数不再被支持。解决方案:修改gradle.properties文件中的JVM参数,将'MaxPermSize'替换为适用于新JVM版本的参数。具体步骤:1.定位到gradle.properties文件。该文件通常位于项目根目录下,或者位于用户主目录的.gradle文件夹中(例如:C:\Users\Administrator\.gradle\gradle.properties)[^3]。2.打开gradle.properties文件,查找包含'org.gradle.jvmargs'的行,该行可能配置了'MaxPermSize'。3.将'MaxPermSize'参数删除或替换为Metaspace相关参数(如'MaxMetaspaceSize')。同时,确保其他参数也是有效的。示例:错误的配置可能如下:org.gradle.jvmargs=-Xmx4096m-Xms512m-XX:MaxPermSize=4096m应修改为(移除MaxPermSize,或替换为MaxMetaspaceSize):org.gradle.jvmargs=-Xmx4096m-Xms512m-XX:MaxMetaspaceSize=512m或者,如果不需要特殊配置Metaspace,可以只保留内存设置:org.gradle.jvmargs=-Xmx4096m-Xms512m4.保存文件,然后重新启动Gradle构建。注意:如果项目中有多个gradle.properties文件(例如项目级和全局级),请确保修改正确的文件。同时,检查环境变量GRADLE_OPTS是否也设置了过时参数。备选方案:如果修改后仍然出现问题,可以尝试清除GradleDaemon:./gradlew--stop或者删除整个.gradle目录下的缓存(谨慎操作,会清除所有缓存):删除用户目录下的.gradle/caches和.gradle/daemon目录(或整个.gradle目录)引用参考:根据官方文档,`org.gradle.jvmargs`用于指定Gradle守护进程的JVM参数[^2]。在配置时需要注意参数的适用性。另外,如果最近升级了JDK(如引用[4]提到升级到OpenJDK20),可能需要确认Gradle版本是否兼容该JDK版本。如果不兼容,建议使用Gradle支持的标准JDK版本(如JDK8、JDK11或JDK17等)。为了验证配置是否生效,可以运行:./gradlew-v该命令会打印Gradle版本信息,同时也会显示使用的JVM参数。如果问题仍然存在,请检查JAVA_HOME环境变量是否指向了合适的JDK版本。最后,建议升级Gradle到较新版本,因为新版本通常对新的JDK支持更好。综上,我们通过修改gradle.properties文件中的JVM参数来解决此问题。生成相关问题:</think> ### Gradle Daemon 启动失败解决方案 问题核心是 `Unrecognized VM option 'MaxPermSize=4096m'`,这是由于过时的 JVM 参数导致的(`MaxPermSize` 已被 JDK 8+ 弃用[^4])。以下是系统化解决步骤: --- #### 🔧 **步骤 1:修改 `gradle.properties` 文件** ```properties # 删除或替换 MaxPermSize(关键!) org.gradle.jvmargs=-Xmx512m -XX:MaxMetaspaceSize=256m ``` - 📍 **文件位置**: - 项目级:`项目根目录/gradle.properties` - 全局级:`C:\Users\用户名\.gradle\gradle.properties` [^3] - ✅ **正确参数**: - `-Xmx512m`:JVM 堆内存上限 - `-XX:MaxMetaspaceSize=256m`:替代 `MaxPermSize`(Metaspace 大小限制)[^2] --- #### ⚠️ **步骤 2:检查 JDK 兼容性** 1. **确认 JDK 版本**: ```bash java -version ``` - JDK 8+ 已移除 `PermGen`,改用 Metaspace - 若使用 OpenJDK 20,需降级至 **JDK 11/LTS 版本**(Android 开发推荐)[^4] 2. **设置环境变量**: - `JAVA_HOME` 指向兼容 JDK(如 JDK 11) - 删除旧版 JDK 残留配置 --- #### ♻️ **步骤 3:清理 Gradle 缓存** ```bash # 停止所有 Gradle 守护进程 ./gradlew --stop # 清理缓存(执行任意位置) rm -rf $HOME/.gradle/caches ``` --- #### 📌 **技术原理** | 参数 | 已弃用 (`MaxPermSize`) | 替代方案 (`MaxMetaspaceSize`) | |------|------------------------|-----------------------------| | **作用** | 永久代内存限制 | Metaspace 内存限制 | | **弃用原因** | JDK 8 移除了 `PermGen` 区域 | JDK 8+ 使用 Metaspace 管理类元数据 [^2] | | **默认值** | - | 无上限(动态扩展) | > ⚡ **性能提示**:`MaxMetaspaceSize` 可防止内存泄露导致无限增长,但不宜过小(推荐 ≥256m)。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值