Giới Thiệu
Sau khi tìm hiểu sâu về Go Maps (Phần 1), bước tiếp theo tự nhiên là khám phá mã nguồn của Go và cách mà các chức năng này thực sự được triển khai. Trước khi chúng ta có thể đi vào các tệp như map.go hay map_swiss.go, chúng ta cần trang bị cho mình một số kiến thức nền tảng. Thời gian chạy Go sử dụng nhiều chỉ thị biên dịch, các thao tác không an toàn, mẹo bit, và thậm chí là một chút mã assembly. Nếu không hiểu rõ những điều này, mã nguồn có thể trở nên khó hiểu.
Vì lý do đó, tôi bắt đầu chuỗi bài viết mới: Cẩm Nang Cơ Bản Về Mã Nguồn Golang. Chuỗi bài viết này sẽ phục vụ như một nền tảng, dạy cho bạn các công cụ và khái niệm mà bạn sẽ gặp phải khi đọc mã nguồn của Go. Khi chúng ta hoàn thành các khái niệm này, chúng ta sẽ quay lại với maps (và nhiều hơn nữa!) với sự tự tin để thực sự hiểu những gì đang xảy ra trong thời gian chạy.
Những gì chúng ta sẽ khám phá:
- ⚡ Chỉ thị biên dịch (
//go:linkname,//go:nosplit,thẻ xây dựng, v.v.) - 🔒 Các gói không an toàn và nội bộ (
unsafe,runtime/internal/sys,runtime/internal/atomic) - 🔢 Các thao tác bit và tối ưu hóa cấp thấp thường được sử dụng trong thời gian chạy
- 🧩 Các điểm tiếp xúc assembly (
memmove,memclrNoHeapPointers, v.v.) - 📏 Sự tương tác giữa sự phát triển stack và garbage collector (tại sao
nosplitlại quan trọng) - 🧭 Mẹo thực tiễn về cách điều hướng, sửa đổi, và xây dựng lại mã nguồn Go
Cuối cùng, bạn sẽ cảm thấy thoải mái khi mở các tệp thời gian chạy của Go và thực sự hiểu những gì đang xảy ra.
Chỉ Thị Dòng (//line) 📝
Chỉ thị này chủ yếu được sử dụng bởi các trình tạo mã và công cụ để cải thiện báo cáo lỗi, nó yêu cầu trình biên dịch xử lý mã tiếp theo như thể nó đến từ một số dòng và/hoặc tệp khác.
Ví dụ:
//line main.go:100
var x = "test" + 123Ở đây, bất kể tệp hoặc dòng thực tế là gì, đầu ra của trình biên dịch sẽ là:
main.go:100: invalid operation: "test" + 123 (mismatched types untyped string and untyped int)Chỉ Thị Hàm ⚙️
1. //go:noescape:
Chỉ thị này thông báo cho trình biên dịch rằng hàm không cho phép bất kỳ tham số con trỏ nào của nó thoát ra heap. Điều này có thể giúp trình biên dịch tối ưu hóa việc cấp phát stack và quy ước gọi. Nó chủ yếu được sử dụng trong mã cấp thấp hoặc mã thời gian chạy, và không làm ảnh hưởng đến hành vi của hàm — chỉ ảnh hưởng đến cách mà trình biên dịch xử lý các tham số con trỏ.
Nó phải được theo sau bởi một khai báo hàm không có thân hàm, và tệp assembly .s phải tồn tại trong cùng gói; nếu không, mã sẽ không biên dịch.
Ví dụ:
//go:noescape
func test1(a unsafe.Pointer) unsafe.PointerĐiều này hợp lệ nếu tồn tại tệp .s (tệp nguồn assembly Go) và thực hiện thực tế của test1 nằm trong tệp .s đó với cùng tên, ví dụ:
//go:build amd64
#include "textflag.h"
// TEXT ·test1(SB), NOSPLIT, $0-16
// Implements: func test1(a unsafe.Pointer) unsafe.Pointer
TEXT ·test1(SB), NOSPLIT, $0-16
MOVQ 0(FP), AX // load a
MOVQ AX, 8(FP) // store return value
RETTrong dòng đầu tiên, bạn có thể thấy //go:build amd64, đây là một điều kiện xây dựng. Nó thông báo cho hệ thống xây dựng Go biên dịch tệp này chỉ khi nhắm đến kiến trúc amd64. Nếu tên tệp đã kết thúc bằng _amd64.s, thẻ xây dựng là tùy chọn.
Nếu chúng ta không có bất kỳ tệp .s nào trong cùng gói và chạy mã trên, chúng ta sẽ nhận được lỗi: missing function body.
Như tôi đã đề cập, các hàm được đánh dấu bằng //go:noescape không được có thân hàm.
Chúng ta đặt một tệp .s và chạy mã sau:
//line main.go:100
//var x = "test" + 123
//go:noescape
func test1(a unsafe.Pointer) unsafe.Pointer
//go:noescape
func test2(a unsafe.Pointer) unsafe.Pointer {
return test1(a)
}Đầu ra sẽ là:
main.go:106: can only use //go:noescape with external func implementations2. //go:noinline🚫:
Nó phải được theo sau bởi một khai báo hàm, thông báo cho trình biên dịch không bao giờ inlining hàm ngay lập tức theo sau, bất kể kích thước hoặc heuristics. Nó chủ yếu được sử dụng để viết các benchmark ổn định (ngăn chặn tối ưu hóa loại bỏ hoặc gập các cuộc gọi) hoặc gỡ lỗi trình biên dịch.
//go:noinline
func add(a, b int) int {
return a + b
}3. //go:nosplit🧵:
Nó phải được theo sau bởi một khai báo hàm, vô hiệu hóa các kiểm tra phát triển stack cho hàm ngay lập tức theo sau. Trình biên dịch sẽ bỏ qua phần mở đầu phân tách stack, vì vậy hàm không bao giờ cần nhiều stack hơn là đã có sẵn (không gọi vào morestack). Sử dụng trong các hàm runtime cấp thấp, lá, phải chạy ngay cả khi stack của goroutine gần như cạn kiệt (ví dụ: trong stack growth, signal handling).
Lưu ý: Chúng ta sẽ thảo luận thêm về điều này trong các phần sau.
Hạn chế: giữ cho nó rất nhỏ, không gọi vào mã có thể cấp phát, panic, block, hoặc phát triển stack. Lạm dụng có thể gây ra sự cố không thể phục hồi.
Ví dụ gây lỗi:
//go:nosplit
func add(n int) int {
if n == 0 {
return 0
}
return 1 + add(n-1)
}Tôi đã gọi nó với n = 1000 và đầu ra là:
main.add: nosplit stack over 792 byte limit
main.add<1>
grows 24 bytes, calls main.add<1>
infinite cycleChỉ Thị Linkname(//go:linkname) 🔗:
Nó thông báo cho trình biên dịch rằng một định danh cục bộ nên được liên kết với (chia sẻ biểu tượng của) một định danh khác (có thể không được xuất khẩu) trong một gói khác. Điều này bỏ qua khả năng nhìn thấy, vốn không an toàn và dễ bị thay đổi phiên bản.
Nó yêu cầu nhập gói unsafe, ngay cả khi không sử dụng (ví dụ: import _ "unsafe"), vì nhóm Go đặc biệt nói với chúng ta rằng điều này không an toàn.
Hai hàm được liên kết với nhau không cần phải có cùng chữ ký, dẫn đến panic nếu bị sử dụng sai.
Ví dụ:
go
// inside the main.go file:
//go:linkname testLink
func testLink(a, b, c string) string
func main() {
log.Println(testLink("a", "b", "c"))
}
// inside the test.go file in another package named 'another':
//go:linkname test main.testLink
func test(a, b string) string {
return a + b
}Đầu ra sẽ là "ab". Như bạn thấy, hàm test trong gói another là riêng tư (không xuất khẩu), và các chữ ký cũng không khớp.
Linkname: Tự Do Nguy Hiểm ⚠️
Chỉ thị linkname tạo ra một vấn đề: chúng ta có thể dễ dàng viết các hàm hoặc biến liên kết với các chi tiết nội bộ của Go, và điều này tạo ra nhiều phụ thuộc vào các chi tiết nội bộ của Golang, điều này đã tạo ra một vấn đề nghiêm trọng: nhiều chương trình hiện phụ thuộc vào các chi tiết nội bộ của Go, điều mà chúng chưa bao giờ được thiết kế để phụ thuộc vào, vì việc thay đổi các nội bộ có thể phá vỡ các chương trình Go đó. Nhóm Go đang cố gắng hạn chế (hoặc ít nhất là giới hạn) việc sử dụng linkname trong mã của người dùng để tránh nhiều hơn nữa các phụ thuộc vào các nội bộ của Golang.
Thẻ Xây Dựng (//go:build, // +build) 🏗️:
Thẻ xây dựng xác định xem một tệp có nên được bao gồm trong việc biên dịch của một gói hay không. Điều này cực kỳ hữu ích cho việc viết mã cụ thể cho nền tảng hoặc tạo các phiên bản xây dựng khác nhau của ứng dụng của bạn.
Cú pháp hiện đại và ưa thích là chỉ thị //go:build. Nó phải được đặt ở đầu tệp, chỉ được tiếp theo bởi các dòng trống hoặc các chú thích khác, và phải được theo sau bởi một dòng trống.
1. //go:build (Go 1.17+)
Điều này có nghĩa là biên dịch tệp này chỉ khi xây dựng cho Linux trên amd64:
//go:build linux && amd64Điều này có nghĩa là biên dịch tệp này chỉ trên hệ thống 64-bit Linux hoặc 64-bit Windows.
//go:build (linux && amd64) || (windows && amd64)Thẻ Tùy Chỉnh🏷️:
Bạn có thể định nghĩa thẻ của riêng bạn để tạo ra các bản xây dựng khác nhau, như một bản xây dựng "phát triển" với ghi log thêm.
//go:build dev
package mypackage
import "log"
func DebugLog(message string) {
log.Printf("[DEV] %s", message)
}//go:build !dev
package mypackage
// This is a no-op in release builds.
func DebugLog(message string) {}Để biên dịch với thẻ dev, bạn sử dụng cờ -tags:
# Điều này sẽ bao gồm debug_logger.go và thực hiện DebugLog của nó.
go build -tags="dev"
# Điều này sẽ bao gồm release_logger.go, nơi DebugLog không làm gì cả.
go build2. // +build (Legacy)
Cú pháp cũ hơn. Mặc dù vẫn được hỗ trợ, //go:build là cú pháp được ưa thích. Bạn có thể sử dụng cả hai trong cùng một tệp để tương thích ngược. Một tệp được bao gồm nếu công thức boolean được thỏa mãn.
// +build linux,darwin
// ... tệp này sẽ được bao gồm trên các hệ thống Linux HOẶC Darwin.🚀 Điều Gì Tiếp Theo?
Trong phần này, chúng ta đã khám phá các chỉ thị biên dịch và thẻ xây dựng, những “công tắc ẩn” điều khiển cách các tệp nguồn Go được biên dịch và cách mà các hàm thời gian chạy hoạt động. Những điều này có mặt khắp nơi trong thời gian chạy Go và bây giờ bạn sẽ nhận ra chúng khi tìm hiểu các tệp như runtime/asm_amd64.s hoặc map.go.
👉 Trong Phần 1, chúng ta sẽ đi sâu vào các Gói Không An Toàn & Nội Bộ mà thời gian chạy phụ thuộc vào. Bạn sẽ thấy cách mà unsafe.Pointer, runtime/internal/sys, và runtime/internal/atomic mở khóa sức mạnh cấp thấp của Go.
Hãy theo dõi — nó sẽ còn thú vị hơn nữa! ⚡
