背景

僵尸指针问题非常难以调试。现在GoGC只会在扫描对象时报告这个问题，尽管Go GC在这里会引发恐慌，但信息不足以进行调试(reportZombies将打印此范围，但不会告诉开发者这个指针是如何收集到gcw的，开发者需要自己找出这个内存地址的来源)。
目前有两种可能导致指针指向gcw的方法：greyobject和gcWriteBarrier(以及它的cx、dx...派生)。greyobject已经有了debug.gccheckmark标志来验证这个指针是否正确，然而gcWriteBarrier没有相应的方法来进行验证。
例如，一个错误的atomic.StorePointer使用，如果开发者不关注这个值的正确性，就不会有任何错误报告。(特别是当这个字段是一个ID或其他没有实际意义的int64字段时)code snippet

package main

import (
	"fmt"
	"sync/atomic"
	"unsafe"
)

type struct1 struct {
	Field int64
}

type struct1ptr *struct1

var s1 struct1ptr = &struct1{
	1,
}

func main() {
	f1 := struct1{
		Field: 0,
	}
	atomic.StorePointer((*unsafe.Pointer)(unsafe.Pointer(s1)), unsafe.Pointer(&f1))
	fmt.Println(s1.Field)
}

此外，如果这个函数在高负载下工作，这个错误的赋值可能会导致僵尸指针，这很难调试。因为这个恐慌只会告诉开发者哪个mspan包含僵尸指针，但没有关于这个指针在哪里分配的信息。

package main

import (
	"fmt"
	"runtime"
	"sync"
	"sync/atomic"
	"time"
	"unsafe"
)

var current time.Time

func main() {
	var wg sync.WaitGroup
	for i := 0; i < 1000; i++ {
		wg.Add(2)
		go func() {
			defer wg.Done()
			rc := time.Now()
			atomic.StorePointer((*unsafe.Pointer)(unsafe.Pointer(&current)), unsafe.Pointer(&rc))
		}()
		go func() {
			defer wg.Done()
			fmt.Printf("%v\n", current.Unix())
		}()
		runtime.GC()
	}
	wg.Wait()
	fmt.Println("===over===")
}

另一个情况是不安全的类型转换。相同的UserInfo可能会导致开发者使用unsafe.Pointer来消除新的分配性能损失并避免为Map字段编写过长的代码。但是在IDL文件更新后，UserInfoFromARPC和UserInfoFromBRPC可能会不同，而且有很高的可能性是新添加的字段将是指针类型，因为新字段通常是可选的。

package main

import (
	"fmt"
	"runtime"
	"sync"
	"unsafe"
)

type UserInfoFromARPC struct {
	ID  int64
	Age int64
}

type UserInfoFromBRPC struct {
	ID    int64
	Age   int64
	Extra *string // this field was introduced after UnsafeQueryB is finished, and generated by some idl generator
}

func Query() *UserInfoFromARPC {
	return &UserInfoFromARPC{
		ID:  100,
		Age: 100,
	}
}

func UnsafeQueryB() *UserInfoFromBRPC {
	return (*UserInfoFromBRPC)(unsafe.Pointer(Query()))
}
func main() {
	var wg sync.WaitGroup
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			fmt.Println(UnsafeQueryB())
			wg.Done()
		}()
		runtime.GC()
	}
	wg.Wait()
}

建议

概要

在gcWriteBarrier中添加一个由宏控制的代码段，gcWriteBarrier将尝试在存储之前检查指针验证。如果指针非法，则在这里引发恐慌。通常情况下，恐慌堆栈将包含发生错误“分配”的函数的帧。开发者可以使用此功能更容易地找到他们的错误。

为什么选择修改gcWriteBarrier

僵尸指针只会发生在错误的指针被转储到堆中时。如果一个指针没有转储到堆中，它至少不会引起僵尸指针。

为什么选择使用宏而不是标志

因为gcWriteBarrier是一个经常被调用的函数，使用宏将避免更改常规代码。只有当开发者在他们的程序中发现了一个僵尸指针并且它是可重现的，他们才能使用-+和这个标志重新编译运行时并启用这些跟踪代码，然后等待恐慌找到错误所在的地方。

缺点

1. 用C宏控制编译后的代码在Go中并不常见
   但可能是最少的性能开销？
   PS:我们是否应该修改reportZombies以使其在设置了invalidptr=0时不引发恐慌？