React 18 RC 版本发布，正式版临门一脚了！

Posted 2022-03-16 魔术师卡颂

大家好，我是 ConardLi，今天给大家带来一个令人兴奋的消息：React 18 RC 版本发布啦！

去年6月份 React 18 发布 alpha 版本的时候，我已经第一时间试用，并且给大家分享了一波：【第一批吃螃蟹】试用 React 18 ！

不过 alpha 毕竟还是属于内部测试版本，可能还包括一些 bug，功能也有很多没放出来，大家不能在生产里去用。

这次发布的是 RC 版本(Release Candidate候选版本）：基本和最终发布的 stable 版本一样，功能上不会再有太大变化，也更加稳定，大家可以尝试用起来了 ～

版本：

，可能会在控制台看到一个警告：
Use createRoot instead. Until you switch to the new API, your app will behave as if it’s running React 17. Learn more: https://reactjs.org/link/switch-to-createroot
这是因为 React 18 中引入了一个新的 Root API，它支持了最新的 concurrent renderer，让你可以自己决定是否启用并发渲染的能力。
也改为了 root.unmount：
还将之前 render 函数的回调函数干掉了，因为通常它在配合 Suspense 一起使用的时候得不到预期的效果：
的服务端渲染，需要升级到：hydrateRoot：
为了完全支持服务端的 Suspense 和流式SSR，改进了 react-dom/server 的 API，旧的 Node.js 流式 API 将会被完全弃用：
renderToNodeStream 弃用⛔️️，使用时将发出警告。
对应新版 Node 环境的流式传输 API 为：renderToPipeableStream。
另外，React 在这个版本还引入了新的 renderToReadableStream 来支持 Deno、Cloudflare worker 等其他环境的流式 SSR 和 Suspense。
renderToString、renderToStaticMarkup 这两个 API 还可以继续用，但是对 Suspense 支持就不那么友好了。
想了解更多，可以看 React 18 官方工作组的博客：https://github.com/reactwg/react-18/discussions/22
中的批处理简单来说就是将多个状态更新合并为一次重新渲染，由于设计问题，在 React 18 之前，React 只能在组件的生命周期函数或者合成事件函数中进行批处理。默认情况下，Promise、setTimeout 以及其他异步回调是无法享受批处理的优化的。
开始，如果你使用了 createRoot，所有的更新都会享受批处理的优化，包括Promise、setTimeout 以及其他异步回调函数中。
手动退出：
官方工作组的博客：https://github.com/reactwg/react-18/discussions/21
的更新机制对于很多第三方 React 库都是阻断性的，如果想要适配 React 18，这些库可能要通过下面这些 API 做一些改造：
useId 是一个新的 Hook，用于在客户端和服务端生成唯一id，同时避免 hydration 的不兼容，这可以解决 React 17 以及更低版本的问题。
useSyncExternalStore 是一个新的 Hook，它允许外部存储通过强制同步更新来支持并发读取。推荐把这个新的 API 推荐应用到任何与 React 外部状态集成的库。
useInsertionEffect 是一个新的 Hook，它可以解决 CSS-in-JS 库在渲染中动态注入样式的性能问题。
的支持。如果你的业务在 IE 还有用户，只能继续使用 React 17 及以下的版本了～。
如果大家想了解更多内容，欢迎查看 React 官方博客：https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html

彦祖，点个「在看」吧

JVM源码分析之临门一脚的OutOfMemoryError完全解读

概述

OutOfMemoryError，说的是java.lang.OutOfMemoryError，是JDK里自带的异常，顾名思义，说的就是内存溢出，当我们的系统内存严重不足的时候就会抛出这个异常(PS:注意这是一个Error，不是一个Exception，所以当我们要catch异常的时候要注意哦)，这个异常说常见也常见，说不常见其实也见得不多，不过作为Java程序员至少应该都听过吧，如果你对jvm不是很熟，或者对OutOfMemoryError这个异常了解不是很深的话，这篇文章肯定还是可以给你带来一些惊喜的，通过这篇文章你至少可以了解到如下几点：

• OutOfMemoryError一定会被加载吗
• 什么时候抛出OutOfMemoryError
• 会创建无数OutOfMemoryError实例吗
• 为什么大部分OutOfMemoryError异常是无堆栈的
• 我们如何去分析这样的异常

OutOfMemoryError类加载

既然要说OutOfMemoryError，那就得从这个类的加载说起来，那这个类什么时候被加载呢？你或许会不假思索地说，根据java类的延迟加载机制，这个类一般情况下不会被加载，除非当我们抛出OutOfMemoryError这个异常的时候才会第一次被加载，如果我们的系统一直不抛出这个异常，那这个类将一直不会被加载。说起来好像挺对，不过我这里首先要纠正这个说法，要明确的告诉你这个类在jvm启动的时候就已经被加载了，不信你就执行java -verbose:class -version打印JDK版本看看，看是否有OutOfMemoryError这个类被加载，再输出里你将能找到下面的内容：

[Loaded java.lang.OutOfMemoryError from /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/rt.jar]

这意味着这个类其实在vm启动的时候就已经被加载了，那JVM里到底在哪里进行加载的呢，且看下面的方法:

bool universe_post_init() {

    ...    // Setup preallocated OutOfMemoryError errors
    k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_OutOfMemoryError(), true, CHECK_false);
    k_h = instanceKlassHandle(THREAD, k);
    Universe::_out_of_memory_error_java_heap = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_metaspace = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_class_metaspace = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_array_size = k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_gc_overhead_limit =
      k_h->allocate_instance(CHECK_false);
    Universe::_out_of_memory_error_realloc_objects = k_h->allocate_instance(CHECK_false);


    ...    if (!DumpSharedSpaces) {    // These are the only Java fields that are currently set during shared space dumping.
    // We prefer to not handle this generally, so we always reinitialize these detail messages.
    Handle msg = java_lang_String::create_from_str("Java heap space", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_java_heap, msg());

    msg = java_lang_String::create_from_str("Metaspace", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_metaspace, msg());
    msg = java_lang_String::create_from_str("Compressed class space", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_class_metaspace, msg());

    msg = java_lang_String::create_from_str("Requested array size exceeds VM limit", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_array_size, msg());

    msg = java_lang_String::create_from_str("GC overhead limit exceeded", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_gc_overhead_limit, msg());

    msg = java_lang_String::create_from_str("Java heap space: failed reallocation of scalar replaced objects", CHECK_false);
    java_lang_Throwable::set_message(Universe::_out_of_memory_error_realloc_objects, msg());

    msg = java_lang_String::create_from_str("/ by zero", CHECK_false);
    java_lang_Throwable::set_message(Universe::_arithmetic_exception_instance, msg());    // Setup the array of errors that have preallocated backtrace
    k = Universe::_out_of_memory_error_java_heap->klass();
    assert(k->name() == vmSymbols::java_lang_OutOfMemoryError(), "should be out of memory error");
    k_h = instanceKlassHandle(THREAD, k);

    int len = (StackTraceInThrowable) ? (int)PreallocatedOutOfMemoryErrorCount : 0;
    Universe::_preallocated_out_of_memory_error_array = oopFactory::new_objArray(k_h(), len, CHECK_false);    for (int i=0; i<len; i++) {
      oop err = k_h->allocate_instance(CHECK_false);
      Handle err_h = Handle(THREAD, err);
      java_lang_Throwable::allocate_backtrace(err_h, CHECK_false);
      Universe::preallocated_out_of_memory_errors()->obj_at_put(i, err_h());
    }
    Universe::_preallocated_out_of_memory_error_avail_count = (jint)len;
  }

}

上面的代码其实就是在vm启动过程中加载了OutOfMemoryError这个类，并且创建了好几个OutOfMemoryError对象，每个OutOfMemoryError对象代表了一种内存溢出的场景，比如说Java heap space不足导致的OutOfMemoryError，抑或Metaspace不足导致的OutOfMemoryError，上面的代码来源于JDK8，所以能看到metaspace的内容，如果是JDK8之前，你将看到Perm的OutOfMemoryError，不过本文metaspace不是重点，所以不展开讨论，如果大家有兴趣，可以专门写一篇文章来介绍metsapce来龙去脉，说来这个坑填起来还挺大的。

能通过agent拦截到这个类加载吗

熟悉字节码增强的人，可能会条件反射地想到是否可以拦截到这个类的加载呢，这样我们就可以做一些譬如内存溢出的监控啥的，哈哈，我要告诉你的是NO WAY，因为通过agent的方式来监听类加载过程是在vm初始化完成之后才开始的，而这个类的加载是在vm初始化过程中，因此不可能拦截到这个类的加载，于此类似的还有java.lang.Object,java.lang.Class等。

为什么要在vm启动过程中加载这个类

这个问题或许看了后面的内容你会有所体会，先卖个关子。包括为什么要预先创建这几个实例对象后面也会解释。

何时抛出OutOfMemoryError

要抛出OutOfMemoryError，那肯定是有地方需要进行内存分配，可能是heap里，也可能是metsapce里（如果是在JDK8之前的会是Perm里），不同地方的分配，其策略也不一样，简单来说就是尝试分配，实在没办法就gc，gc还是不能分配就抛出异常。

不过还是以Heap里的分配为例说一下具体的过程：

正确情况下对象创建需要分配的内存是来自于Heap的Eden区域里，当Eden内存不够用的时候，某些情况下会尝试到Old里进行分配(比如说要分配的内存很大)，如果还是没有分配成功，于是会触发一次ygc的动作，而ygc完成之后我们会再次尝试分配，如果仍不足以分配此时的内存，那会接着做一次full gc(不过此时的soft reference不会被强制回收)，将老生代也回收一下，接着再做一次分配，仍然不够分配那会做一次强制将soft reference也回收的full gc，如果还是不能分配，那这个时候就不得不抛出OutOfMemoryError了。这就是Heap里分配内存抛出OutOfMemoryError的具体过程了。

OutOfMemoryError对象可能会很多吗

想象有这么一种场景，我们的代码写得足够烂，并且存在内存泄漏，这意味着系统跑到一定程度之后，只要我们创建对象要分配内存的时候就会进行gc，但是gc没啥效果，进而抛出OutOfMemoryError的异常，那意味着每发生此类情况就应该创建一个OutOfMemoryError对象，并且抛出来，也就是说我们会看到一个带有堆栈的OutOfMemoryError异常被抛出，那事实是如此吗？如果真是如此，那为什么在VM启动的时候会创建那几个OutOfMemoryError对象呢？

抛出异常的java代码位置需要我们关心吗

这个问题或许你仔细想想就清楚了，如果没想清楚，请在这里停留一分钟仔细想想再往后面看。

抛出OutOfMemoryError异常的java方法其实只是临门一脚而已，导致内存泄漏的不一定就是这个方法，当然也不排除可能是这个方法，不过这种情况的可能性真的非常小。所以你大可不必去关心抛出这个异常的堆栈。

既然可以不关心其异常堆栈，那意味着这个异常其实没必要每次都创建一个不一样的了，因为不需要堆栈的话，其他的东西都可以完全相同，这样一来回到我们前面提到的那个问题，为什么要在vm启动过程中加载这个类，或许你已经有答案了，在vm启动过程中我们把类加载起来，并创建几个没有堆栈的对象缓存起来，只需要设置下不同的提示信息即可，当需要抛出特定类型的OutOfMemoryError异常的时候，就直接拿出缓存里的这几个对象就可以了。

所以OutOfMemoryError的对象其实并不会太多，哪怕你代码写得再烂，当然，如果你代码里要不断new OutOfMemoryError()，那我就无话可说啦。

为什么我们有时候还是可以看到有堆栈的OutOfMemoryError

如果都是用jvm启动的时候创建的那几个OutOfMemoryError对象，那不应该再出现有堆栈的OutOfMemoryError异常，但是实际上我们偶尔还是能看到有堆栈的异常，如果你细心点的话，可能会总结出一个规律，发现最多出现4次有堆栈的OutOfMemoryError异常，当4次过后，你都将看到无堆栈的OutOfMemoryError异常。

这个其实在我们上面贴的代码里也有体现，最后有一个for循环，这个循环里会创建几个OutOfMemoryError对象，如果我们将StackTraceInThrowable设置为true的话(默认就是true的)，意味着我们抛出来的异常正确情况下都将是有堆栈的，那根据PreallocatedOutOfMemoryErrorCount这个参数来决定预先创建几个OutOfMemoryError异常对象，但是这个参数除非在debug版本下可以被设置之外，正常release出来的版本其实是无法设置这个参数的，它会是一个常量，值为4，因此在jvm启动的时候会预先创建4个OutOfMemoryError异常对象，但是这几个异常对象的堆栈，是可以动态设置的，比如说某个地方要抛出OutOfMemoryError异常了，于是先从预存的OutOfMemoryError里取出一个（其他是预存的对象还有），将此时的堆栈填上，然后抛出来，并且这个对象的使用是一次性的，也就是这个对象被抛出之后将不会再次被利用，直到预设的这几个OutOfMemoryError对象被用完了，那接下来抛出的异常都将是一开始缓存的那几个无栈的OutOfMemoryError对象。

这就是我们看到的最多出现4次有堆栈的OutOfMemoryError异常及大部分情况下都将看到没有堆栈的OutOfMemoryError对象的原因。

如何分析OutOfMemoryError异常

既然看堆栈也没什么意义，那只能从提示上入手了，我们看到这类异常，首先要确定的到底是哪块内存何种情况导致的内存溢出，比如说是Perm导致的，那抛出来的异常信息里会带有Perm的关键信息，那我们应该重点看Perm的大小，以及Perm里的内容；如果是Heap的，那我们就必须做内存Dump，然后分析为什么会发生这样的情况，内存里到底存了什么对象，至于内存分析的最佳的分析工具自然是MAT啦，不了解的请google之。