您现在的位置是：首页 >技术教程 >Go GPM 调度器介绍网站首页技术教程

Go GPM 调度器介绍

Michaelwubo 2024-07-09 10:33:18
简介Go GPM 调度器介绍

Go GPM 调度器介绍
1 简介
​ 这几天在学习Go的GPM机制，于是就整理了一下收集的资料分享给大家，文章末尾有原文链接。主要介绍了Go在运行时调度器的基本实现逻辑和演变过程。
​

2 什么是Go调度器
​ Go调度器很轻量也很简单，足以撑起goroutine的调度工作，并且让Go具有了原生（强大）并发的能力。Go调度本质是把大量的goroutine分配到少量线程上去执行，并利用多核并行，实现更强大的并发。

2.1 单进程时代
​ 众所周知，软件是运行在操作系统之上，用来做计算运算的实际是CPU来完成的。但是CPU是无法区分进程和线程的，同一时刻只能执行同一进程，直到一个进程执行完成后才能进入到下一个进程，这就是单进程时代,一切程序只能串行发生。

 

​ 这样的运行就会带来两个问题：

  • 单一的执行流程决定了计算机只能一个任务一个任务的去处理。
  • 进程阻塞所带来的CPU时间的浪费。

​ 所以我们操作系统需要具备多线程并发能力来解决这两个问题。即当一个进程阻塞时，CPU可以切换到另外等待执行的进程上去，这样就能够把CPU利用起来，降低CPU的浪费。

2.2 多进程/线程时代

​ 在多进程/多线程的操作系统中就解决了阻塞的问题。当一个进程阻塞CPU的时候，可以立刻切换到其他进程上去执行。

 

在这个过程中我们就需要引入一种调度机制，通过调度CPU的算法来保证运行的进程都可以被分配到CPU的运行时间片上。从整体上看，它们就是多个进程在同时被运行。

​ 这样虽然解决CPU浪费问题，但是又带来了新的问题：进程拥有太多的资源，进程的创建、切换、销毁都会占用很长的时间。所以CPU虽然利用起来了，但是当进程过多的时候，CPU的很大一部分时间都被用来进行进程调度

2.3 协程提高CPU利用率

​ 在Linux操作系统中来说，CPU对进程和线程的态度是一样的。

 

所以无论是CPU调度切换的是进程还是线程，都会带来损耗。并且线程看起来很美好，在实际开发过程中，多线程开发也要考虑很多同步竞争问题，例如锁、竞争冲突等问题。

​ 实际上，多进程和多线程已经提高了系统的并发能力。但是在高并发的场景下，为每个任务都创建一个线程显然是不现实的，因为会消耗大量的内存，并且在调度时也有比较大的额外开销。每个线程都会占用1M以上的内存空间。

​ 这样在需要大量的进程/线程的业务场景下，又产生了两个问题：

高内存占用
调度时的高CPU消耗
​ 为了解决这个问题，我们要清楚线程是什么。线程是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。在Unix System V中也被称为轻量进程（lightweight processes），但轻量进程更多指内核线程（kernel thread），而把用户线程（user thread）称为线程。所以简单来说线程可以分为两个，一个是内核态线程，一个是用户态线程。一个是用户态线程必须要绑定一个内核态线程，但是CPU并不知道这个用户态线程的存在，它只知道它运行的是一个内核态线程(Linux的PCB进程控制块)。

 

​ 这样我们就再引入一个新的概念协程。

  • 协程（Coroutines）是一种比线程更加轻量级的存在，正如一个进程可以拥有多个线程一样，一个线程可以拥有多个协程。
  • 协程不是被操作系统内核所管理的，而是完全由程序所控制，也就是在用户态执行。这样带来的好处是性能大幅度的提升，因为不会像线程切换那样消耗资源。
  • 协程不是进程也不是线程，而是一个特殊的函数或任务，这个函数可以在某个地方挂起，并且可以重新在挂起处外继续运行。所以说，协程与进程、线程相比并不是一个维度的概念。
  • 一个线程内可以由多个这样的特殊函数在运行，但是有一点必须明确的是，一个线程的多个协程的运行是串行的。如果是多核CPU，多个进程或一个进程内的多个线程是可以并行运行的，但是一个线程内协程却绝对是串行的，无论CPU有多少个核。毕竟协程虽然是一个特殊的函数，但仍然是一个函数。一个线程内可以运行多个函数，但这些函数都是串行运行的。当一个协程运行时，其它协程必须挂起。
     

引入协程以后我们再去细化下分类，内核态线程依然叫线程，用户态线程我们抽象成协程。

 这时基于协程的特点，我们就可以想像，既然一个协程(co-routine)可以绑定一个线程(thread)，那么能不能多个协程(co-routine)绑定一个或者多个线程(thread)上呢？

2.3.1 协程和线程的映射关系

​ 基于上面的问题，我们就有了三种协程和线程之间的映射关系：

N:1关系

N个协程绑定1个线程，优点就是协程在用户态线程即完成切换，不会陷入到内核态，这种切换非常的轻量快速。但也有很大的缺点，1个进程的所有协程都绑定在1个线程上

缺点：

  • 某个程序用不了硬件的多核加速能力
  • 一旦某协程阻塞，造成线程阻塞，本进程的其他协程都无法执行了，根本就没有并发的能力了。

 

  • 1:1关系

    1个协程绑定1个线程，这种最容易实现。协程的调度都由CPU完成了，不存在N:1缺点，

    缺点：

    • 协程的创建、删除和切换的代价都由CPU完成，有点略显昂贵了。

 

 

  • M:N关系

    M个协程绑定1个线程，是N:1和1:1类型的结合，克服了以上2种模型的缺点，但实现起来最为复杂。

 

2.3.2 Go语言的协程goroutine
​ Go为了提供更容易使用的并发方法，使用了goroutine和channel。goroutine来自协程的概念，让一组可复用的函数运行在一组线程之上，即使有协程阻塞，该线程的其他协程也可以被runtime调度，转移到其他可运行的线程上。最关键的是，程序员看不到这些底层的细节，这就降低了编程的难度，提供了更容易的并发

​ Go中，协程被称为goroutine，它非常轻量，一个goroutine只占几KB，并且这几KB就足够goroutine运行完，这就能在有限的内存空间内支持大量goroutine，支持了更多的并发。虽然一个goroutine的栈只占几KB，但实际是可伸缩的，如果需要更多内容，runtime会自动为goroutine分配。

​ 在切换线程时，恢复寄存器中的内容需要向操作系统申请或者销毁资源，每一次线程上下文的切换都需要消耗 0~1us 左右的时间，但是 Go 调度器对 Goroutine 的上下文切换约为0 ~0.2us，减少了 80% 的额外开销。

Goroutine特点：

  • 占用内存更小（几kb）
  • 调度更灵活(runtime调度)

2.4 Go调度器

今天的 Go 语言调度器有着优异的性能，但是如果我们回头看 Go 语言的 0.x 版本的调度器会发现最初的调度器不仅实现非常简陋，也无法支撑高并发的服务。调度器经过几个大版本的迭代才有今天的优异性能，历史上几个不同版本的调度器引入了不同的改进，也存在着不同的缺陷:

  • 单线程调度器 0.x

                1.只包含 40 多行代码；

                2.程序中只能存在一个活跃线程，由 G-M 模型组成；

  •    多线程调度器 1.0

                1.允许运行多线程的程序；

                2. 全局锁导致竞争严重；

  • 任务窃取调度器 1.1

                1.引入了处理器 P，构成了目前的 G-M-P 模型；

                2.在处理器 P 的基础上实现了基于工作窃取的调度器；

                3.在某些情况下，Goroutine 不会让出线程，进而造成饥饿问题；

                4.时间过长的垃圾回收（Stop-the-world，STW）会导致程序长时间无法工作；

  • 抢占式调度器 1.2~ 至今

                1.基于协作的抢占式调度器 1.2 ~ 1.13
                        1.1通过编译器在函数调用时插入抢占检查指令，在函数调用时检查当前 Goroutine 是否发起了抢占请求，实现基于协作的抢占式调度；
                        1.2Goroutine 可能会因为垃圾回收和循环长时间占用资源导致程序暂停；
                2.基于信号的抢占式调度器 - 1.14 ~ 至今
                        2.1实现基于信号的真抢占式调度；
                        2.2垃圾回收在扫描栈时会触发抢占调度；
                        2.3抢占的时间点不够多，还不能覆盖全部的边缘情况；

  • 非均匀存储访问调度器 · 提案

                1.对运行时的各种资源进行分区；
                2.实现非常复杂，到今天还没有提上日程

2.4.1 单线程调度器/多线程调度器
​         单线程调度器只包含表示 Goroutine 的 G 和表示线程的 M 两种结构，全局也只有一个线程。唯一优点就是能运行，但是这次提交已经包含了 G 和 M 两个重要的数据结构，也建立了 Go 语言调度器的框架。

​         多线程调度器与上一个版本几乎不可用的调度器相比，Go 语言团队在这一阶段实现了从不可用到可用的跨越。我们可以在 pkg/runtime/proc.c 文件中找到 1.0.1 版本的调度器，多线程版本的调度函数runtime.schedule:go1.0.1 包含 70 多行代码。整体的逻辑与单线程调度器没有太多区别，因为我们的程序中可能同时存在多个活跃线程，所以多线程调度器引入了 GOMAXPROCS 变量帮助我们灵活控制程序中的最大处理器数，即活跃线程数。

​ 那么我们先来分析一下被废弃的调度器是如何运作的。

 下面我们来看看被废弃的golang调度器是如何实现的。

 ​ M想要执行、放回G都必须访问全局G队列，并且M有多个，即多线程访问同一资源需要加锁进行保证互斥/同步，所以全局G队列是有互斥锁进行保护的。

老调度器有几个缺点：

  1. 创建、销毁、调度G都需要每个M获取锁，这就形成了激烈的锁竞争。
  2. M转移G会造成延迟和额外的系统负载。比如当G中包含创建新协程的时候，M创建了G’，为了继续执行G，需要把G’交给M’执行，也造成了很差的局部性，因为G’和G是相关的，最好放在M上执行，而不是其他M’。
  3. 系统调用(CPU在M之间的切换)导致频繁的线程阻塞和取消阻塞操作增加了系统开销。
     

2.4.2 任务窃取调度器

​ 2012 年 Google 的工程师 Dmitry Vyukov 在 Scalable Go Scheduler Design Doc 中指出了现有多线程调度器的问题并在多线程调度器上提出了两个改进的手段：

  • 在当前的 G-M 模型中引入了处理器 P，增加中间层；

  • 在处理器 P 的基础上实现基于工作窃取的调度器；

 

 Processor，它包含了运行goroutine的资源，如果线程M想运行goroutine，必须先获取P，P中还包含了可运行的G队列。

​ 基于任务窃取的 Go 语言调度器使用了沿用至今的 G-M-P 模型，我们能在 runtime: improved scheduler 提交中找到任务窃取调度器刚被实现时的源代码，调度器的 runtime.schedule:779c45a 在这个版本的调度器中反而更简单了。

2.4.3 GMP模型

  • G — 表示 Goroutine，它是一个待执行的任务；
  • M — 表示操作系统的线程，它由操作系统的调度器调度和管理；
  • P — 表示处理器，它可以被看做运行在线程上的本地调度器；

在Go中，线程是运行goroutine的实体，调度器的功能是把可运行的goroutine分配到工作线程上。

 

  • 全局队列（Global Queue）：存放等待运行的G。
  • P的本地队列：同全局队列类似，存放的也是等待运行的G，存的数量有限，不超过256个。新建G’时，G’优先加入到P的本地队列，如果队列满了，则会把本地队列中一半的G移动到全局队列。
  • P列表：所有的P都在程序启动时创建，并保存在数组中，最多有GOMAXPROCS(可配置)个。
  • M：线程想运行任务就得获取P，从P的本地队列获取G，P队列为空时，M也会尝试从全局队列拿一批G放到P的本地队列，或从其他P的本地队列偷一半放到自己P的本地队列。M运行G，G执行之后，M会从P获取下一个G，不断重复下去。
     

Goroutine调度器和OS调度器是通过M结合起来的，每个M都代表了1个内核线程，OS调度器负责把内核线程分配到CPU的核上执行。

​ 我们知道了GPM模型的框架，自然就需要知道这个模型里面的G、P、M相关信息。

  • P的数量：由启动时环境变量$GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定。这意味着在程序执行的任意时刻都只有$GOMAXPROCS个goroutine在同时运行。
  • M的数量：
  1. go程序启动时，会设置M的最大数量，默认10000，但是内核很难支持这么多的线程数，所以这个限制可以忽略。
  2. runtime/debug中的SetMaxThreads函数，设置M的最大数量。
  3. 一个M阻塞了，会创建新的M。

​ M与P的数量没有绝对关系，一个M阻塞，P就会去创建或者切换另一个M，所以，即使P的默认数量是1，也有可能会创建很多个M出来。

  • P的创建：在确定了P的最大数量n后，运行时系统会根据这个数量创建n个P。
  • M的创建：没有足够的M来关联P并运行其中的可运行的G。比如所有的M此时都阻塞住了，而P中还有很多就绪任务，就会去寻找空闲的M，而没有空闲的，就会去创建新的M。

2.4.5 M
​ Go 语言并发模型中的 M 是操作系统线程。调度器最多可以创建 10000 个线程，但是其中大多数的线程都不会执行用户代码（可能陷入系统调用），最多只会有 GOMAXPROCS 个活跃线程能够正常运行。

​ 在默认情况下，运行时会将 GOMAXPROCS 设置成当前机器的核数，我们也可以在程序中使用 runtime.GOMAXPROCS 来改变最大的活跃线程数。

 在默认情况下，一个四核机器会创建四个活跃的操作系统线程，每一个线程都对应一个运行时中的 runtime.m 结构体。

在大多数情况下，我们都会使用 Go 的默认设置，也就是线程数等于 CPU 数，默认的设置不会频繁触发操作系统的线程调度和上下文切换，所有的调度都会发生在用户态，由 Go 语言调度器(G-P-M中的P)触发，能够减少很多额外开销。

2.4.6 P

调度器中的处理器 P 是线程和 Goroutine 的中间层，它能提供线程需要的上下文环境，也会负责调度线程上的等待队列，通过处理器 P 的调度，每一个内核线程都能够执行多个 Goroutine，它能在 Goroutine 进行一些 I/O 操作时及时让出计算资源，提高线程的利用率。

​ 因为调度器在启动时就会创建 GOMAXPROCS 个处理器（P），所以 Go 语言程序的处理器数量一定会等于 GOMAXPROCS，这些处理器会绑定到不同的内核线程上。

​ runtime.p 结构体中的状态 status 字段会是以下五种中的一种：
_Pidle：处理器没有运行用户代码或者调度器，被空闲队列或者改变其状态的结构持有，运行队列为空
_Prunning：被线程 M 持有，并且正在执行用户代码或者调度器
_Psyscall：没有执行用户代码，当前线程陷入系统调用
_Pgcstop:被线程 M 持有，当前处理器由于垃圾回收被停止
_Pdead:当前处理器已经不被使用
​ 通过分析处理器 P 的状态，我们能够对处理器的工作过程有一些简单理解，例如处理器在执行用户代码时会处于 _Prunning 状态，在当前线程执行 I/O 操作时会陷入 _Psyscall 状态。

3 GO调度器的设计策略

  • 复用线程：避免频繁的创建、销毁线程，而是对线程的复用。
  1. work stealing机制:​ 当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程。
  2. hand off机制

 当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程。​ 当本线程因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行。

  • 利用并行：GOMAXPROCS设置P的数量，最多有GOMAXPROCS个线程分布在多个CPU上同时运行。GOMAXPROCS也限制了并发的程度，比如GOMAXPROCS = 核数/2，则最多利用了一半的CPU核进行并行。
  • 抢占：在coroutine中要等待一个协程主动让出CPU才执行下一个协程，在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死，这就是goroutine不同于coroutine的一个地方。
  • 全局G队列：在新的调度器中依然有全局G队列，但功能已经被弱化了，当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G。
     

3.1 go func() 调度流程

 

从上图我们可以分析出几个结论：

  1. 我们通过 go func()来创建一个goroutine；
  2. 有两个存储G的队列，一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在P的本地队列中，如果P的本地队列已经满了就会保存在全局的队列中；
  3. G只能运行在M中，一个M必须持有一个P，M与P是1：1的关系。M会从P的本地队列弹出一个可执行状态的G来执行，如果P的本地队列为空，就会向其他的MP组合偷取一个可执行的G来执行；
  4. 一个M调度G执行的过程是一个循环机制；
  5. 当M执行某一个G时候如果发生了syscall或则其余阻塞操作，M会阻塞，如果当前有一些G在执行，runtime会把这个线程M从P中摘除(detach)，然后再创建一个新的操作系统的线程(如果有空闲的线程可用就复用空闲线程)来服务于这个P；
  6. 当M系统调用结束时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列。如果获取不到P，那么这个线程M变成休眠状态， 加入到空闲线程中，然后这个G会被放入全局队列中。
     

3.2 调度器的生命周期

 特殊的M0和G0：

M0

​ M0是启动程序后的编号为0的主线程，这个M对应的实例会在全局变量runtime.m0中，不需要在heap上分配，M0负责执行初始化操作和启动第一个G， 在之后M0就和其他的M一样了。

G0

​ G0是每次启动一个M都会第一个创建的gourtine，G0仅用于负责调度的G，G0不指向任何可执行的函数, 每个M都会有一个自己的G0。在调度或系统调用时会使用G0的栈空间, 全局变量的G0是M0的G0

我们来跟踪一段代码

package main

import "fmt"

func main() {
    fmt.Println("Hello world")
}

接下来我们来针对上面的代码对调度器里面的结构做一个分析。

​ 也会经历如上图所示的过程：

  1. runtime创建最初的线程m0和goroutine g0，并把2者关联。
  2. 调度器初始化：初始化m0、栈、垃圾回收，以及创建和初始化由GOMAXPROCS个P构成的P列表。
  3. 示例代码中的main函数是main.main，runtime中也有1个main函数——runtime.main，代码经过编译后，runtime.main会调用main.main，程序启动时会为runtime.main创建goroutine，称它为main goroutine，然后把main goroutine加入到P的本地队列。
  4. 启动m0，m0已经绑定了P，会从P的本地队列获取G，获取到main goroutine。
  5. G拥有栈，M根据G中的栈信息和调度信息设置运行环境
  6. M运行G
  7. G退出，再次回到M获取可运行的G，这样重复下去，直到main.main退出，runtime.main执行Defer和Panic处理，或调用runtime.exit退出程序。
     

调度器的生命周期几乎占满了一个Go程序的一生，runtime.main的goroutine执行之前都是为调度器做准备工作，runtime.main的goroutine运行，才是调度器的真正开始，直到runtime.main结束而结束。

4 Go调度器调度场景过程解析

4.1 G1创建G2

​ P拥有G1，M1获取P后开始运行G1，G1使用go func()创建了G2，为了局部性G2优先加入到P1的本地队列。

 

4.2 G1执行完毕

​ G1运行完成后(函数：goexit)，M上运行的goroutine切换为G0，G0负责调度时协程的切换（函数：schedule）。从P的本地队列取G2，从G0切换到G2，并开始运行G2(函数：execute)。实现了线程M1的复用。

 

4.3 G2开辟过多的G

​ 假设每个P的本地队列只能存4个G。G2要创建了6个G，前4个G（G3, G4, G5, G6）已经加入p1的本地队列，p1本地队列满了。

 

4.4 G2本地满再创建G7

​ G2在创建G7的时候，发现P1的本地队列已满，需要执行负载均衡(把P1中本地队列中前一半的G，还有新创建G转移到全局队列)。实现中并不一定是新的G，如果G是G2之后就执行的，会被保存在本地队列，利用某个老的G替换新G加入全局队列。

 

​ 这些G被转移到全局队列时，会被打乱顺序。所以G3,G4,G7被转移到全局队列。

4.5 G2本地未满创建G8

​ G2创建G8时，P1的本地队列未满，所以G8会被加入到P1的本地队列。

 

 

G8加入到P1点本地队列的原因还是因为P1此时在与M1绑定，而G2此时是M1在执行。所以G2创建的新的G会优先放置到自己的M绑定的P上。

4.6 唤醒休眠的M

​ 规定：在创建G时，运行的G会尝试唤醒其他空闲的P和M组合去执行。

 

​ 假定G2唤醒了M2，M2绑定了P2，并运行G0，但P2本地队列没有G，M2此时为自旋线程**（没有G但为运行状态的线程，不断寻找G）**。

4.7 被唤醒的M获取G
​ M2尝试从全局队列(简称“GQ”)取一批G放到P2的本地队列（函数：findrunnable()）。M2从全局队列取的G数量符合下面的公式：

n = min(len(GQ)/GOMAXPROCS + 1, len(GQ/2))


​ 至少从全局队列取1个G，但每次不要从全局队列移动太多的G到P本地队列，给其他P留点。这是从全局队列到P本地队列的负载均衡。

 

 假定我们场景中一共有4个P（GOMAXPROCS设置为4，那么我们允许最多就能用4个P来供M使用）。所以M2只从能从全局队列取1个G（即G3）移动P2本地队列，然后完成从G0到G3的切换，运行G3。

4.8 M2从M1偷取G
​ 假设G2一直在M1上运行，经过2轮后，M2已经把G7、G4从全局队列获取到了P2的本地队列并完成运行，全局队列和P2的本地队列都空了,如场景8图的左半部分。

 

全局队列已经没有G，那m就要执行work stealing(偷取)：从其他有G的P哪里偷取一半G过来，放到自己的P本地队列。P2从P1的本地队列尾部取一半的G，本例中一半则只有1个G8，放到P2的本地队列并执行。

4.9 自旋线程最大限制
​ G1本地队列G5、G6已经被其他M偷走并运行完成，当前M1和M2分别在运行G2和G8，M3和M4没有goroutine可以运行，M3和M4处于自旋状态，它们不断寻找goroutine。

 

​ 为什么要让m3和m4自旋？自旋本质是在运行，线程在运行却没有执行G，就变成了浪费CPU。这样既然会浪费CPU，那为什么不销毁现场，来节约CPU资源？因为创建和销毁CPU也会浪费时间，我们希望当有新goroutine创建时，立刻能有M运行它，如果销毁再新建就增加了时延，降低了效率。当然也考虑了过多的自旋线程是浪费CPU，所以系统中最多有GOMAXPROCS个自旋的线程(当前例子中的GOMAXPROCS=4，所以一共4个P)，多余的没事做线程会让他们休眠。

4.10 G发生系统调用/阻塞
​ 假定当前除了M3和M4为自旋线程，还有M5和M6为空闲的线程(没有得到P的绑定，注意我们这里最多就只能够存在4个P，所以P的数量应该永远是M>=P, 大部分都是M在抢占需要运行的P)，G8创建了G9，G8进行了阻塞的系统调用，M2和P2立即解绑，P2会执行以下判断：如果P2本地队列有G、全局队列有G或有空闲的M，P2都会立马唤醒1个M和它绑定，否则P2则会加入到空闲P列表，等待M来获取可用的p。本场景中，P2本地队列有G9，可以和其他空闲的线程M5绑定。

 

4.11 G发生系统调用/非阻塞

​ G8创建了G9，假如G8进行了非阻塞系统调用。

 

M2和P2会解绑，但M2会记住P2，然后G8和M2进入系统调用状态。当G8和M2退出系统调用时，会尝试获取P2，如果无法获取，则获取空闲的P，如果依然没有，G8会被记为可运行状态，并加入到全局队列,M2因为没有P的绑定而变成休眠状态(长时间休眠等待GC回收销毁)。

5 小结
​ Goroutine 和调度器是 Go 语言能够高效地处理任务并且最大化利用资源的基础，本节介绍了 Go 语言用于处理并发任务的 G - M - P 模型，我们不仅介绍了它们各自的数据结构以及常见状态，还通过特定场景介绍调度器的工作原理以及不同数据结构之间的协作关系，希望能够帮助理解调度器的实现和运行逻辑。

参考文档：

go调度器
Golang调度器GPM原理与调度全分析

Go GPM 调度器介绍_Roger_c0dEr的博客-CSDN博客

风语者！平时喜欢研究各种技术，目前在从事后端开发工作，热爱生活、热爱工作。

站长推荐