In daily development, panic will appear if you are not careful. If you do not register RECOVER, panic will directly interrupt the logic behind the program. Improper use will bring huge hidden dangers. Here are two common mistakes about panic!

1. Panic and Recover

In concurrency issues, we often use read/write locks to ensure concurrency security. In the seven memory leak scenarios, we mentioned that improper use of locks would cause Groutine to leak memory because it could not obtain locks. The following is an example of Chaochao and Tingting acquiring the right to use TV.

Defines the TV structure and provides methods to register and get the current consumer

type Television struct {
  belong string
  sync.RWMutex
}
​
func (m *Television) set(name string) {
  m.Lock()
  m.belong = name
  m.Unlock()
}
​
func (m *Television) get() string {
  m.RLock()
  user := m.belong
  m.RUnlock()
  return user
}
Copy the code

In the main process, the user concurrently obtains the TV use right

func main() {
  users := []string{"chaochao", "tingting"}
  tv := &Television{}
  w := sync.WaitGroup{}
  usersLen := len(users)
​
  w.Add(usersLen)
  for i := 0; i < usersLen; i++ {
    go func(user string) {
      tv.set(user)
      w.Done()
    }(users[i])
  }
  w.Wait()
  fmt.Println("TV user is", tv.get())
}
Copy the code

The output

TV user is tingting
Copy the code

There seems to be no problem, but what if the get and set methods are more complicated and panic occurs?

Func (m *Television) set(name string) {m.lock () m.long = name // Panic ("setErr") m.lock ()}Copy the code

Then the whole program will crash, online if there is such a problem, basically belong to the prize! Therefore, we need to register a defer to recover the panic, so that the program can continue to run.

func main() { users := []string{"chaochao", "tingting"} tv := &Television{} w := sync.WaitGroup{} usersLen := len(users) w.Add(usersLen) for i := 0; i < usersLen; I++ {go func(user string) {defer func() {if err := recover(); err ! = nil { fmt.Println("err:", err) } }() tv.set(user) w.Done() }(users[i]) } w.Wait() fmt.Println("TV user is", tv.get()) }Copy the code

It looks like the program is fine here, but is it?

Second, memory leakage

In the set method, before panic there was an operation to acquire the lock, but after panic the set method simply exits without releasing the lock. Other coroutines fail in their attempts to acquire the lock, causing Goroutine leaks.

Therefore, lock release is best inlockThen register onedeferRelease.

type Television struct {
  belong string
  sync.RWMutex
}
​
func (m *Television) set(name string) {
  m.Lock()
  defer m.Unlock()
  m.belong = name
}
​
func (m *Television) get() string {
  m.RLock()
  defer m.RUnlock()
  user := m.belong
  return user
}
Copy the code
Third, summary

This article introduced the use of panic and Recover, which are usually placed in defer to prevent panic interrupters from having a huge impact on the line. We then explained that lock release should also be placed in defer to prevent memory leaks due to other coroutines not getting locks when Painic fails to release the locks. For more information about Painic, please leave a comment below!