go
MoeYang
擅长各种leetcode暴力解法
展开
-
golang源码分析:sync.Pool 如何从读写加锁到无锁
我们知道,早期的sync.Pool,底层是通过互斥锁实现对共享队列的并发访问的,这里会存在的问题是,尽管是分段锁,高并发场景下频繁进行G的wait和runable状态调度其实开销也不算小通过互斥锁保证并发安全的sync.Pool数据结构type Pool struct { noCopy noCopy local unsafe.Pointer // local,固定大小per-P池, 实际类型为 [P]poolLocal localSize uintptr // ..原创 2020-12-14 17:48:39 · 471 阅读 · 0 评论 -
golang源码分析:channel
首先说一些结论:只有发送端可以close chan,接收端不要搞1、重复 close,产生 panic2、close一个nil,产生 panic3、写未初始化chan永远阻塞4、写close会panic5、make chan返回的是* hchan,所以chan可以随意在函数和go间传递channel 的主要结构:一个环形数组实现的队列,用于存储消息元素;两个链表实现的 goroutine 等待队列,用于存储阻塞在 recv 和 send 操作上的 goroutine;.原创 2020-12-11 16:26:20 · 548 阅读 · 1 评论 -
布隆过滤器原理及golang的快速实现
最近面临这样的场景:2亿+数据需要调用后端服务A,业务需要1min处理完成,那么A服务承载的tps达到惊人的300w......必须想办法降低tps。那么方案来了:1、把时间窗口拉长 2、降低待处理数据量。拉长时间业务肯定是接受不了的,但是按照以往的经验,这部分数据并不全部需要处理,可能仅有一半真正需要调用A服务,所以我们可以把1亿数据给过滤掉。这里我们维护一个布隆过滤器来进行数据的过滤。----------------以上都是导语----------------1. 布隆过滤器的概原创 2020-11-12 20:12:58 · 275 阅读 · 0 评论 -
golang内存逃逸分析
逃逸分析在编译阶段完成,目的是决定内存分配地址是栈还是堆:编译时通过 go build -gcflags=-m 可以查看逃逸对象1、关于堆和栈栈可以简单理解成一次函数调用内部申请到的内存,它们会随着函数的返回把内存还给系统。在栈上申请的内存 :函数返回直接释放,不会引起垃圾回收,对性能没有影响。在堆上申请的对象生命周期可以超出函数调用的作用域,需要gc进行回收。2、看几个demo1、申请临时变量不会逃逸func a() { t := make([]int, 10) //..原创 2020-12-09 18:49:00 · 448 阅读 · 1 评论 -
从“gorm建立mysql数据库连接,偶现tcp: i/o timeout问题”简单看gorm.DB源码
昨天被同事问到一个问题:go服务,gorm建立mysql数据库连接,偶现tcp: i/o timeout问题是怎么回事?说实话,我平时没怎么用过gorm,也只是简单了解它的用法。考虑到问题是连接mysql偶现tcp: i/o timeout, 第一反应是怀疑mysql的负载太高,比如连接数太高导致排队。于是看了下代码对gorm的调用代码:使用gorm建立连接的场景这里看起来没什么问题,连接池的参数也都有配上。// NewDB 连接dbfunc NewDB(dbKey st.原创 2020-12-08 11:55:51 · 4256 阅读 · 1 评论 -
golang内存对齐原理
内存对齐的现象:之前没接触过c艹的同学可以先看下面的例子:type A struct { a bool b string c bool}type B struct { a bool c bool b string}func main() { fmt.Printf("Size A:%d\n", unsafe.Sizeof(A{})) fmt.Printf("Size B:%d\n", unsafe.Sizeof(B{}))}输出结果是原创 2020-11-30 20:16:27 · 379 阅读 · 0 评论 -
从单测mock失败简单谈golang内联优化
简单说下最近遇到因为go函数内联导致的单测mock问题:假设我们现在有这样一个简单的求max函数:func max(a, b int) int { if a > b { return a } return b}然后我们使用gomonkey来mock掉这个函数(当然,这是为了演示,事实上我们mock掉的一般是rpc调用):// TestMaxfunc TestMax(t *testing.T) { // mock掉max方法 maxMock := ApplyFunc原创 2020-11-23 11:14:59 · 3542 阅读 · 0 评论 -
golang源码分析:sync.Map
先说结论:sync.Map适用于以下场景读多写少:读多写少的环境下,都是从read的map去读取,不需要加锁,而写多读少的情况下,需要加锁,其次,存在将read数据同步到dirty的操作的可能性,大量的拷贝操作会大大的降低性能 读写不同的key:sync.Map是针对key的值的原子操作,相当于加锁加载 key上,所以,多个key的读写是可以同时并发的// 封装的线程安全的maptype Map struct { // lock mu Mutex // 实际是readOnly这个结构原创 2020-11-17 17:54:10 · 170 阅读 · 0 评论