LockGit
对于加锁和解锁操作为什么不使用defer
func (b *Bucket) Room(rid int) (room *Room) { b.cLock.RLock() room, _ = b.rooms[rid] b.cLock.RUnlock() return } 为何不写作 func (b *Bucket) Room(rid int) (room *Room) { b.cLock.RLock() defer b.cLock.RUnlock() room, _ = b.rooms[rid] return }
没什么不同吧。。。
defer的话，不管下面逻辑怎样都会执行，相当于try finally 解锁，防止lock后逻辑出错，锁一直被占着 但defer会有性能损耗
没什么不同吧。。。
https://mp.weixin.qq.com/s?__biz=MzA4ODg0NDkzOA==&mid=2247487117&idx=1&sn=f16833a6f11e929ba6f1d0bca73e9a02&chksm=9022b168a755387e33f0c31c1ea7b44452b04125b80964883de4ba6ad81a097d3c5211e36709&scene=126&sessionid=1585665601&key=5ad99c85beba54493778e510614e9215cde3928ea95bfc6f5c0fdb2ad4d6304efbce1e1ca00e17264052b9f8d7c040260fe9bd7221c2af432694540918c7c64c43ccb66e60527fcae9ce328e898f09f5&ascene=1&uin=MTAzNjg2OTM2MQ%3D%3D&devicetype=Windows+10&version=62080079&lang=zh_CN&exportkey=AWqYJ%2FXom3cDgNQVLaUqf7M%3D&pass_ticket=S5jTvgPK9dIL3iw0fZ7axO6trE0iVPrbxWp4oF5al3PgbcbuPr262qWV%2B7lqrCcY
不知道你贴这个意义是什么，，这里面原话是
defer 的开销非常小，只有在你觉得你的函数执行需要在纳秒级别的情况下才需要考虑避免使用。使用 defer 换取的可读性是值得的。这尤其适用于具有比简单内存访问更复杂的大型方法，这时其他的计算比 defer 更重要。
何来性能损耗这中说法？
而且
defer的话，不管下面逻辑怎样都会执行
这句话也不对吧，
少看点八股文，，多看看实际场景。
这三行代码，一共就三种情况
锁住 从 map 中获取 value 成功 用不用 defer 无影响 锁住 从 map 中获取 value 失败 用不用 defer 无影响 未锁住 无法获取 推测 lock 中报错， unlock 函数不处理，也无影响
这三行代码，一共就四种情况
锁住 从 map 中获取 value 成功 用不用 defer 无影响 锁住 从 map 中获取 value 失败 用不用 defer 无影响 未锁住 从 map 中获取 value 成功 推测 lock 中报错， unlock 函数不处理，也无影响 未锁住 从 map 中获取 value 失败 推测 lock 中报错， unlock 函数不处理，也无影响
我的意思不是针对某一个场景，我的意思是unlock放defer一方面可读行好，一方面是可以防止忘记unlock操作，以及中间代码执行错误unlock没有执行
如果你的函数有 300 行，defer 会可读性更好，这函数就三行，用不用 defer 没区别。除非你的屏幕只能显示两行代码。具体情况具体分析。
defer只是个语法糖，并不是代码风格的强制要求。可以推荐这种写法，但行数少的时候不这么写也不算错。
