自研Java协程在腾讯的生产实践

自研Java协程在腾讯的生产实践本文是今年QCon java专场《Java协程在腾讯的生产实践》主题分享,分享团队为腾讯大数据JVM团队。

图片

导读 / Introduction

本文是今年QCon java专场《Java协程在腾讯的生产实践》主题分享,分享团队为腾讯大数据JVM团队。本文主要介绍协程的产生背景、java协程的发展历程、社区官方协程Project Loom的设计与实现,以及腾讯自研协程Kona Fiber的产生背景、设计与实现、性能测试和业务实践。

1. 协程产生的背景

1.1 线程模型

最经典的编程模型是线程模型,它是操作系统层面对cpu的抽象。由于线程模型是一种同步编程模型,它直观、易于理解,因此使用线程模型的开发效率高。但是对于IO密集型的程序,由于每次IO操作都需要Blocking当前线程,因此会产生一次线程切换,线程切换需要在用户态和内核态之间切换,且线程切换需要保存当前线程的执行上下文,一次线程切换的开销在10微秒量级。因此,对于IO密集型程序,cpu很大一部分都用于线程切换,导致cpu的利用率不高。

线程模型的第二个问题是,对于IO密集且高并发的程序,如果不采用异步编程模型,通常是一个线程对应一个并发(因为假设一个线程去做数据库访问操作,线程就被阻塞了,就不能执行其他任务了,只能用另一个线程去执行)。因此对于高并发的程序来说,需要创建大量线程。操作系统为了兼容各种各样的编程语言、执行逻辑,因此操作系统线程预留的栈内存通常较大,一般是8M。由于线程占用的内存较大,即使不考虑cpu利用率的问题,一台机器也很难创建太多线程(只考虑线程栈的内存开销,1万个线程就需要80G内存),因此很难在不使用异步编程框架的情况下,仅靠线程模型支持IO密集型+高并发程序。

1.2 异步模型

异步编程模型是一种编程语言框架的抽象,它可以弥补线程模型对于IO密集型+高并发程序支持的短板。它通过复用一个线程,例如线程在做io操作导致阻塞之前,通过回调函数调用到另一个逻辑单元,完成类似线程切换的操作;异步模型的执行效率很高,因为相比线程切换,它直接调用了一个回调函数;但是它的开发门槛较高,需要程序员自己理解哪里可能产生io操作,哪里需要调用回调函数,如何定期检查io操作是否做完;另外,由于线程的调用栈由一些逻辑上并不相关的模块组成,因此一旦出现crash之类的问题,调用栈比较难以理解,维护成本也较高。

1.3 协程

图1.1展示了线程模型和异步模型在生产效率和执行效率的对比图。可以看到,线程模型的生产效率是最高的,同时它对于IO密集型+高并发程序的执行效率较差。异步模型正好相反,它的生产效率较差,但是如果实现的很完美,它的执行效率是最高的。

协程的出现,是为了平衡线程模型和异步模型的生产效率和执行效率;首先,协程可以让程序员按照线程模型去编写同步代码,同时,尽可能降低线程切换的开销。

图片

图1.1

2. Java协程的发展历程

上面分析了协程产生的背景,那么Java协程的现状是怎样的呢?

首先,由于Java生态丰富的异步框架,缓解了协程的紧迫性,用户可以用异步框架去解决IO密集型+高并发的程序。

如图2.1所示,列出了Java协程的发展历程。

图片

图2.1

2.1 JKU

Java协程最早是JKU发表的论文+提供的patch。JKU的协程是一种有栈的协程,即每个协程都有自己独立的调用栈。不同于操作系统线程,由于JKU的协程只需要考虑java代码的执行,根据java代码执行时的特点,通常只需要较小的栈就可以满足需要,通常JKU的协程只需要不超过256K的栈。

2.2 Quasar/Kotlin

Quasar和Kotlin是之后出现的方案,它们都不需要修改java虚拟机,只需要修改上层java代码。它们都是无栈协程,所谓无栈协程,是指协程在suspend状态时不需要保存调用栈。那么如果协程切换出去以后,没有保存调用栈,下次恢复执行时,如何读取调用关系呢?Quasar和Kotlin在切换时,会回溯当前协程的调用栈,然后根据这个调用栈生成一个状态机,下次恢复执行时,根据这个状态机恢复执行状态;无栈协程通常不能在任意点切换,只能在被标记的函数切换,因为只有被标记的函数才能生成对应的状态机,Quasar需要加一个@Suspendable的annotation标记可以切换的函数,Kotlin需要在函数定义时加上suspend关键字标记可以切换的函数。

2.3 Project Loom

Project Loom是Openjdk社区推出的官方协程实现,它从立项到今天已经超过3.5年,目前已经包含27个Committer,超过180个author,3200+commits。

图2.1列出了Loom一些重要的时间点。Loom在17年底立项,18年初正式对外推出。19年7月,它发布了第一个EA(Early Access)Build,这时候它的实现还是一个Fiber类。在19年10月的时候,它的接口发生了一个较大的变动,将Fiber类去掉,新增了VirtualThread类,作为Thread类的子类,兼容所有Thread的操作。这时候它的基本思想已经比较清晰了,就是协程是线程的一个子类,支持线程的所有操作,用户可以完全按照线程的方式使用协程。

Loom作为Openjdk的官方实现,它的目标是提供一个Java协程的系统解决方案,兼容已有Java规范、JVM特性(例如ZGC、jvmti、jfr等),最终目标是对整个Java生态的全面兼容。对Java生态的全面兼容既是Loom的优势,同时也是它的挑战。因为Java已经发展了20多年,Loom要在最底层新加入一个协程的概念,需要适配的东西非常多,例如庞大而复杂的标准类库,大量JVM特性。所以,截至目前,Loom仍然有非常多的事情要做,目前还没有达到一个真正可用的状态,图2.1最右边的部分是我们的一个推测,我们猜测到jdk18或jdk19的时候,Loom或许可以加上一个Experimental标记,提供给用户使用。

3. Loom的实现架构

图3.1列出了Loom引入的一些新的概念,其中最重要的概念就是Virtual Thread,也就是协程。Loom的官方表述为:“Virtual threads are just threads that are scheduled by the Java virtual machine rather than the operating system”。站在用户的角度,可以把协程理解为线程,按照线程的方式使用,这也是Loom最重要的设计。

图片

图3.1

除了Virtual Thread以外,Loom还新增了Scope Variable和Structured Concurrency的概念,后文会对它们分别进行介绍。

3.1 Loom的基本原理

如图3.2所示,展示了一个协程的生命周期。最初,执行VirtualThread.start()方法创建一个协程,等待被调度;当协程被调度执行以后,开始执行用户指定的业务代码,在执行代码的过程中可能会去访问数据库/访问网络,这些IO操作最后都会调用到底层的一个Park操作。Park可以理解为协程让出执行权限,且当前不能被调度执行。IO结束后会调用Unpark,Unpark之后协程可以被调度执行。在Park操作时,需要执行一个freeze操作,这个操作主要是将当前协程的执行状态,也就是调用栈保存起来。当协程Unpark且被调度时,会执行一个thaw操作,它是freeze的对称操作,主要是把之前freeze保存的调用栈恢复到执行线程上。

图片

图3.2

图3.3展示了freeze和thaw具体完成的内容。首先看freeze操作,调用栈的上半部分从ForkJoinWorkerThread.run到Continuation.enterSpecial都是类库里面的调用。从A开始才是用户的业务代码,假设用户调用了函数A,函数A又调用了函数B,函数B又调用了函数C,之后函数C有一个数据库访问操作,导致协程让出执行权限(执行了一个yield操作),接下来调用到freeze保存当前协程的执行状态(调用栈);这时会首先产生一个stack walk的动作,Loom会从当前调用栈的最底层逐步向上遍历,一直遍历到Continuation.enterSpecial为止。将所有遍历到的栈中的oop都保存一个refStack中,这样做可以保证协程的栈在GC时不作为root。

通常,thread的栈都会被GC当作root来处理,且处理root时通常是需要stop-the-world的,如果协程的栈和线程的栈一样,也被当作root处理,那么由于协程可以支持到几百万甚至上千万的量级,这会导致stop-the-world的时间变长。因此stack walk和refStack的设计(将协程栈上的内容拷贝到一个refStack中),可以在concurrent阶段处理协程的栈,不会由于协程数量的增多影响GC的暂停时间。

图片

图3.3

另一方面,每次freeze时,Loom都会将协程当前的执行栈拷贝到java heap中,即本例中的A、B、C和yield被单独拷贝出来,这样做可以保证协程的栈的内存真正做到按需使用。

当协程被Unpark且被调度时,协程执行thaw操作。thaw主要是将之前保存在java heap里的协程栈恢复到执行栈上,Loom在这里引入了lazy copy的优化。所谓lazy copy,是指Loom通过大量的profiling,发现大部分程序在io操作以后,还会紧跟着产生又一次io。具体到当前的例子,函数C在触发一次io操作以后,很可能还会产生一次io操作,而不是执行完毕返回到函数B,然后函数B也执行完毕返回到函数A。这样的话,在每次thaw的时候,就没必要把所有的调用栈都拷贝回去,而只需要拷贝一部分,然后在拷贝的调用栈尾部加一个return barrier,如果函数确实返回到return barrier,可以通过return barrier触发继续拷贝调用栈的动作;这样每次freeze和thaw的时候,都只需要拷贝一小部分内容,大大提升了切换性能。

在freeze和thaw的时候间隔里,有可能触发过GC导致oop被relocate。因此thaw的时候需要执行一个restore oop的动作,确保不会出现内存访问异常。

3.2 VirtualThread的使用

  • 调度器:

协程可以理解为一种用户态线程,在用户态执行时,由于不能直接访问CPU,所以只能用线程代替cpu。所以,协程需要一个用户态的调度器,调度器中包含物理线程,协程被调度器放在物理线程上执行。如果用户不指定调度器,默认调度器是ForkJoinPool,Loom针对ForkJoinPool做了很多关于协程调度的优化。

  • 直接创建VirtualThread:

    Thread thread = Thread.ofVirtual().start(() -> System.out.println(“Hello”)); thread.join()

相比于创建Thread,只需要增加一个ofVirtual()的函数调用,创建的就是协程。

如果用户想要自己写一个针对自己业务模型更有效的调度器,可以通过调用scheduler()函数指定调度器,代码如下所示:

Thread thread = Thread.ofVirtual().scheduler(CUSTOM_SCHEDULER).start(() -> System.out.println("Hello"));
thread.join()
  • 创建协程池

除了直接使用协程以外,还可以通过创建协程池的方式使用协程,例如创建一个包含10000个协程的协程池,将任务提交给协程池执行。对应代码如下:

ThreadFactory factory
if (UseFiber == false) {
    factory = Thread.ofPlatform().factory();
} else {
    factory = Thread.ofVirtual().factory();
}
ExecutorService e = Executors.newFixedThreadPool(ThreadCount, factory);

在创建ThreadPool时,如果传入的factory是ofPlatform()的factory,对应的就是线程池,如果是ofVirtual()的factory,对应的就是协程池。

3.3 VirtualThread Pin

Pin的状态指的是VirtualThread在freeze时无法让出Carrier Thread(协程执行时挂载的物理线程)。主要有两种情况下会导致Pin:

  • VirtualThread的调用栈包含JNI frame。因为JNI调用的实现是C++代码,可以做的事情非常多,例如它可以保存当前Carrier Thread的Thread ID,如果这时切换出去,那么下一次执行时,如果另一个Carrier Thread来执行这个协程,将会产生逻辑错误(Carrier Thread的ID不一致);

  • VirtualThread持有synchronized锁。这是java早期锁的实现带来的限制,因为java的synchronized锁的owner是当前的Carrier Thread,如果一个协程持有一把锁,但是锁的owner被认为是当前的Carrier Thread,那么如果接下来这个Carrier Thread又去执行另一个协程,可能另一个协程也被认为拥有了锁,这可能导致同步的语义发生混乱,产生各种错误。

偶尔出现的Pin并不是一个很严重的问题,只要调度器中始终有物理线程负责执行协程就可以。如果调度器中所有的物理线程都被Pin住,可能会对吞吐量产生较大影响。Loom针对默认的调度器ForkJoinPool做了优化,如果发现所有的物理线程都被Pin住,就会额外创建一些物理线程,保证协程的执行不受太大影响。用户如果想要彻底消除Pin,可以按照如图3.4的方式,通过-Djdk.tracePinnedThreads选项定位产生Pin的调用栈。

图片

图3.4

3.4 Structured Concurrency

结构化并发的设计初衷是方便管理协程的生命周期。结构化并发的基本想法是,调用一个method A,通常并不关心method A是由一个协程按部就班的执行,还是将method A划分为100个子任务,由100个协程同时执行。下面的代码是使用结构化并发的一个小例子:

ThreadFactory factory = Thread.ofVirtual().factory();
try (ExecutorService executor = Executors.newThreadExecutor(factory)) {
    executor.submit(task1);
    executor.submit(task2);
}

当前执行的协程会在try代码段结束的位置等待,直到try对应的代码段执行结束,就好像try代码段中的内容是由当前协程按部就班的执行一样。结构化并发本质上是一种语法糖,方便将一个大任务划分为多个小任务,由多个协程同时执行。有了结构化并发,很自然的会产生结构化的中断和结构化的异常处理。结构化的中断,是指try代码段的超时管理,例如用户想要try中的task1和task2在30秒内完成,如果30秒内没有完成则产生一个中断,结束执行。结构化的异常处理,是指try中的内容被划分为2个子任务,如果子任务产生异常,对于异常处理来说,可以做到和一个协程顺序执行的做法相同。

3.5 Scope Variable

Scope Variable是Loom社区增加协程以后,对原有ThreadLocal的重新思考。Scope Variable可以理解为轻量的、结构化的Thread Local。由于Thread Local是全局有效的、非结构化的数据,因此一旦修改就会覆盖掉之前的值。Scope Variable是一种结构化的Thread Local,它的作用范围仅限一个Code Blob,下面的代码是Scope Variable的一个测试用例,根据assert信息可以看出Scope Variable如果在Code Blob之外就会自动失效。

public void testRunWithBinding6() {
    ScopeLocal<String> name = ScopeLocal.inheritableForType(String.class);
    ScopeLocal.where(name, "fred", () -> {
        assertTrue(name.isBound());
        assertTrue("fred".equals(name.get()));

        ScopeLocal.where(name, "joe", () -> {
            assertTrue(name.isBound());
            assertTrue("joe".equals(name.get()));
            ensureInherited(name);
        });

        assertTrue(name.isBound());
        assertTrue("fred".equals(name.get()));
        ensureInherited(name);
    });
}

Scope Variable的另一个好处是,它可以和结构化并发巧妙结合起来。结构化并发通常会将一个大任务划分为多个子任务,如果子任务的个数非常多,例如一个大任务被划分成1000个子任务,那么如果采用Inherit Thread Local来复制父协程的Thread Local到子协程上,由于Thread Local是mutable的,所以子协程也只能拷贝父协程的Thread Local。在子协程非常多的情况下,这种拷贝开销很大。Scope Variable为了应对这种情况,仅仅在子协程上增加一个父协程的引用,而不需要额外的拷贝开销。

4. 为什么需要Kona Fiber?

通过前面的分析可以看出,Loom的设计是非常完善的,对各种情况都有充分的考虑,用户只需要等待Loom成熟以后使用Loom即可。那么,为什么腾讯还需要自研一个协程Kona Fiber呢?

我们通过和大量业务的沟通,分析出当前业务对协程的三个主要需求:

  • 在JDK8/JDK11上可用:当前大量业务还是基于JDK8/JDK11进行开发的,而Loom作为Openjdk社区的前沿特性,基于社区的最前沿版本进行开发,让很多还在使用旧版本JDK的业务无法使用;

  • 代码的可演进性:用户希望基于JDK8/JDK11修改的协程代码,未来升级到社区最新版本的时候,能够在不修改代码的情况,切换到社区官方的协程Loom;

  • 切换性能的需求:当前Loom的实现,由于有stack walk和stack copy的操作,导致切换效率还有一定提升空间,用户希望有更好的切换效率。

基于这三点需求,我们设计并实现了Kona Fiber。

5. Kona Fiber的实现

5.1 Kona Fiber与Loom的异同

图5.1展示了Kona Fiber和Loom的共性以及差异点,中间黄色的部分是Kona Fiber和Loom都支持的,两边的蓝色部分是Kona Fiber和Loom的差异点。

图片

图5.1

首先看共性的部分:

  • Loom最重要的设计是VirtualThread,对于Virtual Thread的接口,KonaFiber是全部支持的,用户可以用相同的一套接口使用Loom和Kona Fiber。

  • Loom针对ForkJoinPool做了很多优化,包括前面提到的自动扩展Carrier Thread,Kona Fiber也对这一部分优化进行了移植和适配。

  • 对于Test Case,由于Kona Fiber的接口与Loom接口的一致性,理想情况下可以不加任何修改,直接运行Loom的Test Case。当然,实际运行Loom的Test Case时,仍然需要少量修改,这些修改主要是由于大版本的差异。因为Loom是基于最新版本(jdk18),而Kona Fiber是基于jdk8,如果Loom的Test Case包含了jdk8不支持的特性,例如jdk8不支持var的变量定义,那么仍需要少量的适配。当前,Loom的大部分Test Case我们已经移植到了Kona Fiber,对应的文件目录(相对于jdk的根目录)为jdk/test/java/lang/VirtualThread/loom。

对于差异的部分,首先是性能方面,由于Kona Fiber是stackful的方案,在切换性能上会优于Loom,在内存开销上也会比Loom多一些,这部分的详细数据会在下一章进行介绍。其次,由于Loom引入了一些新的概念,这些概念虽然可以让程序员更好的使用协程,但是这些概念的成熟以及被程序员广泛接受,都需要一定的时间。未来如果用户对Scope Variable、Structure Concurrency有共性需求,Kona Fiber也会虑引入这些概念,目前还是以开箱即用为目标,暂不支持这些新特性。

5.2 Kona Fiber的实现架构

如图5.2所示,展示了一个Kona Fiber协程的生命周期。

图片

图5.2

第一个步骤和第二个步骤与Loom相同,即协程被创建、协程被调度执行。当协程真正被调度执行时,才会在runtime创建协程的数据结构以及协程的栈。创建成功以后,返回到java层执行用户代码。接下来如果在用户代码中遇到IO操作(例如数据库访问),会导致协程被Park,因此会进入到runtime,这时在runtime会执行一个stack switch的过程,切换到另一个协程执行。IO结束时(例如数据库访问完成),会唤醒协程继续执行。

图片

图5.3

如图5.3所示,展示了Kona Fiber在stack switch时的具体实现。协程可以理解为用户态的线程,又因为Kona Fiber的每个协程都有一个独立的栈,所以协程切换本质上只需要切换rsp和rbp指针即可。因为,Kona Fiber的切换开销相比于Loom的stack walk和stack copy要小一些,在理论上会有一个更好的性能。接下来会有详细的数据对Kona Fiber和Loom进行比较。

6. Kona Fiber的性能数据

图6.1展示了Kona Fiber、Loom和JKU的切换性能数据,横轴代表协程个数,纵轴表示每秒切换的次数。

图片

图6.1

可以看到,Kona Fiber的性能优于Loom,且当协程个数较多时,JKU的性能也好于Loom。前文叙述过,由于Loom在切换时需要做stack copy和stack walk,所以导致切换性能会差一点。

图片

图6.2

图6.2展示了Kona Fiber、Loom和JKU在创建30000个协程时的内存开销,无论是runtime直接使用的物理内存,还是JavaHeap的内存使用,Loom都是最优的(占用内存最少),当然这也得益于Loom的stack copy的实现,可以做到对内存真正的按需使用。由于Kona Fiber兼容了Loom Pin的概念,因此相比JKU去掉了很多不需要的数据结构,在内存使用上优于JKU。从内存使用总量上,虽然Kona Fiber占用的内存多于Loom,但是30000个协程总体占用不到1G内存(runtime占用的内存加上Java Heap占用的内存),对于大多数业务也是可接受的。

图片

图6.3

图片

图6.4

图6.3、图6.4分别展示了Kona Fiber和Loom在使用默认调度器ForkJoinPool时的调度性能。其中横轴表示调度器中Carrier Thread的个数,纵轴表示调度器每秒完成切换操作的次数,不同颜色的线代表不同个数的协程。可以看到,Loom在协程个数较多时,性能抖动较明显。Kona Fiber在不同协程个数的情况下,性能表现都很稳定。这种差异的产生,可能还是与Loom在切换时要做stack walk和stack copy有关。

注:

1. 所有关于Loom的性能数据,都是基于2020年9月Loom的代码。

2. 所有的性能测试用例都可以在开源代码中获取,对应的目录(相对于jdk的根目录)为demo/fiber

7. Kona Fiber的业务落地

7.1 业务协程化改造

如果一个业务想要从线程切换到协程,通常需要以下三个步骤:

1.将创建线程改为创建协程;将线程池改为协程池。第一步非常简单,只需要将线程的使用替换为协程的使用(按照3.2小节“Virtual Thread的使用”进行替换即可)

2.将部分同步接口替换为异步框架。当前Kona Fiber仍有一些接口不支持,例如Socket、JDBC相关的接口。使用这些接口,将导致协程不能正常切换(Blocking在native代码或者Pin住),协程会退化成线程,那么协程的优势也就不存在了。目前Kona Fiber对网络和数据库的一些原生接口不支持,好在一般网络和数据库操作都可以找到对应的异步框架,例如网络操作有Netty,数据库有异步的redis。图7.1以替换Netty为例,介绍了如何利用异步框架有效的使用协程。首先,创建一个CompletableFuture,然后将任务提交给Netty,接下来当前协程调用Future.get()等待Netty执行完成。在Netty执行完成的回调函数里调用Future.complete(),这样协程就可以恢复执行。

图片

图7.1

3. 协程性能优化:Pin的解决。3.3小节介绍过Pin,Pin虽然不会导致整个系统死锁,但是频繁的Pin仍然会显著降低业务的吞吐量。对于Pin的解决,主要是两个方面,即产生Pin的两个原因:synchronized锁和native frame。第一步,在调试阶段开启-Djdk.tracePinnedThreads,这样可以找到所有引起Pin的调用栈。如果Pin是由于业务代码使用synchronized锁引起的,那么只需要将synchronized锁替换成ReentrantLock即可;如果Pin是由于包含native frame或者第三方代码包含synchronized锁引起的,那么只能通过将任务提交到一个独立线程池的方法来解决,这样可以保证协程的执行不受影响。

7.2 企点开放平台-统一推送服务

企点开放平台-统一推送服务是腾讯公司的业务,天然存在高并发的需求。最初业务方尝试使用WebFlux响应式编程,但由于业务方存在较多第三方外包人员,且WebFlux的开发、维护难度较高,导致业务方放弃使用WebFlux。后来,在了解了腾讯内部自研的Kona Fiber后,业务方果断选择尝试切换Kona Fiber。

业务方针对Kona Fiber的适配,主要是通过nio+Future替换bio,将所有阻塞操作替换为nio,当阻塞操作完成时执行Future.complete()唤醒协程;业务方反馈的替换协程的工作量为:三人天、200+行的代码适配、测试工作。最终相比Servlet的线程方案,系统整体吞吐量提升了60%。

下面的代码是业务方修改的代码片段,分别表示创建一个协程池,以及通过加一个annotation让函数运行在协程池上:

@Bean(name = "asyncExecutor")
public Executor asyncExecutor() {
  ThreadFactory threadFactory = Thread.ofVirtual().factory();
  return Executors.newFixedThreadPool(fiberCount, threadFactory);
}


@Async("asyncExecutor")
public CompletableFuture<ResponseEntity<ResponseDTO>> direct() {
  ···
}

7.3 SLG游戏后台服务

SLG(Simulation Game)游戏主要是一些策略类游戏,这类游戏不像一些对战类游戏对实时性要求非常高。策略类游戏的特点是逻辑复杂,且游戏业务通常都有高并发、高性能需求。业务方基于Kona Fiber定制了一种单并发的协程调度器。

如图7.2所示,多个协程只运行在一个playerService Thread上,由于Carrier Thread只有一个线程,因此同一时刻只有一个运行在playerService Thread的协程可以执行;这样做可以省去很多同步操作,提高开发者的编程效率。替换了Kona Fiber以后,系统的整体吞吐量也相比线程方案提高了35%。

图片

图7.2

右侧的battleService Thread存在访问数据库请求,业务方使用的是腾讯自研的Tcaplus数据库,为了避免协程退化成线程,业务方将数据库操作提交到一个独立的线程池来执行。

7.4 trpc-java

trpc是腾讯公司自研的高性能、新老框架易互通、便于业务测试的RPC框架。一些使用trpc-java的用户对高并发+IO密集型程序有需求。在协程出现以前,他们都只能通过trpc-java提供的异步框架解决性能问题。异步框架虽然可以解决高并发+IO密集型程序的性能问题,但是由于它对开发者要求较高,很多时候用户一不小心就会将异步代码写成同步代码,导致性能下降。

当前,trpc-java已经结合Kona Fiber推出了trpc-java协程版本,用户可以按照编写同步代码的方式,获得异步代码的性能。目前已有大数据特征中台业务、trpc-网关业务正在适配协程。

8. Future Plan

  1. Kona Fiber在Kona8上的源码github链接:

    github.com/Tencent/Ten…

  2. Kona Fiber在Kona11上的源码github链接:

    github.com/Tencent/Ten…

  3. 持续跟进Loom社区,将Loom的优化移植到Kona Fiber。

参考文献

  1. Getting started – Getting started – OpenJDK Wiki

  2. Troubleshooting – Troubleshooting – OpenJDK Wiki

  3. State of Loom: Part 2

传送门

Kona 8对外开源版本,欢迎star:

GitHub – Tencent/TencentKona-8: Tencent Kona is a no-cost, production-ready distribution of the Open Java Development Kit (OpenJDK), Long-term support(LTS) with quarterly updates. Tencent Kona serves as the default JDK internally at Tencent Cloud for cloud computing and other Java applications.

Kona11对外开源版本,欢迎star:

GitHub – Tencent/TencentKona-11: Tencent Kona JDK11 is a no-cost, production-ready distribution of the Open Java Development Kit (OpenJDK), Long-Term Support(LTS) with quarterly updates. Tencent Kona JDK11 is certified as compatible with the Java SE standard.

– 标题图来源:Pexels –

今天的文章自研Java协程在腾讯的生产实践分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/15692.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注