likely() and unlikely()

本文介绍了GCC编译器中的likely和unlikely指令的使用方法及其原理。这些指令用于预测条件分支的方向,帮助编译器进行优化,从而提高程序运行效率。通常在错误处理等特殊情况下使用,能够显著提升性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

The gcc C compiler has a built-in directive that optimizes conditional branches as either very likely taken or very unlikely taken. The compiler uses the directive to appropriately optimize the branch. The kernel wraps the directive in very easy-to-use macros, likely() and unlikely().

For example, consider an if statement such as the following:

if (foo) {
        /* ... */
}

To mark this branch as very unlikely taken (that is, likely not taken):

/* we predict foo is nearly always zero ... */
if (unlikely(foo)) {
        /* ... */
}

Conversely, to mark a branch as very likely taken:

/* we predict foo is nearly always nonzero ... */
if (likely(foo)) {
        /* ... */
}

You should only use these directives when the branch direction is overwhelmingly a known priori or when you want to optimize a specific case at the cost of the other case. This is an important point: These directives result in a performance boost when the branch is correctly predicted, but a performance loss when the branch is mispredicted. A very common usage for unlikely() and likely() is error conditions. As one might expect, unlikely() finds much more use in the kernel because if statements tend to indicate a special case.

                                                                                                                                 from Linux Kernel Development Second Edition

 

 

---------------------------------------------------------------------------------------------

 

在linux中判断语句经常会看到likely和unlikely,例如:

if(likely(value)){
}
else{
}
 

简单从表面上看if(likely(value)) == if(value),if(unlikely(value)) == if(value)。

也就是likely和unlikely是一样的,但是实际上执行是不同的,加likely的意思是value的值为真的可能性更大一些,那么执行if的机会大,而unlikely表示value的值为假的可能性大一些,执行else机会大一些。加上这种修饰,编译成二进制代码时likely使得if后面的执行语句紧跟着前面的程序,unlikely使得else后面的语句紧跟着前面的程序,这样就会被cache预读取,增加程序的执行速度,likely和unlikely的实现在include/linux/compiler.h中:

      9 #if __GNUC__ == 2 && __GNUC_MINOR__ < 96 
     10 #define __builtin_expect(x, expected_value) (x) 
     11 #endif 
     12 
     13 #define likely(x)   __builtin_expect((x),1) 
     14 #define unlikely(x) __builtin_expect((x),0)

__builtin_expect是gcc的一个预处理命令,其解释如下:

long __builtin_expect (long exp, long c)
You may use __builtin_expect to provide the compiler with branch prediction information. In general, you should prefer to use actual profile feedback for this
(‘-fprofile-arcs’), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.
The return value is the value of exp, which should be an integral expression. The value of c must be a compile-time constant. The semantics of the built-in are that it is expected that exp == c. For example:
if (__builtin_expect (x, 0))
foo ();

would indicate that we do not expect to call foo, since we expect x to be zero. Since you are limited to integral expressions for exp, you should use constructions such as
if (__builtin_expect (ptr != NULL, 1))
error ();
when testing pointer or floating-point values.

 

转载于:https://www.cnblogs.com/yangzd/archive/2010/09/27/1837202.html

This happens when a goal of a plugin couldn't be configured. The most likely cause is that the contents of the <configuration> section for the plugin in your POM does not match the parameter types of the goal in question. E.g. trying to configure a numeric parameter from a string would trigger this error. So please verify that the configuration for the goal is correct by consulting the plugin documentation. The documentation for many common Maven plugins can be reached via our plugin index. While quite unlikely, it's also possible that the goal couldn't be configured because of a broken plugin class path. For instance, if the plugin class path is missing some dependencies of the plugin, this can result in linkage errors that prevent the configuration of the goal. To check whether the plugin JAR and its POM are intact, inspect your local repository which is usually located at ${user.home}/.m2/repository. For a plugin with the coordinates com.company:custom-maven-plugin:1.0, the file to check is com/company/custom-maven-plugin/1.0/custom-maven-plugin-1.0.jar and custom-maven-plugin-1.0.pom, respectively. If those files don't match the copies in the plugin repository, e.g. as noticeable by checksum mismatches, simply delete the local files and have Maven re-download it. If you have verified that your local copy of the JAR/POM and the JAR/POM in the plugin repository are bytewise identical but Maven still reports a linkage error, please report this to the maintainer of the plugin. 翻译
最新发布
07-24
<think>我们正在解决Maven插件配置错误:`<configuration>`部分的内容与参数类型不匹配的问题。 这个错误通常发生在Maven插件的配置中,当我们在pom.xml文件中为插件提供的配置参数与插件期望的参数不匹配时出现。 可能的原因包括: 1. 参数名称拼写错误 2. 参数类型不匹配(例如,期望是整数却提供了字符串) 3. 使用了插件不支持的参数 4. 配置的结构不正确(例如,应该使用子元素的地方使用了属性) 解决步骤: 1. 确认插件版本:检查使用的插件版本,并查看该版本的文档,确认支持的配置参数及其类型。 2. 检查配置参数:仔细检查pom.xml中该插件的<configuration>部分,确保每个参数名称和结构都与文档一致。 3. 使用IDE辅助:现代IDE(如IntelliJ IDEA)通常能够对pom.xml进行验证,并提示可能的错误。 4. 简化配置:如果配置复杂,尝试简化配置,逐个添加参数以定位问题。 示例:假设我们配置maven-compiler-plugin时错误地将`<source>`写成了`<sources>`,就会导致此错误。 正确配置示例: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.11.0</version> <configuration> <source>11</source> <target>11</target> </configuration> </plugin> ``` 错误配置示例(参数名错误): ```xml <configuration> <sources>11</sources> <!-- 应该是<source> --> <target>11</target> </configuration> ``` 另外,注意参数类型。例如,如果某个参数需要是一个列表(数组),那么应该使用子元素来配置,而不是字符串。 例如,对于maven-surefire-plugin,配置要排除的测试类,应该这样写: ```xml <configuration> <excludes> <exclude>**/ExcludedTest.java</exclude> </excludes> </configuration> ``` 而不是: ```xml <configuration> <excludes>**/ExcludedTest.java</excludes> </configuration> ``` 因为`excludes`参数是一个字符串列表(数组),所以需要嵌套`<exclude>`元素。 如果问题仍然存在,可以尝试清除Maven本地仓库中该插件的缓存,然后重新下载。 清除缓存方法: - 手动删除本地仓库中对应插件的目录(默认在~/.m2/repository下) - 或者使用命令:`mvn dependency:purge-local-repository` 最后,运行`mvn help:effective-pom`可以查看合并后的有效POM,帮助检查配置。 如果以上方法都不能解决问题,可以查看插件的官方文档或源码,确认配置方式。 引用[1]中提到Maven构建生命周期和插件目标执行,但与本问题关联不大。引用[2]是关于多部分文件上传的,也不直接相关。因此,我们主要根据Maven插件配置的通用原则来解决。 相关问题: 1. 如何查看Maven插件的可用配置参数? 2. 在Maven中如何正确配置数组类型的参数? 3. Maven插件配置错误还有哪些常见类型? 4. 如何调试Maven插件的执行过程?</think>### 解决 Maven 插件目标配置错误:`<configuration>` 内容与参数类型不匹配 #### 问题分析 当出现 `The contents of the <configuration> section does not match parameter types` 错误时,通常由以下原因导致: 1. **参数类型不匹配** 插件要求的参数类型(如整数、布尔值)与实际配置的类型(如字符串)不一致[^1] 2. **参数名称拼写错误** 插件配置项名称大小写错误或拼写错误(如 `source` 写成 `sources`) 3. **插件版本兼容性问题** 旧版本插件不兼容新版配置参数(常见于 Maven 3.x 升级后) 4. **嵌套结构错误** 需要多层嵌套的配置项被错误地扁平化处理(如 Surefire 插件的 `<excludes>` 配置) --- ### 解决方案 #### 1. 检查参数类型(核心步骤) ```xml <!-- 错误示例:source 应为数值类型却配置了字符串 --> <configuration> <source>eleven</source> <!-- ❌ 错误 --> </configuration> <!-- 正确示例 --> <configuration> <source>11</source> <!-- ✅ 数值类型 --> <verbose>true</verbose> <!-- ✅ 布尔类型 --> </configuration> ``` #### 2. 验证参数名称 使用 `maven-help-plugin` 查看插件支持的参数: ```bash mvn help:describe -Dplugin=插件组ID:插件ID -Ddetail ``` 示例输出: ``` Name: maven-compiler-plugin ... Configuration Parameters: source (Default: 1.8) User property: maven.compiler.source The -source argument for the Java compiler. ... ``` #### 3. 修复嵌套结构错误 ```xml <!-- 错误示例:扁平化配置 --> <configuration> <excludes>**/*Test.java</excludes> <!-- ❌ --> </configuration> <!-- 正确示例:Surefire 插件的多层嵌套 --> <configuration> <excludes> <exclude>**/*IntegrationTest.java</exclude> <!-- ✅ --> </excludes> </configuration> ``` #### 4. 升级插件版本 在 `pom.xml` 中显式指定兼容版本: ```xml <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.11.0</version> <!-- 替换为最新稳定版 --> </plugin> </plugins> </pluginManagement> </build> ``` #### 5. 调试配置 使用 `mvn help:effective-pom` 查看最终生效的 POM: ```bash mvn help:effective-pom > effective-pom.xml ``` 检查输出文件中插件的实际配置 --- ### 典型错误场景修复 | 错误场景 | 修复方案 | |---------|----------| | **类型不匹配**<br>`<testFailureIgnore>true</testFailureIgnore>` | 改为布尔值:`<testFailureIgnore>true</testFailureIgnore>` | | **拼写错误**<br>`<sources>11</sources>` | 修正为:`<source>11</source>` | | **旧版插件参数**<br>`<compilerVersion>11</compilerVersion>` | 新版改用:`<release>11</release>` | | **缺少嵌套**<br>`<argLine>-Xmx512m</argLine>` | 添加容器:`<argLine>-Xmx512m</argLine>` | > **重要提示**:Maven 插件参数名称**区分大小写**,且大多数参数使用**单数形式**(如 `exclude` 而非 `excludes`)[^1] --- ### 完整配置示例(maven-surefire-plugin) ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>3.1.2</version> <configuration> <!-- 布尔值参数 --> <skipTests>false</skipTests> <!-- 字符串参数 --> <argLine>-Xmx1024m</argLine> <!-- 嵌套集合参数 --> <excludes> <exclude>**/*IntegrationTest.java</exclude> </excludes> <!-- 数值参数 --> <forkCount>3</forkCount> </configuration> </plugin> ``` --- ### 验证步骤 1. 运行配置验证: ```bash mvn validate ``` 2. 执行插件目标: ```bash mvn 插件前缀:目标名 -X # -X 启用调试模式 ``` 3. 检查日志中 `[DEBUG] Configuring mojo` 部分确认参数解析 > 引用[1]提到 Maven 构建生命周期中插件目标的执行顺序,当配置错误时会导致目标执行失败[^1]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值