乐观锁与悲观锁

• 乐观锁：每次读数据的时候都认为其他人不会修改，所以不会上锁，而是在更新的时候去判断在此期间有没有其他人更新了数据，可以使用版本号机制。在数据库中可以通过为数据表增加一个版本号字段实现。读取数据时将版本号一同读出，数据每次更新时对版本号加一。当我们更新的时候，判断数据库表对应记录的当前版本号与第一次取出来的版本号值进行比对，如果值相等，则予以更新，否则认为是过期数据。乐观锁适用于多读的应用类型，可以提高吞吐量。
• 悲观锁：每次读数据的时候都认为别人会修改，所以每次在读数据的时候都会上锁，这样别人想读这个数据时就会被阻塞。MySQL中就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁。

ET

Edge Triggered (ET) 边缘触发只有数据到来,才触发,不管缓存区中是否还有数据。

LT(level triggered)是缺省的工作方式，并且同时支持block(阻塞)和no-block(非阻塞) socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．

优点：当进行socket通信的时候，保证了数据的完整输出，进行IO操作的时候，如果还有数据，就会一直的通知你。

缺点：由于只要还有数据，内核就会不停的从内核空间转到用户空间，所有占用了大量内核资源，试想一下当有大量数据到来的时候，每次读取一个字节，这样就会不停的进行切换。内核资源的浪费严重。效率来讲也是很低的。

LT

Level Triggered (LT) 水平触发只要有数据都会触发。

ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知。请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once).

优点：每次内核只会通知一次，大大减少了内核资源的浪费，提高效率。

缺点：不能保证数据的完整。不能及时的取出所有的数据。

应用场景： 处理大数据。使用non-block(非阻塞)模式的socket。

goroutine是go的核心，没有goroutine，go就没什么意思了👿。goroutine离不开协程，线程和并发，所以下面会说说相关的内容。

协程

协程(coroutine)其实就是一个函数，方法或者例程（routine）。一般情况下函数都是在用户线程下面执行的，线程的调度由内核触发，所以函数在执行过程中，用户线程没办法控制函数的执行调度，只能任由内核主宰。协程就不同，它可以由用户线程控制调度，在任何时候调度协程的执行。函数在执行时，内核调度会陷入内核并保存当前线程的栈和上下文，然后恢复之前被停止线程继续执行，代价比较高。而协程的调度，不用陷入内核，用户线程只是保存当前协程的栈和上下文，恢复之前的被停止协程继续执行。

还有种说法是说函数是协程的一种特例。因为函数只有在return语句才会返回，而协程可以在任何时刻返回。

协程很早就提出来了，可是在现在才火起来吧，大概由于某种语言（lua）的广泛使用吧。而go更是把协程用到底，基本可以理解go的所有代码都跑在协程下，并用goroutine来代表它自己的协程。

启动一个mysql

用docker很容易就起一个mysql的环境了，我的github repo docker-code,有例子

1
2

cd mysql
sudo docker-compose up

此文章除了说g1,还顺带总结了一些其他概念，mark之👿

本文首先简单介绍了垃圾收集的常见方式，然后再分析了G1收集器的收集原理，相比其他垃圾收集器的优势，最后给出了一些调优实践。

什么是垃圾回收

首先，在了解G1之前，我们需要清楚的知道，垃圾回收是什么？简单的说垃圾回收就是回收内存中不再使用的对象。

垃圾回收的基本步骤

回收的步骤有2步：

• 查找内存中不再使用的对象
• 释放这些对象占用的内存

查找内存中不再使用的对象

只剩下这个没有mark了，偏偏这时候，面试被问到，悲剧了😢

jdk6和jdk7中的实现

设计思路

ConcurrentHashMap采用了分段锁的设计，只有在同一个分段内才存在竞态关系，不同的分段锁之间没有锁竞争。相比于对整个Map加锁的设计，分段锁大大的提高了高并发环境下的处理能力。但同时，由于不是对整个Map加锁，导致一些需要扫描整个Map的方法（如size(), containsValue()）需要使用特殊的实现，另外一些方法（如clear()）甚至放弃了对一致性的要求（ConcurrentHashMap是弱一致性的）。

ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock）。ConcurrentHashMap中的HashEntry相对于HashMap中的Entry有一定的差异性：HashEntry中的value以及next都被volatile修饰，这样在多线程读写过程中能够保持它们的可见性，代码如下：

1
2
3
4
5

static final class HashEntry<K,V> {
        final int hash;
        final K key;
        volatile V value;
        volatile HashEntry<K,V> next;

很好理解的动画，一看就懂了👿

这篇文章通过一个有效的例子描述了一个名为Paxos 的分布式一致性算法。

分布式一致性算法用于使一组计算机能够就单个值达成一致，例如通常使用两阶段或三阶段提交做出的提交或回滚决策。只要选择一个值，算法的其他值就没有关系了。

在分布式系统中，这很难，因为机器之间的消息可能会丢失或无限期延迟，或者机器本身可能会发生故障。

Paxos保证节点只会选择单个值（意味着它保证安全），但不保证在大多数节点不可用时能不能去到值

玩了很久的kafka，现在总结下吧，当然通过别人的文章来总结还是事半功倍的👿

架构图

如上图，一个kafka架构包括若干个Producer（服务器日志、业务数据、web前端产生的page view等），若干个Broker（kafka支持水平扩展，一般broker数量越多集群的吞吐量越大），若干个consumer group，一个Zookeeper集群（kafka通过Zookeeper管理集群配置、选举leader、consumer group发生变化时进行rebalance）。

一直很好奇final的类字段在class文件是怎么表示的，所以用javap看看怎么回事,也顺便复习下字节码指令👿

没有final修饰的类的静态字段

定义一个类

1
2
3
4
5
6
7

public class test{
  public static String str="严";

  public static void main(String[] args){
        System.out.println(str);
  }
}