How does one implement the Singleton design pattern in the go programming language?
-
1how do you implement a Singleton in any language? :D – Gordon Gustafson Dec 01 '09 at 00:15
-
31Hopefully it's impossible. – Mark Byers Dec 01 '09 at 00:25
-
15why the gruff with singletons? Am I missing a new trend? The singleton design pattern has its uses. – Brenden Nov 19 '13 at 18:21
10 Answers
Setting aside the argument of whether or not implementing the singleton pattern is a good idea, here's a possible implementation:
package singleton
type single struct {
O interface{};
}
var instantiated *single = nil
func New() *single {
if instantiated == nil {
instantiated = new(single);
}
return instantiated;
}
single
and instantiated
are private, but New()
is public. Thus, you can't directly instantiate single
without going through New()
, and it tracks the number of instantiations with the private boolean instantiated
. Adjust the definition of single
to taste.
However, as several others have noted, this is not thread-safe, unless you're only initializing your singleton in init()
. A better approach would be to leverage sync.Once
to do the hard work for you:
package singleton
import "sync"
type single struct {
O interface{};
}
var instantiated *single
var once sync.Once
func New() *single {
once.Do(func() {
instantiated = &single{}
})
return instantiated
}
See also, hasan j's suggestion of just thinking of a package as a singleton. And finally, do consider what others are suggesting: that singletons are often an indicator of a problematic implementation.

- 1,730
- 15
- 10
-
Having not tested this code, it looks to me like you'd only be able to get an instance of single the first time you call New(). After that, you just get nil. If you lose track of your one instance and it gets garbage collected, you can't create any more. Wouldn't you want to keep track of the pointer to the instance of single and return that instead of nil? – Evan Shaw Dec 03 '09 at 17:54
-
Agreed; I've changed the code to do so, although linguistically I'm not very happy with New() returning something other than a fresh object. In another language, I probably would have raised an exception when trying to instantiate the object a second time. Note that, with this approach, the singleton will never actually go out of scope. – esm Dec 05 '09 at 00:24
-
Also, I'll point out again that a better way to think about this is probably hasen j's Pythonic approach: treat a package as your singleton, which the language enforces for you already. – esm Dec 05 '09 at 00:25
-
9Perhaps overlooked; would a singleton in Go also need to deal with synchronization? What if several goroutines call New() at the same time and then all evaluate `if instantiated = nil` to true ? – Allen Hamilton Nov 03 '12 at 23:12
-
you don't need to init `single` to `nil` since that's the default value, right? – Brenden Nov 19 '13 at 18:20
-
8This example is not thread-safe, see : http://marcio.io/2015/07/singleton-pattern-in-go/ – Aleš Jul 21 '15 at 05:29
-
I've updated the example to use sync.Once, which is seems to be the most idiomatic way to accomplish this right now. – esm Jan 07 '16 at 01:07
-
Go's happens before says that "func passed to sync.Do only gets called once". My question is can other go routines see fully constructed instantiated object immediately after sync.Do returns? If you take java for example instantiated needs to be volatile for other threads to see fully constructed instantiated value. – Siva praneeth Alli Jul 09 '20 at 16:14
Just put your variables and functions at the package level.
Also see similar question: How to make a singleton in Python
I think that in a concurrent world we need to be a bit more aware that these lines are not executed atomically:
if instantiated == nil {
instantiated = new(single);
}
I would follow the suggestion of @marketer and use the package "sync"
import "sync"
type MySingleton struct {
}
var _init_ctx sync.Once
var _instance *MySingleton
func New() * MySingleton {
_init_ctx.Do( func () { _instance = new(MySingleton) } )
return _instance
}

- 46,639
- 15
- 102
- 119
-
3
-
Hi @fabrizioM , I have a question here: your code is thread-safe. But there is another problem: the struct name is MySingleton - so we can init an object without calling New(): secondInstance := MySingleton{}. – hungson175 Apr 16 '15 at 14:57
-
However, if the struct name is changed to mySingleton, we have another problem: in different package we can only get the instance, but cannot pass around: obj := singletonpkg.New() is OK - but some function like func process(singletonpkg.mySingleton obj) { ... } is NOT OK. So, how can we implement the "correct" Singleton in go ? – hungson175 Apr 16 '15 at 15:23
-
1@hungson175 if mySingleton implements an exported interface, say `SingletonInterface`, you can have the `New` function return an instance of the interface, not the unexported type. – scottysseus Oct 22 '19 at 13:58
Before trying to find a way to bend Go to your will, you might want to take a look at some articles:
In summary, over time people have found singletons to be less than optimal, and imho especially if you are trying to do any test-driven development: on many levels they are pretty much as bad as global variables.
[disclaimer: I know its not a strict answer to your question but it really is relevant]

- 25,416
- 6
- 48
- 54

- 78,960
- 28
- 103
- 104
-
1Isn't the Unix philosophy (small, sharp tools) similar to using Singleton classes? – Gustav Apr 17 '15 at 14:30
-
27Sorry, but this should not be up-voted. Does not answer the question. None of the sources have anything to do with the Go programming language either. This is not the place for religious debates on coding patterns. – Evan Byrne May 21 '18 at 00:32
Easy peasy as you can see in the following code:
package main
import (
"fmt"
"sync"
)
type singleton struct {
count int
sync.RWMutex
}
var instance singleton
func GetInstance() *singleton {
return &instance
}
func (s *singleton) AddOne() {
s.Lock()
defer s.Unlock()
s.count++
}
func (s *singleton) GetCount() int {
s.RLock()
defer s.RUnlock()
return s.count
}
func main() {
obj1 := GetInstance()
obj1.AddOne()
fmt.Println(obj1.GetCount())
obj2 := GetInstance()
obj2.AddOne()
fmt.Println(obj2.GetCount())
obj3 := GetInstance()
obj3.AddOne()
fmt.Println(obj3.GetCount())
}
Expected result would be:
1 2 3
Because you're accessing to the same resource. That's the reason I've added mutex in order to be concurrent proven accessing count attribute from multiple processes. :-)
Source:

- 1,721
- 19
- 20
You can do initialization using the once package:
This will ensure that your init methods only get called once.

- 41,507
- 11
- 37
- 40
Just have a single static, final, constant, global, application-wide instance of the Object you want.
This however contradicts the OO paradigm. Its use should be limited to primitives and immutable objects, not to mutable objects.

- 1,082,665
- 372
- 3,610
- 3,555
You should be aware that Once.Do
is serious about executing the code only once. That means, the code is always executed only once, even though it might have panicked:
from https://golang.org/pkg/sync/#Once.Do
If f (note: the once logic) panics, Do considers it to have returned; future calls of Do return without calling f.
I used mutexes instead to ensure unique initialisation of a global configuration variable to overcome this restriction:

- 4,381
- 28
- 28
I think if you want something like a singleton in Go you should try and think about what you're trying to achieve. Unlike Java or C#, Go has no concept of "static" classes, so the traditional distinction is less clear. In my mind, the key point you'd want from a singleton is not allowing others to construct it. To that end, I think it can achieved more simply: export an interface, implement an unexported class which implements this interface, and export a single instance of it. For instance:
var DefaultTransformer Transformer = &transformer{}
type Transformer interface {
Transform(s string) string
}
type transformer struct {
}
func (t *transformer) Transform(s string) string {
return s + "1"
}
var _ Transformer = (*transformer)(nil)
As the other answers show, there are many more literal ways you can implement the singleton pattern in Go, but they strike me as answers that start from the premise that the pattern must be copied exactly, rather than starting from solving a real problem you have in Go.

- 3,307
- 1
- 26
- 41