前言

在2022年9月20日Java19发布啦，再次新增了几个特性，其中最吸引我的就是virtual Thread虚拟线程了，官方提供了虚拟线程的预览，这是Project Loom 的主要成果。

虚拟线程是为了提高Java并发变成的可扩展性，是一种轻量级线程。它并不是为了替代原先的Thread线程，而是一种扩展，类似于Go语言中的协程，可以避免线程的上下文切换所带来的额外消耗。

在原先的线程模型中，每个Java线程都对应一个操作系统的线程，但virtual Thread则可以将多个虚拟线程对应到一个操作系统线程上去。

前言

最近，当我将开发完的新项目接口丢给前端仔去调用，正准备去摸鱼时，我的前端同事突然告诉我，我跨域配置没打开。我说这怎么可能，我这可是祖传代码，该配置的响应头都配置了，例如下面的代码demo

1
2
3

resp.setHeader("Access-Control-Allow-Methods","*");
resp.setHeader("Access-Control-Allow-Origin", "*");            
resp.setHeader("Access-Control-Allow-Credentials", "true");

我说你不要诈我，但很快我就看到了一张图，啥时候cookie多了个SameSite字段？我说别慌！待我研究一下这是啥

前言

最近遇到了一个需求：后台根据存储数据生成一个PDF报表，里面还会有各种分析图表，经过技术调研后，大体技术栈如下

1. 使用poi-tl来作为报表模板，生成word文档
2. 使用jfreechart来进行各种分析图表生成
3. 随后将生成word文档转换为PDF即可

开放思路理清后，下面就来了解一下怎么编码把~

前言

在Go的各种框架中，总是能看见context的身影，它被用来进行数据传递、超时通知等。

context在Golang1.7的版本被引入，它被称为协程的上下文，用来在各个协程之间进行上下文信息传递，例如：取消信号、超时信号、数据传递等。这种传递不仅只传送给被调用者、context能够进行链式的调用。

线程不安全的map

总所周知，Go中内置容器Map是线程不安全的，当有多个协程同时进行操作，会抛出fatal error: concurrent map writes的错误，例如下面的例子

1
2
3
4
5
6
7
8

func testMap() {
	m := make(map[string]int)
	for i := 0; i < 100; i++ {
		go func(num int) {
			m[fmt.Sprintf("%d", num)] = num
		}(i)
	}
}

因此如果我们有多个协程同时操作map的需求，就不能直接使用map啦。通常我们可以通过加读写锁（sync.RWMutex）或者使用sync.Map来保证线程安全。

前言

Go跟Java一样都是自动垃圾回收、简称GC，即在后台运行一个守护线程，监控各个对象的状态，识别并且释放不在使用的对象的内存空间。

目前Go使用的垃圾回收策略是三色标记法+混合写屏障，下面就来学习一下GC的细节把。

GMP模型

• G：即goroutine协程，每个Go关键字都会创建一个协程，协程在当创建的时候大约只占2MB，在不断的运行中可以按需增大（最大1GB）和缩小。
• M：即操作系统线程，Go中默认最多创建10000线程，同时每个Go协程都需要M上才能运行。
• P：即调度器，负责将协程调度到线程上，默认数量为CPU核心数，每一个M都与一个P对应。

前言

Go中channel是一个核心类型，用于协程直接的通信以实现并发通信。

Go中对于并发编程有个核心思想：不要通过共享内存来通信，而是通过通信来共享内存，channel即是这一思想的实现。