• 【2019年第15周】【2019/04/08 - 2019/04/14 】
  • A. LeetCode 151
  • R: Go Concurrency Patterns: Pipelines and cancellation
  • T:
    • Go 调度器的一个无法执行陷阱
    • 关于线程同步操作的一道面试题
  • S:
    • 腾讯防水墙团队：浅谈业务安全前端对抗
    • 《Go 语言核心36讲》之 条件变量 sync.Cond

Algorithm

Review

这篇文章读起来略有些费劲，这周只读了一半，下周继续读完

Tips

这周写了两篇文章:

修改了一篇文章:

Share

腾讯防水墙团队：浅谈业务安全前端对抗

原文链接: https://mp.weixin.qq.com/s/JBKTuwP5HEjsNLVheppHfg

这篇文章整体是个广告文，但是感觉讲的以下内容有点价值:

首先需要给大家一个客观的认识，类似 Uglify 的代码压缩并不是很好的代码保护手段，因此普遍认为代码压缩不属于代码保护的一部分，代码压缩只是一种代码优化。前端代码保护大致有两个流派，一个是以语法树变换为基础的混淆保护，一个是以构建私有执行环境为思路的虚拟机保护，谷歌则属于后者。代码混淆的效果因混淆器的负责程度而不同，基础级别的混淆器混淆出来的代码也很容易被逆向，而虚拟机保护的抗逆向效果好，其原理是在 JavaScript 的执行环境之上再设计构建一个虚拟机，所有原有业务逻辑的 JavaScript 代码均转换为该虚拟机可识别的字节码，复杂度较高效果好。

代码压缩并不是代码保护，这点我是很赞同的。想起之前在 V2EX 上，很多人在那争论 utf-8 算不算加密算法。我觉得这是很搞笑的争论，并不是说把文本变成人类无法识别的数字就是加密了。

在我的理解中，加密需要保证以下几个特性:

  1. 使用秘钥保证被保护的内容的安全，加密算法是否公开不会影响被保护内容的安全性。而且好的加密算法应该是公开的，这样才能让全世界的开发者一起来检验并提高安全性。
  2. 密文不能透露出原文的的时间，内容频率等信息。例如经典的凯撒加密算法在现在完全不能使用，很容易通过分析字母频率来破解。

《Go 语言核心36讲》之 条件变量 sync.Cond

课程链接：https://time.geekbang.org/column/article/41588 (需要购买方可查看)

  • 条件变量的 Wait 方法执行的操作

    1. 将调用它的 Goroutine 加入当前条件变量的通知队列中
    2. 解锁当前条件变量的底层互斥锁
    3. 让当前 Goroutine 处于等待状态，当前 Goroutine 会阻塞在Wait那行代码上
    4. 如果通知到来，唤醒当前 Goroutine，并且锁定条件变量底层的互斥锁，Goroutine 会继续执行后面的代码

  • Wait 为什么要将底层的互斥锁解锁

    • Wait解锁遵循了互斥锁的重要原则，成对的锁定和解锁。
    • Wait解锁后，其他的 Goroutine 也好修改互斥资源，否则其他 Goroutine 无法获得锁，也无法修改互斥资源。
    • 如果是其他 Goroutine 解锁互斥锁，这样很容易造成多 Goroutine 解锁同一个锁的情况，这样会导致不可恢复的panic。

  • Wait为什么要使用for循环来判断临界条件。

    1
2
3
4
5
6

    c.L.Lock()
for !condition() {
    c.Wait()
}
... make use of condition ...
c.L.Unlock()

    • 假设有多个 Goroutine 同时Wait一个cond的时候，某个 Goroutine 的Broadcast可能会唤醒多个 Goroutine，多个 Goroutine 都去针对cond底层的互斥锁上锁，只有一个 Goroutine 会上锁成功，其他 Goroutine 就会阻塞。 等成功上锁的 Goroutine 执行完之后，其他的 Goroutine 不会再去检查条件了，而是直接上锁，这样就会导致第二次上锁的 Goroutine 获得的临界条件不是预期的值 所以Wait操作要包裹在for循环之中。

    • 在多 CPU 核心的计算机系统中，即使没有收到条件变量的通知，调用其Wait方法的 Goroutine 也是可能被唤醒的。这是由计算机硬件层面决定的。