发布时间：2020年7月21日 - 3分钟阅读
在JetBrains博客上，Roman Elizarov刚刚放出了一个非常大的消息，如果你在Kotlin/Native和多平台的世界里。
如果你看完这篇文章后还有问题，想让我们提供意见，请提交你的KN并发问题，我们会给你回复。
显式线程控制的 "冻结 "并发模型，正在发生变化。
在过去的2年多时间里，我一直在讨论这个并发和运行时模型。从安全的角度来看，有很多可取之处。不受限制的共享内存访问是有问题的，说得轻巧一点。在运行时强制执行一些规则意味着额外的安全，并迫使你思考你的JVM代码是如何架构的。也许可以用不同的方式来做？
当然，如果退一步讲，我在过去几年里做了很多内容来解释这个模型。那就意味着，也许，对于开发者来说，它很难学。这当然是一个独特的模型，而且JVM和Native生活在不同的规则下，这确实是一些混乱的根源。
解读那篇博客
我想强调一下博客中的一些部分，并讨论一下。 最重要的一点是在TL;DR中。
"现有的代码将继续工作，并将被支持。"
需要强调的是，这个帖子说的是未来的变化，你的Native代码将与这些未来的变化兼容。
"为了解决这些问题，我们已经开始为Kotlin/Native开发一个替代的内存管理器，它将允许我们解除对Kotlin/Native中对象共享的限制......"
这意味着运行时强化的线程约束模型将消失。大家对 "对象共享 "的含义有些困惑。这不仅仅是全局对象。是完整的内存管理模式。
"我们计划以一种与现有代码大部分兼容的方式引入它，因此目前正在工作的代码将继续工作。"
"大部分兼容 "可能听起来像一个问题，但除非你有一些非常奇特的东西，否则它应该可以正常工作。冻结仍将存在，但它将是可选的（像Javascript一样）。注解仍然会有实现，即使它们不再做任何事情。
你的代码将继续工作，而且在许多情况下，工作得更快。
"而且我们将研究如何改进Kotlin在整个Kotlin语言中处理不可变数据的方法，而不仅仅是在Kotlin/Native中。"
这一部分很有意思。JVM和Native在运行时的工作方式不同是最大的问题之一。改进语言中的不可变数据，并将其应用于并发的最佳实践，听起来是件好事，但我们必须看看会出现什么。
"同时，我们会继续支持现有的内存管理器，我们会发布Kotlin/Native的多线程库，这样你就可以在它们之上开发你的应用。"
这一点很重要。对于我们的应用程序，我们使用多线程coroutines分支。我们小心翼翼地使用它，以避免Roman帖子中讨论的潜在内存泄漏，但它是库生态系统的核心部分。我们会持续支持它。
现在怎么办？
好吧，就我个人而言，我要去找其他的事情在会议上谈论:)
除此之外，_现在_没有什么变化。内存管理器的更新没有时间表，但你可以假设这将是相当长的一段时间。这不是几个月后的事。这意味着，在可预见的未来，如果你写Kotlin/Native代码，你需要了解冻结模型以及如何在其中写代码。所有我们一直在谈论的东西仍然适用。
KMP作为一个平台不断成熟，只要这些更新到来，你现在为Native写的并发代码将继续工作。
我想我们（Touchlab）可能会开始围绕如何完成某些任务制作内容，而不是围绕基本原理（"冻结 "等）进行更深入的解释。基本上是技术配方。比如，如何使用Flow和Sqldelight，如何处理各种场景下的网络等等。你主要可以隐藏当前内存模型的细节，当这些变化来临时，你可以写好过渡的代码。
所以，现在变化不大，但变化肯定会到来。最终，这将提高采用率，这对生态系统来说是好事。我相信以后我还会有更多的话要说......
通过( www.DeepL.com/Translator )（免费版）翻译
