Java和go的异同，以及go的一些坑

1.为什么go没有volatile？

go推荐用channel传递共享变量，传递消息。
Share memory by communicating, don't communicate by sharing memory.
通过通信共享内存，而不是通过共享内存而通信。面对并发问题，你首先想到的应该是channel，因为channel是线程安全的并且不会有数据冲突，比锁好用多了。
channel的核心是数据流动，关注到并发问题中的数据流动，把流动的数据放到channel中，就能使用channel解决这个并发问题
《Channel or Mutex》中给了3个数据流动的场景：

1. 传递数据的所有权，即把某个数据发送给其他协程
2. 分发任务，每个任务都是一个数据
3. 交流异步结果，结果是一个数据

mutex的能力是数据不动，某段时间只给一个协程访问数据的权限擅长数据位置固定的场景。
《Channel or Mutex》中给了2个数据不动场景：

1. 缓存
2. 状态，我们银行例子中的map就是一种状态

2.Swtich
Go语言改进了 switch 的语法设计，case 与 case 之间是独立的代码块，不需要通过 break 语句跳出当前 case 代码块以避免执行到下一行，

3.go没有可重入锁，但是可以自己实现
4.值传递
java值传递，Java中的对象传递，如果是修改引用，是不会对原来的对象有任何影响的，但是如果直接修改共享对象的属性的值，是会对原来的对象有影响的。
go也是值传递，但slice、map、channel的值天生就是指针。go slice的坑

5.阻塞队列
java 的阻塞队列类似于go的channel，go提出的用channel进行并发通信，处理生产者，消费者问题。
垃圾收集也基本相同，

6.闭包
闭包，java的闭包引用的变量必须是final 而go引用的变量可以修改，且是延迟加载。
在Java中，闭包是 通过“接口与内部类实现的”

7.场景
go主要的场景在于高并发的程序，语法简单。
java适合业务复杂的场景

8.CountDownLatch
go的sync包下的WaitGroup与Java的CountDownLatch类似
wg := sync.WaitGroup{}
workers := 3
wg.Add(workers)
worker := func() {
defer wg.Done()
// 干活干活干活
}
leader := func() {
wg.Wait()
// 检查工作成果
}
go leader()
for i := 0; i < workers; i++ {
go worker()
}

CountDownLatch
CountDownLatch countDown = new CountDownLatch(1);
countDown.countDown();
await.await();

WaitGroup 的整个调用过程可以简单地描述成下面这样：

1. 当调用 WaitGroup.Add(n) 时，counter 将会自增: counter += n
2. 当调用 WaitGroup.Wait() 时，会将 waiter++。同时调用 runtime_Semacquire(semap), 增加信号量，并挂起当前 goroutine。
3. 当调用 WaitGroup.Done() 时，将会 counter--。如果自减后的 counter 等于 0，说明 WaitGroup 的等待过程已经结束，则需要调用 runtime_Semrelease 释放信号量，唤醒正在 WaitGroup.Wait 的 goroutine。
   （信号量（进程通信））

go主线程结束，子线程也结束

附go slice 的坑

当slice长度不足以放下新元素时，会将当前的数据复制到一个更大的数组中。自动扩容时，长度在1024以下的每次扩容到原数组的2倍。大于1024的每次扩容1.25倍。

这种特性会导致很多特殊情况。

slice是否被修改

package main
import "fmt"
func main(){
    s := make([]int, 3, 3) //[0 0 0]
    modifyA(s)
    fmt.Println(s)

    modifyB(s)
    fmt.Println(s)

    modifyB(s[0:2])
    fmt.Println(s)

    modifyC(s[0:2:2])
    fmt.Println(s)

    w := s[1:]
    w[0] = 6
    fmt.Println(w)
    fmt.Println(s)
}

func modifyA(x []int){
    x[1] = 1
}
func modifyB(x []int){
    x = append(x, 2)
}
func modifyC(x []int){
    x = append(x, 4)
}
func modifyD(x []int){
    x[0] = 3
}

调用modifyA会修改。因为将 ptr传递给了函数 所以操作的底层数组还是同一个。

modifyA(s)
fmt.Println(s) //被修改了 [0 1 0]

第一次调用 modifyB没有修改。因为go函数调用为值传递。
操作的底层数组由于是复制指针，所以指向同一个数组。但len和cap则是复制来的。
函数中，是在len之后添加元素，只修改了局部变量x 的len，却不会影响原本的s。
如果在modifyB函数中输入 x[3] 则能输出值。

modifyB(s)
fmt.Println(s) //没有被修改 [0 1 0]

第二次调用 modifyB 则修改了。
因为 s[0:2] 的 len 是2，再追加其实是给x[2]赋值。所以直接修改了底层数组，影响了s

modifyB(s[0:2])
fmt.Println(s) //被修改了 [0 1 2]

modifyC虽然与modifyB类似，但是调用时传递的s[0:2:2] cap 为2，len也为2，此时空间已经不足以append，所以做了扩容，扩容后 ptr 会变。此时x与s指向的已经不是同一个底层数组了。所以不会修改

modifyC(s[0:2:2])
fmt.Println(s) //没有被修改 [0 1 2]

此处 s[0:2:2] 最后一个冒号后面的数字，明确声明了cap的值为2，所以才能不修改原数组。平时应用时，除非用cap(s) == len(s)来显示确认，否则无法确定 s是否会被修改。

其实核心内容有两点：

函数为值复制传递
slice的属性包含指向底层数组的指针、cap和len
据此就能对上面的情况就能做出正确判断了。

copy的坑
如果要做slice复制，需要使用copy(dst, src)函数。

copy复制的元素个数其实是min(len(dst), len(src))。如果dst是一个len=0的slice是无法复制进去的。

真正的用法应当是这样

arr := []int{1, 2, 3}
tmp := make([]int, len(arr))
copy(tmp, arr)