I don't understand the problem you're trying to solve.

You're writing a single-threaded program. Don't use the go statement. Then you won't need locks on your global variables. It's irrelevant whether, or how, the runtime interrupts your goroutine occasionally to get its own work done.

In any case, this issue tracker isn't the right place for this kind of discussion. Please see https://golang.org/wiki/Questions for good places to ask.

@randall77 Thanks for your reply, and sorry for that I did not make my problem clear.
For example, I have a simple http server, this is my main function:

func main() {
    runtime.MAXGOPROC(1); // use only one thread to run all goroutines
    ...... // start http server
}

And, each client request will call into this function:

func simpleHandler(r*Request) {
    ...... // do long time cost job, consume almost 10ms time
   aMap[key] = value // access to a global map instance named aMap
}

as you sugguest, I do not use "go" to create new goroutine, but the HTTP runtime does: every new client request correspond to a new goroutine.
because long time cost job has cost almost 10ms, and when it run into "aMap[key]=value", the goroutine will have great chance to be preemted, and then another goroutine read the map, it will panic:

If I can disable the "cooperative goroutine preemption", then everything goes right.

Regardless of the GOMAXPROC setting your program has a logical data race, and is considered by the go specification to be undefined. We're not going to change the language to support this use case but maybe you could explain the underlying problem that has lead you to use a shared map, there may be another way to solve your underlying problem without changing the language.

@davecheney Thanks for your reply.
I recognize that I can use mutex, but the most important thing to me, is how can we get rid of the missing lock/unlock of mutex.? Maybe someday, somebody goes wrong, and then a thread safety(or concurrent safety) bug come, unfortunately, this type of bug show up randomly, and is difficult to reproduce and fix.

If golang has the facility just like rust does, utilize the compiler to force things to be thread safety, then mutex is free to use(without the consideraton of performance). But for now, golang need the programer to ensure thread safety, that make my hair curl.

I can set GODEBUG=asyncpreeptoff=1 to disable async preemption, and runtime.GOMAXPROC(1) to use only one thread to run all goroutines, then, if we can disable the '10ms coorperative preemption' too, we need not to use mutex most of time.

@linguohua Have you seen https://blog.golang.org/race-detector and https://golang.org/doc/articles/race_detector.html ? The race detector can help detect a missing lock/unlock of a mutex.

Thank you for explaining your use case.

Generally the practice to ensure lock invariants are followed is to place the type under the mutex and the mutex itself into a struct and drive access to those values through methods on that struct.

Alternatively, grant the ownership of the thing under the lock to a single goroutine and mediate access to that state via messages over a channel.

Lastly, pervasive use of the race detector in test and canary deploys is recommended to local data races.

@ianlancetaylor @davecheney Thank you both.
I will follow your advices to refactor our code.