Kotlin 延迟初始化：lateinit与by lazy的华山论剑

张

张建站

2026/7/10 3:50:51

10分钟阅读

Kotlin 延迟初始化lateinit与by lazy的华山论剑引言Kotlin 的延迟初始化之谜在 Kotlin 的开发旅程中你是否曾为变量初始化而烦恼想象一下你正在构建一个复杂的 Android 应用其中有一些对象的初始化过程既耗时又依赖于特定的时机比如在 Activity 的生命周期方法中才能获取到必要的上下文来初始化某些服务。又或者你不想让这些对象在类加载时就占用内存而是希望在真正需要使用它们的时候才进行初始化。这时Kotlin 的延迟初始化机制就像一把神奇的钥匙为你打开了优化代码性能与结构的大门。而在延迟初始化的领域里lateinit 与 by lazy 是两把各具特色的 “利刃”它们看似相似实则在适用场景、使用方式等方面有着诸多不同。接下来就让我们深入探索 lateinit 与 by lazy 的世界看看它们如何在不同的场景中发挥作用以及在实际开发中如何抉择。lateinit显式控制的利刃基本语法lateinit 是 Kotlin 中的关键字专门用于修饰 “可变非空属性”也就是由 var 修饰的非空引用类型。使用时只需在 var 属性前添加 lateinit 关键字在声明时无需赋值后续在合适时机手动赋值即可。比如在一个简单的用户服务类中classUserService{// 模拟用户登录方法funlogin(username:String,password:String):Boolean{// 这里省略具体的登录逻辑直接返回true表示登录成功returntrue}}classDemoClass{// lateinit修饰可变非空引用类型属性lateinitvaruserService:UserServicelateinitvartitle:String}需要格外注意的是lateinit 不能用于修饰 val 属性因为 val 修饰的属性是只读的一旦初始化就不可更改这与 lateinit 需要手动赋值的特性相悖同时lateinit 也不能修饰基本数据类型如 Int、Double、Boolean 等它只能用于非空的引用类型像 String、自定义类、控件对象等。适用场景lateinit 的核心特点是 “显式初始化”这就决定了它适用于那些初始化时机由外部逻辑控制无法在属性声明时完成的场景。在依赖注入场景中当我们使用 Spring、Hilt 等依赖注入框架时服务类对象通常由框架负责初始化并注入到目标类中。比如在一个基于 Hilt 的 Android 项目中我们的 ViewModel 需要一个 Repository 来获取数据而这个 Repository 是由 Hilt 注入的此时就可以用 lateinit 修饰importjavax.inject.InjectclassUserViewModel{// lateinit修饰Repository对象由Hilt后续注入InjectlateinitvaruserRepository:UserRepository// 业务方法中使用注入的RepositoryfungetUserInfo(userId:String):User{returnuserRepository.getUserById(userId)}}// 被注入的Repository类classUserRepository{fungetUserById(userId:String):User{// 模拟从网络或数据库获取用户信息returnUser(userId,张三)}}dataclassUser(valid:String,valname:String)在生命周期回调初始化场景中以 Android 开发为例Activity、Fragment 等组件的生命周期由系统管理控件初始化如 findViewById、ViewBinding通常需要在 onCreate、onViewCreated 等生命周期方法中完成。比如我们在 Activity 中初始化一个 TextViewimportandroid.os.Bundleimportandroid.widget.TextViewimportandroidx.appcompat.app.AppCompatActivityclassMainActivity:AppCompatActivity(){// lateinit修饰TextView控件声明时不赋值lateinitvartvTitle:TextViewoverridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)// 生命周期回调中手动初始化lateinit属性tvTitlefindViewById(R.id.tv_title)// 初始化后正常使用tvTitle.text延迟初始化演示}}简单示例再深入到 Android 开发的实际场景中假设我们正在开发一个新闻类应用在 MainActivity 中有一个用于显示新闻标题的 TextView。由于 TextView 的初始化依赖于 Activity 的布局加载完成所以我们可以使用 lateinit 来延迟初始化它。importandroid.os.Bundleimportandroid.widget.TextViewimportandroidx.appcompat.app.AppCompatActivityclassMainActivity:AppCompatActivity(){// lateinit修饰TextView控件声明时不赋值lateinitvarnewsTitleTextView:TextViewoverridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)// 初始化TextViewnewsTitleTextViewfindViewById(R.id.news_title_text_view)// 从网络获取新闻数据这里简化为直接赋值valnewsTitleKotlin延迟初始化的奥秘// 设置新闻标题到TextViewnewsTitleTextView.textnewsTitle}}在依赖注入的场景下比如我们使用 Dagger2 进行依赖注入。假设有一个 UserManager 类它依赖于一个 UserService 来进行用户相关的操作。// UserService接口interfaceUserService{fungetUserDetails():String}// UserService的实现类classUserServiceImpl:UserService{overridefungetUserDetails():String{return用户详情姓名-张三年龄-25}}// 使用Dagger2的ComponentComponentinterfaceUserComponent{funinject(userManager:UserManager)}// UserManager类依赖UserServiceclassUserManager{InjectlateinitvaruserService:UserServicefunshowUserDetails(){valdetailsuserService.getUserDetails()println(details)}}// 测试代码funmain(){valcomponentDaggerUserComponent.create()valuserManagerUserManager()component.inject(userManager)userManager.showUserDetails()}关键注意点在使用 lateinit 时有几个关键的注意点需要牢记。首先不可修饰基本数据类型如果我们想要延迟初始化基本数据类型需使用 Delegates.notNull () 委托例如importkotlin.properties.DelegatesclassExample{varage:IntbyDelegates.notNull()}其次未初始化访问会报错。如果在手动初始化前访问 lateinit 属性会抛出 UninitializedPropertyAccessException 异常。不过我们可以通过属性名.isInitialized 语法检查属性是否已初始化避免异常的发生。例如classMainActivity:AppCompatActivity(){lateinitvartvTitle:TextViewoverridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)if(::tvTitle.isInitialized){tvTitle.text已初始化}else{// 这里可以进行一些提示或者其他操作println(tvTitle还未初始化)}tvTitlefindViewById(R.id.tv_title)tvTitle.text延迟初始化演示}}最后lateinit 修饰的是 var 属性这意味着初始化后仍可重新赋值这与我们即将要介绍的 by lazy 有着本质区别。例如classDemo{lateinitvarmessage:StringfunchangeMessage(){if(::message.isInitialized){message新的消息内容}else{message初始消息内容}}}by lazy自动惰性的暗器基本语法by lazy 是 Kotlin 中的属性委托机制用于实现属性的延迟初始化。它只能用于修饰 val 属性语法格式为val 属性名: 类型 by lazy { 初始化代码块 }。其中初始化代码块是一个 Lambda 表达式在属性首次被访问时才会执行执行结果会被缓存起来后续访问该属性时直接返回缓存值无需再次执行初始化代码。比如classDataLoader{// 模拟从网络加载数据的方法funloadDataFromNetwork():String{// 这里省略具体的网络请求逻辑直接返回一个模拟数据return从网络加载的数据}}classApp{// by lazy修饰的属性首次访问时才会执行初始化代码块valdata:Stringbylazy{valloaderDataLoader()loader.loadDataFromNetwork()}}适用场景by lazy 的 “自动惰性加载” 特性使其在很多场景中都能大显身手。在单例模式中by lazy 是实现线程安全单例的绝佳方式。例如objectDatabaseInstance{// by lazy实现单例首次访问时创建实例valdatabasebylazy{// 模拟创建数据库连接的过程Database()}}classDatabase{// 数据库类的构造函数init{println(数据库连接已创建)}}在配置加载场景中配置文件的读取往往是一个耗时操作使用 by lazy 可以在真正需要配置信息时才进行加载提升应用的启动速度。比如classConfigLoader{// 模拟从文件加载配置的方法funloadConfigFromFile():MapString,String{// 这里省略具体的文件读取逻辑直接返回一个模拟配置returnmapOf(key1tovalue1,key2tovalue2)}}classAppConfig{// by lazy修饰配置属性首次访问时加载配置valconfigbylazy{valloaderConfigLoader()loader.loadConfigFromFile()}}在高成本对象创建场景中像 Retrofit 实例、大型图片加载器等对象的创建成本较高使用 by lazy 可以避免在应用启动时就创建这些对象节省资源。比如创建一个 Retrofit 实例importretrofit2.Retrofitimportretrofit2.converter.gson.GsonConverterFactoryobjectApiClient{// by lazy创建Retrofit实例首次访问时初始化valretrofitbylazy{Retrofit.Builder().baseUrl(https://api.example.com/).addConverterFactory(GsonConverterFactory.create()).build()}}简单示例在一个音乐播放器应用中我们需要加载歌曲的歌词而歌词的加载可能涉及网络请求或文件读取是一个相对耗时的操作。此时就可以使用 by lazy 来延迟加载歌词。classLyricLoader{// 模拟从网络加载歌词的方法funloadLyricFromNetwork(songId:String):String{// 这里省略具体的网络请求逻辑直接返回一个模拟歌词return这是一首好听的歌歌词如下[此处为歌词内容]}}classSongPlayer{privatevalsongId123456// by lazy修饰歌词属性首次访问时加载歌词vallyricbylazy{valloaderLyricLoader()loader.loadLyricFromNetwork(songId)}funplaySong(){println(正在播放歌曲歌曲ID$songId)// 这里可以添加播放歌曲的逻辑}funshowLyric(){println(歌曲歌词${lyric})}}在上述代码中lyric属性使用 by lazy 修饰在调用showLyric方法访问lyric属性时才会执行loadLyricFromNetwork方法加载歌词避免了在SongPlayer对象创建时就进行歌词加载提高了应用的响应速度。核心特性by lazy 具有几个非常实用的核心特性。首先是惰性加载初始化代码只有在属性首次被访问时才会执行大大节省了资源。比如在一个游戏开发项目中游戏地图的加载可能涉及大量的资源和计算如果在游戏启动时就加载地图会导致游戏启动缓慢。使用 by lazy只有当玩家进入游戏地图场景时才会加载地图提升了游戏的启动速度和用户体验。其次是不可变性by lazy 修饰的是 val 属性初始化后不可修改这保证了数据的一致性和安全性。比如在一个电商应用中商品的配置信息如商品名称、价格、库存等在加载后不应该被随意修改使用 by lazy 修饰这些配置属性就可以确保其不可变性。最后是线程安全by lazy 默认是线程安全的它通过同步锁机制保证在多线程环境下初始化代码只执行一次。比如在一个多线程的网络请求场景中多个线程可能同时访问某个网络服务实例使用 by lazy 创建网络服务实例就可以确保在多线程环境下该实例只被创建一次避免了资源浪费和潜在的线程安全问题。不过我们也可以根据实际需求选择非线程安全模式NONE来获得更高的性能比如在 Android 主线程这种单线程环境中。双雄对决lateinit 与 by lazy 全面对比初始化时机lateinit 需要开发者手动赋值初始化时机完全由开发者控制。在 Activity 中我们通常在 onCreate 方法中初始化 lateinit 修饰的控件如classMainActivity:AppCompatActivity(){lateinitvarbtnLogin:ButtonoverridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)btnLoginfindViewById(R.id.btn_login)btnLogin.setOnClickListener{// 登录逻辑}}}by lazy 则是在属性首次被访问时自动初始化后续访问直接返回缓存值。比如在一个电商应用中商品数据的加载可能比较耗时我们可以使用 by lazy 来延迟加载classProductRepository{// 模拟从网络获取商品数据的方法fungetProductData():String{// 这里省略具体的网络请求逻辑直接返回一个模拟数据return商品数据名称-手机价格-5000元}}classProductManager{valproductDatabylazy{valrepositoryProductRepository()repository.getProductData()}funshowProductData(){println(productData)}}在上述代码中productData属性在调用showProductData方法首次访问时才会执行getProductData方法加载商品数据而不是在ProductManager对象创建时就加载。变量类型lateinit 只能用于 var 修饰的非空对象类型因为它允许开发者在后续手动赋值所以必须是可变的。在一个游戏开发项目中我们可能需要动态更新游戏角色的装备此时就可以使用 lateinit 修饰装备对象classEquipment{// 装备类的属性和方法}classPlayer{lateinitvarweapon:Equipment// 玩家类的其他属性和方法}by lazy 用于 val 修饰的属性初始化后不可修改适用于所有类型包括基本数据类型和对象类型。比如在一个数学计算库中我们可能需要计算一个复杂的数学常量这个常量一旦计算出来就不会改变此时就可以使用 by lazyclassMathConstants{valpibylazy{// 模拟复杂的计算过程3.141592653589793}}线程安全lateinit 不保证线程安全在多线程环境下若多个线程同时尝试初始化 lateinit 变量可能会导致数据不一致或其他并发问题需要开发者自行保证线程安全。比如在一个多线程的文件读写场景中如果多个线程同时尝试初始化一个 lateinit 修饰的文件操作对象可能会导致文件读写错误classFileOperator{lateinitvarfile:java.io.File// 文件操作方法}funmain(){valoperatorFileOperator()Thread{operator.filejava.io.File(test.txt)// 进行文件操作}.start()Thread{if(::file.isInitialized){// 进行文件操作}else{operator.filejava.io.File(test.txt)// 进行文件操作}}.start()}by lazy 默认是线程安全的它通过同步锁机制保证在多线程环境下初始化代码只执行一次。在一个多线程的网络请求场景中多个线程可能同时需要访问一个网络服务实例使用 by lazy 创建网络服务实例就可以确保在多线程环境下该实例只被创建一次避免了资源浪费和潜在的线程安全问题classNetworkService{// 网络服务类的属性和方法}objectNetworkClient{valservicebylazy{NetworkService()}}不过我们也可以根据实际需求选择非线程安全模式NONE来获得更高的性能比如在 Android 主线程这种单线程环境中classSingleThreadExample{valdatabylazy(LazyThreadSafetyMode.NONE){// 初始化代码}}使用风险lateinit 如果在未初始化时访问会抛出 UninitializedPropertyAccessException 异常。在一个测试类中如果我们不小心在初始化前访问了 lateinit 变量就会导致测试失败classTestClass{lateinitvartestData:StringfuntestMethod(){try{println(testData)}catch(e:UninitializedPropertyAccessException){println(testData未初始化)}testData测试数据println(testData)}}by lazy 如果初始化代码块中抛出异常在首次访问属性时会将异常抛出。在一个数据库连接的场景中如果初始化数据库连接时出现异常比如数据库地址错误那么在首次访问数据库连接属性时就会抛出异常classDatabaseConnection{valconnectionbylazy{try{// 模拟创建数据库连接的过程// 如果数据库地址错误这里会抛出异常java.sql.DriverManager.getConnection(jdbc:mysql://localhost:3306/mydb,user,password)}catch(e:Exception){throwRuntimeException(数据库连接失败,e)}}}通过以上对比我们可以清晰地看到 lateinit 与 by lazy 在各个方面的差异这将有助于我们在实际开发中根据具体需求做出正确的选择。实战策略如何选择正确的武器在实际开发中我们常常会在 lateinit 和 by lazy 之间犹豫不决不知道该如何选择。下面我将为大家提供一些实用的选择策略。当你需要可变属性时比如在一个游戏开发项目中游戏角色的状态如生命值、魔法值等会随着游戏进程不断变化此时就应该选择 lateinit 。因为 lateinit 修饰的是 var 属性允许我们在后续的代码中根据游戏的实际情况动态更新角色的状态classGameCharacter{lateinitvarhealth:Intlateinitvarmagic:Int// 其他属性和方法}当你需要初始化逻辑复杂时比如在一个电商应用中商品数据的加载可能涉及多个网络请求、数据解析和计算此时 by lazy 是更好的选择。它可以将复杂的初始化逻辑封装在一个代码块中在属性首次被访问时才执行避免了在应用启动时就进行复杂的计算提高了应用的响应速度classProduct{valproductDetailsbylazy{// 模拟复杂的商品数据加载过程// 可能涉及多个网络请求、数据解析和计算loadProductDetails()}privatefunloadProductDetails():String{// 这里省略具体的加载逻辑直接返回一个模拟数据return商品详情名称-手机价格-5000元描述-这是一款高性能手机}}当你追求线程安全时by lazy 是首选。因为它默认是线程安全的在多线程环境下初始化代码只会执行一次确保了数据的一致性和安全性。比如在一个多线程的文件读写场景中多个线程可能同时需要访问一个文件操作对象使用 by lazy 创建文件操作对象就可以确保在多线程环境下该对象只被创建一次避免了资源浪费和潜在的线程安全问题classFileOperator{valfilebylazy{java.io.File(test.txt)}// 文件操作方法}当你需要在生命周期回调中初始化时lateinit 是更合适的选择。比如在 Android 开发中Activity、Fragment 等组件的生命周期由系统管理控件初始化如 findViewById、ViewBinding通常需要在 onCreate、onViewCreated 等生命周期方法中完成此时使用 lateinit 修饰控件对象可以确保控件在正确的时机被初始化 classMainActivity:AppCompatActivity(){lateinitvarbtnLogin:ButtonoverridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)btnLoginfindViewById(R.id.btn_login)btnLogin.setOnClickListener{// 登录逻辑}}}通过以上策略我们可以根据具体的业务场景和需求快速准确地选择合适的延迟初始化方式让我们的代码更加高效、健壮。总结与展望掌握延迟初始化的精髓在 Kotlin 的世界里lateinit 与 by lazy 是延迟初始化的两大法宝它们各有千秋为我们解决了不同场景下变量初始化的难题。lateinit 适用于需要手动控制初始化时机的可变属性它在依赖注入和生命周期回调初始化等场景中表现出色但需要我们注意其使用限制和未初始化访问的风险。by lazy 则擅长处理只读属性的自动惰性加载在单例模式、高成本对象创建等场景中发挥着重要作用其线程安全和缓存机制为我们的代码保驾护航。在实际开发中我们要根据业务需求和场景特点灵活选择 lateinit 或 by lazy让它们成为我们优化代码性能和结构的得力助手。同时随着 Kotlin 语言的不断发展和演进延迟初始化机制也可能会有新的特性和改进希望大家持续关注不断探索在 Kotlin 的开发道路上越走越远。以上就是关于 Kotlin 中 lateinit 与 by lazy 的详细解析希望这篇文章能帮助你更好地理解和运用它们。如果你在学习或实践中有任何疑问或心得欢迎在评论区留言交流。