@Hopetree #17

因为 405 、401 、404 这三个都属于前缀模式匹配。/static/js/css/4.png 同时匹配到了这三个前缀模式，当同时匹配到多个前缀模式时，需要按最长匹配规则进行选取，即最终会命中 405 。

而 405 没有阻止继续匹配正则，所以会继续匹配正则模式，而正则模式就是 402 那个，所以会返回 402

@coderzhangsan #12 ，其实就是匹配相同的子字符串，看哪个子字符串最长

比如有三个 location :
A：/a
B: /a/b
C：/a/b/c

对于字符串 /a/b/c/d ，A 、B 、C 三个都能匹配到，但 C 是最长的，所以最终会采用 C 这个 location

@xlzyxxn #50 ，羡慕啊，5 年就有这么多，我这边很多公司都是按最低工资缴纳公积金的，导致我一个月的公积金只有几百块钱

公积金余额会影响以后公积金贷款的额度，如果你没有公积金贷款买房打算的话可以全部提取出来

@Linken404 #3 ，单纯看配置文件，bbb.example.com 的 http 协议监听端口是 8080 ，你在 return 301 的时候又没有指定 8080 端口，不确定是不是这个原因

我也很喜欢这种真全面屏直边框的外观造型，外观真的无可挑剔！但有几个缺点还在纠结：
1 ）不支持无线充电
2 ）不清楚努比亚的系统好不好用，毕竟是小众厂商，感觉不会像大厂开发的那么好用
3 ）屏幕分辨率不是很高

希望 OP 使用一段时间后，可以再发一下使用感受让我参考下~~

@lesismal @codehz @Evrins 好吧，原来是编译器的问题。感觉多线程并发这块水真的有点深，原子性、内存可见性、指令重排、CPU 的 MESI 缓存一致性协议、内存屏障...涉及到一大堆东西，还要预防编译器的自动优化问题，防止出现预期之外的情况，后面这些再逐块深入研究了，哈哈哈哈...最后再次感谢你们帮忙分析，感谢已经发送~

@dyllen

"根本没有什么可见性的问题，一个协程修改了，另一个协程里面能立马读到新的值"，关于这个我可以给你一段代码例子：
```go
func main() {
flag := true

// 协程 A
go func() {
fmt.Printf("Goroutine start\n")
for flag {
fmt.Printf("Goroutine flag: %v\n", flag)
time.Sleep(time.Second * 1)
continue
}
fmt.Printf("Goroutine finish\n")
}()

for {
flag = false
continue
}
}
```
上面这段代码在我的机器上执行，每次都是不断的输出 "Goroutine flag: true"，说明 main 协程 中的 flag = false 赋值语句没有生效，或者说生效了，但是新的值没有被 协程 A 观测到。

然后还想问下 @codehz 大佬，上面这段代码之所以出现这样的运行结果，是不是也是因为指令重排导致的呢？

感谢所有大佬的热心回复，这个帖子就先讨论到这吧，我要先整理和消化下相关知识，thanks~~

@codehz 并发有三大问题：原子性、有序性、可见性。你说的执行顺序，我觉得是属于有序性的范畴。现在主要是在讨论可见性，而可见性问题是由于 CPU 各个核心缓存不一致 导致的

@BeautifulSoap
@xiaxiaocao
@codehz

首先非常感谢各位大佬的回答，因为我平时高并发做得比较少，所以这块知识有点混乱，再加上表达能力确实不太好，导致挺多人 Get 不到我疑惑的地方。

然后对于 @BeautifulSoap ：
1. 因为单线程程序没有并发可见性问题，所以我就先假设了两个协程分别跑在不同的 CPU 核心上
2. 谢谢你分享的这篇文章，纠正了我的一个误区：之前我以为 happens-before 规则只是一个事件发生顺序的一个规定，但其实它还包含了”可见性“的语义，A happens-before B 代表 A 对共享变量做出的修改，对于 B 来说是可见的。

然后 golang 的 channel 为了满足可见性要求，我猜底层应该会有以下操作：
1. 线程 A 修改共享变量，不能只将修改保存在线程所在 CPU 核心的缓存里，还要将它同步回内存
2. 如果其它 CPU 核心上也有此共享变量，需要将缓存里的变量设置为失效状态
3. 其它核心上的线程读取共享变量，因为所在核心的缓存状态已标记为失效，只能去内存里读，此时就能读到最新的变量值了

我这样理解对不对呢？

@raynor2011
@cyrivlclth

非常感谢，我先消化下你们发出来的链接内容

@ZField #28 对，java 的 volatile 关键字，我看网上资料说是通过禁用 CPU 缓存来解决可见性问题的，但 golang 的 channel 是不是通过同样的方式去解决的就不知道了，还是说可见性问题只存在 java ？但这个貌似也说不通，只要是多线程并发，应该就会有可见性问题

@cyrivlclth #21 所以可见性问题只存在于 Java 语言吗

@yph007595 #15 因为 CPU 有多个核心，每个核心都有独立的缓存，线程 A 修改了共享变量，那么这个修改只会存储到它自己所在的核心，跑在其它 CPU 核心的线程不一定能知道这个修改，比如 java 语言提供的 volatile 关键字，就是通过禁用 CPU 缓存来解决这个可见性问题的（最后一句关于 java 的话来自 ChatGPT ）

@InDom 谢谢回答，我知道无缓冲的 channel 会阻塞，但我关注的重点是多线程并发的可见性问题，具体可以看 #5 的回复

@sunny352787 可是就算 channel 阻塞结束了，main 协程也不一定能够打印出 "hello, world" 吧？因为 golang 是多线程，多线程并发就会有可见性问题，一个线程修改了共享变量，这个修改对于其它线程来说不一定能观测到

9 年经验 6k ？

@brader 回复 2 楼，其实现实中微信聊天，对方一般也是等全部内容输入完了才会发给你的，所以换到 chatgpt ，等全部内容接收完后，做一次检测再发送给用户这个我觉得问题不大。关键点是你要提醒用户你正在打字，比如“程序正在生成回答，已经生成了 xx 个字，请耐心等待”，总之就是不要让用户觉得你的程序卡住了