背景
最近业务上需要复用CPP编写的客户端SDK库,为了让团队主力语言Golang能够顺利接入SDK,因此使用了CGO桥接技术将C++11编写的SDK库封装成生产环境可用的Golang SDK,在翻阅了网上大部分关于cgo的中英文资料后,发现其中尤其是实现Go调用CPP库还是有非常多需要注意的细节,大部分中文资料都是以简单的C++的STL库函数封装为例点到为止,本文在前人基础之上总结了一系列封装复杂CPP库时的最佳实践的tips,希望能填补相关资料的空白。
最近业务上需要复用CPP编写的客户端SDK库,为了让团队主力语言Golang能够顺利接入SDK,因此使用了CGO桥接技术将C++11编写的SDK库封装成生产环境可用的Golang SDK,在翻阅了网上大部分关于cgo的中英文资料后,发现其中尤其是实现Go调用CPP库还是有非常多需要注意的细节,大部分中文资料都是以简单的C++的STL库函数封装为例点到为止,本文在前人基础之上总结了一系列封装复杂CPP库时的最佳实践的tips,希望能填补相关资料的空白。
Best Practices for Wrapping CPP Library with CGO
Recently, our business needed to reuse a client SDK library written in CPP. To enable our team’s primary language, Golang, to seamlessly integrate with this SDK, we used CGO bridging technology to wrap the C++11 SDK library into a production-ready Golang SDK. After reviewing most of the online resources about CGO in both Chinese and English, I found there are many important details to consider when implementing Go calls to CPP libraries. Most Chinese materials only briefly mention simple examples of wrapping C++ STL library functions. Building on previous work, this article summarizes a series of best practices for wrapping complex CPP libraries, aiming to fill the gap in related documentation.
这几天有一个 Go API service 经过定时监控发现占用的内存不断上涨,内存从初始的 70M 一直上升到超过 1G 直到吃光内存退出,基本上就可以断定是存在内存泄露的问题了,但是因为自带垃圾回收的语言出现内存泄露的情况较少,如果存在那一定是大问题,因此有了下文详细的排查过程,为日后处理此类问题积累经验。
Memory Leak Caused by Using Go STL to Query DB
Recently, a Go API service was found to have continuously increasing memory usage through regular monitoring. The memory usage rose from the initial 70MB to over 1GB until it ran out of memory and crashed. This clearly indicated a memory leak issue. Since memory leaks rarely occur in languages with built-in garbage collection, if there is one, it must be a significant problem. Therefore, the following detailed investigation process was carried out to accumulate experience for handling similar issues in the future.
一般来说每个 CPU 核有 L1 和 L2 缓存,L3是共享缓存
以缓存行为单位存储,通常是 64 字节为一行
这种利用局部性原理的缓存是数组访问比链表访问快的主要原因
在 Go 语言的世界中,类型转换基本上都是很显式的,但最近在编写 web 后台的时候需要进行 context 之间的共享传值,常常就会出现 interface{} 的转换,
最常见的做法就是进行 type assertion 来进行转换,正常来讲作为编写者我们都清楚自己数据的具体类型,然鹅,在某些中间步骤之后,我们的原始类型没有变,但是可能
会被中间类型所迷惑
最近发现到的是JSON反序列化时所做的隐式类型转换,起因是对 interface{} 的一次 assertion 报错
Go语言的并发模式是其最具特色的编程范式之一。本文总结了在Go开发中最常见的几种并发模式,包括请求-接收模式、单一状态者模式、生产-消费模式、Pipeline流水线模式等。这些模式能够帮助我们更好地组织和管理goroutine,使并发程序更加健壮和优雅。通过这些模式的学习,你将能够更好地掌握Go语言的并发特性,写出更高质量的并发代码。
Concurrency patterns are one of Go’s most distinctive programming paradigms. This article summarizes the most common concurrency patterns in Go development, including request-receiver pattern, single state holder pattern, producer-consumer pattern, Pipeline pattern, and more. These patterns help us better organize and manage goroutines, making concurrent programs more robust and elegant. By learning these patterns, you’ll be able to better master Go’s concurrency features and write higher quality concurrent code.
通过Go HTTP Client的报错看标准库https请求
在用 Go 自带的 http client 进行默认 Get 操作的时候,发现如下错误
1 | x509: certificate signed by unknown authority |
这个报错来自 crypto/x509 中关于证书签名的验证
最近在刚玩具级的 MapReduce ,其中充斥着大量的并发编程的代码,稍有不慎就可能导致 Map 或者 Reduce 的时候遭遇到未知的阻塞状态 (Blocking),导致整个系统无法按照计划
处理所有的 Task 并将输出的结果写入文件,经过一番 DEBUG ,发现竟是无缓冲通道的基本用法没有掌握熟练,当遇上多个 channel 协作的时候就难免会踩坑
先说重点:
无缓冲通道要求发送方和接收方同时准备好,才能”进行”发送和接收操作
show me the code