kotlin与Spring, 默认类,方法,property为final带来的问题--依赖注入失效,NullPointerException异常

当在Spring中使用Kotlin时,由于Kotlin类、方法和属性默认为final,导致Spring的依赖注入失效,出现NullPointerException。问题主要在于Kotlin的final特性与Spring的CGLIB代理不兼容。解决方案是将@Async等注解的方法、类和属性声明为open,或者使用Kotlin的all-open插件自动将特定注解的类转换为open。这个问题提醒我们理解框架底层原理的重要性,特别是在使用AOP时。

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

问题的由来

在Spring中使用kotlin, 发现依赖注入似乎没有生效,导致NPE.
比如以下的代码,对于发送短信这个功能, 并不需要在主流程中同步发送, 所以就使用了Spring的@Async注解, 可以使这个方法在配置AsyncExecutor中执行.
但是实际调用时, 却发现contactDao为null, 程序报NullPointerException异常. 但是我用java写却没有问题.

@Service
open class MessageService {
    //根据用户id获取用户联系信息的Dao
    @Autowired
    lateinit var contactDao: ContactDao

    //将message发给一系列的用户ids
    @Async
    fun sendMessage(contactIds: List<String>, message: String) {
        //先根据id获取用户联系信息
        contactIds.map { contactDao.getContactById(it) }
                //对每个用户发送message
                .forEach { contact ->
                    sendPhoneMessage(contact.phone,message)
                }
    }

    fun sendPhoneMessage(phoneNumber:String, message:String){
        ...
    }
}

原理

解决这个问题, 就需要对Spring的源码有一定的了解.
简单的说就是kotlin的类, 方法, property默认都是final, 是不能够被子类更改的. 而Spring的cglib代理需要非final类, 方法.

  1. Spring的异步注解(@Async), 事务(@Transactional), 缓存(@Cacheable,@CachePut,@CacheEvict等),Configuration这些其实都要更改方法的执行流程, 也就是说要使用代理来更改.
  2. 对于不指定具体代理方法, 且没有实现接口的类, spring会选择使用cglib来进行代理
  3. cglib代理过程是先根据Bean实例的类,生成一个子类(配置了拦截器), 然后寻找构造器, 构造一个子类实例(并没有对该实例进行任何注入设置, 该实例的属性的都是null).
  4. 代理后生成的实例非final方法调用会转发给原bean, 就可以获得依赖注入的属性值. 但是final方法是不会被代理的, 所以对上面的kotlin bean操作, 那么property肯定是null.

解决方法

所以我们可以手动将@Async注解的方法的kotlin类的类, 所有方法, 所有属性都改为open. 这样cglib代理时就不会有问题了.

open class MessageService {

    @Autowired
    lateinit open var contactCache: ContactCache

    @Async
    open fun sendMessage(contactIds: List<String>, message: AlarmMessage) {
        contactIds.map { contactCache.getContactById(it) }
                .forEach { contact ->
                    sendPhoneMessage(contact.phone,message)
                }
    }

    open fun sendPhoneMessage(phoneNumber:String, message:String){
        ...
    }
}

或者使用官方的maven插件,kotlin all open插件.
All-open compiler plugin
配置all open依赖, 使用spring plugin, 就可以将有@Component, @Async, @Transactional, @Cacheable等的类编译为open了.

<plugin>
    <artifactId>kotlin-maven-plugin</artifactId>
    <groupId>org.jetbrains.kotlin</groupId>
    <version>${kotlin.version}</version>
    <configuration>
        <compilerPlugins>
            <plugin>spring</plugin>
        </compilerPlugins>
        <jvmTarget>1.8</jvmTarget>
    </configuration>
    <executions>
        <execution>
            <id>compile</id>
            <phase>compile</phase>
            <goals>
                <goal>compile</goal>
            </goals>
        </execution>
        <execution>
            <id>test-compile</id>
            <phase>test-compile</phase>
            <goals>
                <goal>test-compile</goal>
            </goals>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-maven-allopen</artifactId>
            <version>${kotlin.version}</version>
        </dependency>
    </dependencies>
</plugin>

总结:

Effective Java第二版第17条: 要么为继承而设计, 并提供文档说明, 要么就禁止继承.kotlin类, 方法默认final应该来源于此. 这条建议的确很好…不过对于我们这种普通开发者来说, 这个改变, 的确造成了很多不便, 特别是使用AOP的框架, 如果对源码不熟悉, 就很容易出错. 对于框架的开发者来说, 这的确是一个很好的实践.

这个问题的讨论可以看这里, kotlin语言的开发者有讨论为什么要将kotlin类和方法设计为final : https://discuss.kotlinlang.org/t/a-bit-about-picking-defaults/1418

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值