ARTS
ARTS 是陈浩(网名左耳朵耗子)在极客时间专栏里发起的一个活动,目的是通过分享的方式来坚持学习。
每人每周写一个 ARTS:Algorithm 是一道算法题,Review 是读一篇英文文章,Technique/Tips 是分享一个小技术,Share 是分享一个观点。
本周内容
这一周的 ARTS 你将看到:
- Work Break II 这道题的评论区竟然有一半人都在吐槽测试例太恶心?
- 一篇文章了解 Golang GC 的“昨天、今天和明天”。
- 一个老 Gopher 常谈的问题,到底 return 和 defer 哪个先执行?
- 不要一开始就经陷入细节的地狱。
Algorithm
本周的算法题是 LeetCode 的 139.Work Break 和 140.Work Break II.
我本来只想做一下 140 题,这道题目的要求简单来说就是,输入一个字符串 s
和一个由不同单词组成的字典 wordDict
,由你来判断上面输入的 s
是否可以通过只添加空格的方式(只能把字符串拆分成多个“单词”,但是不能调整字符顺序)拆分成由 wordDict
中的单词组成的一个“句子”。
不(jian)难写出了下面通过回溯来“从前到后”拼接所有合法结果的代码。
“从前向后”回溯但会超时的解法
func wordBreak(s string, wordDict []string) []string {
var ans []string
wd := make(map[string]struct{}, len(wordDict))
for _, word := range wordDict {
wd[word] = struct{}{}
}
bt140(0, s, "", wd, &ans)
return ans
}
func bt140(start int, s, currStr string, wd map[string]struct{}, ans *[]string) {
if start == len(s) {
*ans = append(*ans, currStr)
return
}
newStr := currStr
for i := start; i < len(s); i++ {
cs := s[start : i+1]
if _, ok := wd[cs]; !ok {
continue
}
if start != 0 {
cs = " " + cs
}
newStr += cs
bt140(i+1, s, newStr, wd, ans)
newStr = currStr
}
}
但是无奈地发现单纯通过回溯的方式“从前向后”拼接符合要求的单词是没办法通过下面这个测试例的。无论怎么优化都超时,这是最致郁的。
s :="a...73a...aba...73a...a"
wordDict := []string{"a","aa","aaa","aaaa","aaaaa","aaaaaa","aaaaaaa","aaaaaaaa","aaaaaaaaa","aaaaaaaaaa"}
上面测试例中长达 140 多的输入字符串长度必然会让代码长时间卡在对第 75 个字符 b 判断失败之后的递归上。打开力扣评论区看到大半都在吐槽这个测试例我就放心了。除此之外还有很多评论在说可以根据第 139 题的结论,先对 140 的输入 s
判断一下是否能分割成句子,然后在真正的进行分割就可以通过。抱着试一试的心态,先把 139 题用最通俗的方式 AC 了,索性先看下 139 题。
使用第139题“从后向前”回溯的解法优化超时问题
大体思路就是使用回溯“从后往前”找满足要求的分割方式:每层判断当前起始位置 start
开始是否可以组成的单词,如果可以就把当前这个单词和 s
“后面”部分每个满足要求的分割拼接在一起,直到从 start
为 0 的时候找到的单词也被拼接到结果中。具体代码如下。
func wordBreak(s string, wordDict []string) bool {
wd := make(map[string]struct{}, len(wordDict))
for _, s := range wordDict {
wd[s] = struct{}{}
}
return breakable(s, wd)
}
func breakable(s string, wd map[string]struct{}) bool {
mem := make(map[int]bool, len(wd))
var dfs func(start int) bool
dfs = func(start int) bool {
if _, ok := mem[start]; ok {
return mem[start]
}
if start == len(s) {
return true
}
for i := start; i < len(s); i++ {
_, ok := wd[s[start:i+1]]
if ok && dfs(i+1) {
mem[start] = true
return true
}
}
mem[start] = false
return false
}
return dfs(0)
}
在最开始的 140 题目的解法中 wordBreak
函数里加入上面 breakable
函数先判断输入字符串能不能被正确分割,代码如下。
func wordBreak(s string, wordDict []string) []string {
var ans []string
wd := make(map[string]struct{}, len(wordDict))
for _, word := range wordDict {
wd[word] = struct{}{}
}
if !breakable(s, wd) {
return ans
}
bt140(0, s, "", wd, &ans)
return ans
}
直接使用“从后向前”的回溯方式
上面使用 139 题答案帮助判断的方式不仅可以 AC,而且最吊诡的是这个“组合”解法竟然能拿双百。想象一下如果面试的时候真的被问到这道题的话,如果给出这样的结果还是显得有些太奇怪了。毕竟针对测试例单独做优化这种路子有点野,除非遇到一个野生面试官,否则这种接法不会让他满意。
既然已经选择了回溯,就用回溯最常用的记忆化优化一下吧。因为“从前向后”的方式我暂时想不到方便的记忆化实现方式(如果你知道怎么做的话请在评论里告诉我),参考了别人的答案还是用了“从后向前”的方式来做。简单来说,就是记忆从某个 start
起到 s
结束所有的正确分割,实现可以参考下面的代码。
func wordBreak(s string, wordDict []string) []string {
sz := len(wordDict)
wd := make(map[string]struct{}, sz)
mem := make(map[int][]string, sz)
for _, word := range wordDict {
wd[word] = struct{}{}
}
var dfs func(start int) []string
dfs = func(start int) []string {
if _, ok := mem[start]; ok {
return mem[start]
}
var ret []string
if start == len(s) {
return ret
}
for i := start; i < len(s); i++ {
w := s[start : i+1]
if _, ok := wd[w]; !ok {
continue
}
sfxs := dfs(i + 1)
// s 中的最后一个可匹配的 word 就不需要再加空格了
if i+1 == len(s) {
ret = append(ret, w)
}
for _, sfx := range sfxs {
ret = append(ret, w+" "+sfx)
}
}
mem[start] = ret
return ret
}
return dfs(0)
}
Review
这周一起回顾一下 Go 官方介绍 GOGC 的文章:Getting to Go: The Journey of Go's Garbage Collector。
文章是 2018 年 7 月 在 Symposium on Memory Management (ISMM) 中的一次演讲的 PPT,可以算是目前为止官方对 Golang GC 历史最全面的一次介绍。下面是我对文中关于 GC 发展史主要内容的总结。
先说结论,目前 Golang 的 GC 算法是参考了 Dijkstra 的这篇论文 On-the-Fly Garbage Collection: An Exercise in Cooperation 来实现的。目前的 GC 是基于三色标记算法的,无分代,无碎片搬移,并使用了混合写屏障,存在微秒级别的 STW(Stop The World) 的,与业务逻辑并行执行的垃圾回收算法。
具体的故事还是从 2014 年开始说起,那时候的 GC 几乎是 Go 被吐槽最多的点,这已经严重拖累了 Go 的发展。这也是作者 Rick Hudson 刚来到 Go 团队时的情况,作者和其他开发人员一起制定了可实现的短期目标:没有读屏障的并行 GC.
Go 开发团队最终选择了“三色标记+并行执行+GC特殊阶段才开启写屏障”的实现,具体实现中还会使用“GC Pacer”来控制内存申请速度和内存标记速度,比如防止内存申请速度长期比标记速度快导致的“标记不完”的问题。
经过一番努力在 Go1.5 版本中(首次使用上述 GC 算法,在此之前写屏障会在 GC 时全程开启),经过线上服务的验证,垃圾回收延迟(原文中 GC latency)从 300-400 毫秒(ms)降低到了 30-40 毫秒。
1.6 版本中,延迟又被降低到了 5 毫秒以内。
1.8 版本中,延迟又又被降低到了 1 毫秒以内。
1.10 ……
至此作者认为 Go 终于摘掉了“GC 太垃圾”的帽子。在整个优化和提升的过程中,作者也客观的提到了 Go 团队所做出的取舍:为了编译速度放弃 ROC(Request Oriented Collector),为了吞吐量放弃分代(generational GC),等等。
最后作者表达了对未来 Go 发展的期待:保持性能的前提下提高可靠性,维持现有的 GC 模型,继续优化逃逸分析,优化写屏障,同时希望能够吃上未来五年内存性能发展所带来的红利(因为 GC 是 non-copying?)。
Tip
这周的 Tip 想聊一个经常被问到的问题:“return 和 defer 哪个先执行?”
先说结论吧:首先,编译器读到 defer 时对 defer function 的参数求值,这时会拷贝 defer function 的参数; 然后,程序执行到 return 时先将返回值保存到栈里;随后,按照后进先出的顺序执行之前保存好的 defer function;最后,函数退出并处理返回值。
如果这道题被问到的时候是结合代码的话,那么一定会涉及到 defer function 参数求值以及值传递引用传递的问题(虽然项目中并不推荐这样使用)。以上的这种问题,直接看官方的这个 https://blog.golang.org/defer-panic-and-recover 就可以完全解决了。文中最为关键的三句话,摘抄在这里。
- A deferred function's arguments are evaluated when the defer statement is evaluated.
一个 defer function 的参数在 defer 语句被求值(我理解是编译器读到这句时)的时候就已经被求值了。 - Deferred function calls are executed in Last In First Out order after the surrounding function returns.
defer function 在其外层函数 return 后才执行,且执行顺序是后进先出。 - Deferred functions may read and assign to the returning function's named return values.
defer function 可以对函数的有名返回值进行读取和赋值操作。
最后的最后,特别提醒一个值得注意的问题,就是 defer function 参数中如果出现了指针类型的话,一定要特别关注 defer function 是否会改变指针指向的值。
这个问题就聊到这里吧,如果你觉得我的观点存在任何问题,请随时在评论区指出来。
Share 灵光一闪
最近一直在看 GOGC 相关的东西,包括一些官网文档和大神们提炼的文章,越看越想深入去研究细节。结果就是陷入茫茫细节的海洋,逐渐忘了最开始想看什么内容。这个过程很像 DFS,但问题是可能深入的分支非常深,同时越深入的内容难度也会越大,导致花了非常多精力和时间之后还是没有一个整体的认知。或许学习的过程在最开始可以像 BFS 一样,先了解整体,再逐层深入,最后需要深度的时候在选择一个或者几个关键点深入学下去。
俗话说,细节是魔鬼(The devil is in the detail)。细节可能最后是无法避免的,接触魔鬼之前多学几样驱魔之术,应该比单纯靠勇气的结果好上不少。
以上。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。