<Java并发性和多线程>读后感

连接:
[url]http://tutorials.jenkov.com/java-concurrency/synchronized.html[/url]

这个人的文章写的相当的清楚，


部分章节的总结：

[b]Starvation and Fairness:[/b]

由于调度的不公平性，某线程可能得到较少的执行机会，甚至得不到执行的机会，这种情况叫做starvation.

解决的方式是：线程在锁上排队，唤醒的时候，按照排队的顺序来唤醒，就解决了不公平的问题(具体的实现有比较多的细节，我还没有仔细读)

[b]Nested Monitor Lockout:[/b]

lock过程：就是在拿到上次lock之后，继续lock内层的lock,

而unlock的时候，也是先拿上层的lock，然后拿内层的lock，然后notify。

导致的结果是，lock在wait在内存的object的时候，只释放了内层object的锁，而继续持有外层object的锁。 unlock过程，在想拿到外层object的锁的时候拿不到，造成了永远不能notify的问题。和死锁类似。

[b]Slipped Conditions：[/b]

一个常见的错误，一个线程check一个条件的时候，根据check的结果做一件事情。但是check之后，这个条件被另外的线程改变，导致的结果是check失效

[b]Locks:[/b]

lock的来源：由sychronized关键字实现，提供更强的功能。

这里面有一个哲学：就是执行速度快的语句可以放在sychronized里，lock的实现也是利用这一点。（我推测是因为sychonized锁，会busy waiting，也就是说，如果sychronized拿不到锁的话，会不停的retry，消耗CPU的资源，相对较快执行的语句，busy waiting消耗很少的CPU计算能力）。lock利用wait，消除busy waiting，节省CPU资源。

ReenterLock，是说的已经拿到一个对象的锁，然后再次进入的，也是没问题的。

FairLock，synchronizde的锁并不是公平的，通过排队队列，实现公平的唤醒

[u][i]可以跟UNIX的mutex+condition对比，sychroinzed关键词，相当于mutex和condtion这些原始材料，Lock则是通过这写原始材料组合成的可用工具。[/i][/u]