文章目录
 
1. 全局解释器锁(GIL)
2. 为何多线程访问内存要加锁

 
1. 全局解释器锁(GIL)
 
CPython解释器在内存管理上不是线程安全的, 所以创建出了一个GIL锁机制, 阻止多线程并行
GIL锁只存在于CPython中, 对于JPython等就没有这个概念, 但由于JPython用的人比较少, 所以支持的模块也比较少, 最常用的还是CPython
 
2. 为何多线程访问内存要加锁
 
由于存在GIL锁, 所以多线程应该是串行的, 但是为什么访问内存还需要加锁呢?
CPython解释器为了模拟并发执行, 默认会在线程执行100调CPU指令后(0.005s)尝试进行线程切换(修改切换时间, sys模块下sys.setswitchinterval()函数)
线程block后也会释放锁(例如线程执行I/O操作时)

 
 
多线程保证线程安全就是让多个线程执行的情况和单线程一样，读的时候是不影响线程安全的，但如果对数据操作，增加或者删除，几个线程同时进行，就会发生删多或者增加多的情况，这时候为了保证线程安全，就可以加对象锁。
 
 
 
并发不是很高的情况下，sychronized性能更好，优先选择，反之reentrantlock在高并发的情况下，性能会提高几十倍。或者使用reentrantlock三个独有的功能就选择reentrantlock：
 
 
 
两者都是可重入锁：都是同一个线程进入会+1，直到为0才释放锁，
 
两者都是阻塞的方式加锁，也就是一个线程进入锁的同步块，其他线程都必须在锁的同步代码块外面等待执行完毕。
 
 
 
Sychronized:Reentranlock:
 
优点不需要自己手动释放锁，jvm会自动释放锁，所以会更安全。Reentranlock需要自己主动用unlock释放锁(必须在finally)，否则线程异常，导致系统宕机
Jvm实现的，是java的关键字，ReentranlockJdk1.5之后提供的类。
锁的是一整个代码块，reenTranlock方法调用实现的，更灵活。
不可以中断，等代码块正常执行完毕释放锁，或者抛出异常。

首先需要说明一点的是：我们一直在强调 redis 是单线程，只是在处理我们的网络请求的时候只有一个线程来处理，一个正式的Redis Server运行的时候肯定是不止一个线程的。
 
为什么redis是单线程的？
 
  官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。
 
为什么redis需要加锁？
 
  我们需要注意的是：redis是单线程这是毋庸置疑的。redis 本身是不会产生并发安全问题的，不需要加锁。再多的 commands 都是 one by one 执行的。
   这里说的加锁是我们为了满足业务在使用的时候，可能会出现并发问题而需要加锁。比如，当一个 redis 服务器同时有多个客户端访问时，每个客户端会有一个线程。客户端访问之间存在竞争。因为存在多客户端并发，所以必须保证操作的原子性。比如银行卡扣款问题，获取余额，判断，扣款，写回就必须构成事务，否则就可能出错。
   在传统单体应用单机部署的情况下，可以使用Java并发相关的锁，如ReentrantLcok或synchronized进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统，渐渐的被部署在多机器多JVM上同时提供服务，这使得原单机部署情况下的并发控制锁策略失效了，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。
   分布式环境下，数据一致性问题一直是一个比较重要的话题，而又不同于单进程的情况。分布式与单机情况下最大的不同在于其不是多线程而是多进程。多线程由于可以共享堆内存，因此可以简单的采取内存作为标记存储位置。而进程之间甚至可能都不在同一台物理机上，因此需要将标记存储在一个所有进程都能看到的地方
   可以用 redis 来实现分布式锁。
 
分布式锁的实现条件
 
1、互斥性：要保证任意时刻，只能有一个客户端持有锁。
 
2、可靠性：要保证系统的稳定性，不能产生死锁。
 
3、一致性：要保证锁只能由加锁人解锁，不能产生A的加锁被B用户解锁的情况。

什么是锁？为什么存在？

 多个线程运行的时候，共享了同一块资源，在访问这块资源的时候就称为临界资源。为了解决这个问题，我们可以为这块资源加上一把锁,只允许一个线程访问这块资源。

 那今天就讲讲互斥锁，自旋锁。
 首先先看看不加锁的情况下多线程共享访问临界资源会发生什么.
 代码很简单，开启10个线程，各加上100000，理想结果应该是10 * 100000，好的，来试试吧
 

```c
#include <stdio.h>
#include <pthread.h>

#define THREAD_NUM 10
int count = 0;
void *proc(void *arg)
{
    int i = 0;
    while( i++ < 100000) {
        count++;
        usleep(1);
    }   
}

int main() 
{
    int i = 0;
    pthread_t id[THREAD_NUM] = {0};

    for (i = 0; i < THREAD_NUM; i++) {
        pthread_create(&id[i], NULL, proc, NULL);
    }   

    while (1) {
        printf("total %d\n", count);
        sleep(1);
    }   
    return 0;
}

 
运行结果
 
[guojunfeng@guojunfeng mutex]$ ./mutex 
total 9
total 158333
total 317776
total 476812
total 634098
total 793269
total 943308
total 997398
total 997398
total 997398
total 997398
total 997398
 
很明显结果997398跟理想状态1000000少了一些，丢失的那些值去哪了呢？为什么会导致这种现象，是谁在作怪？
 可能很多同学会说count是临界资源没有加锁造成的，那为什么没有加锁达不到理想值呢？这块临界资源到底发生了什么事？
 因为count++翻译成指令，反汇编看看，其实是有三个指令，读 加 写。
 
[guojunfeng@guojunfeng mutex]$ objdump -S -d mutex > count
//找到count++的位置
400642:   8b 05 00 0a 20 00       mov    0x200a00(%rip),%eax        # 601048 <__TMC_END__>
400648:   83 c0 01                add    $0x1,%eax
40064b:   89 05 f7 09 20 00       mov    %eax,0x2009f7(%rip)        # 601048 <__TMC_END__>  
 
大概意思是：
 读取保存count到临时变量eax
 edx再自增+1
 存储edx到count

 本来理想状态是以下这样交互达到正确的++
 绝大多数的状态是这样的，线程1完成三个指令后切换线程2执行
 
线程1
线程2
mov 0x200a00(%rip),%eax
add $0x1,%eax
mov %eax,0x2009f7(%rip)
mov 0x200a00(%rip),%eax
add $0x1,%eax
mov %eax,0x2009f7(%rip)
但有少数情况并不是上面这样的，竞争资源比较大的时候，会变成以下状态
 
线程1
线程2
mov 0x200a00(%rip),%eax
mov 0x200a00(%rip),%eax
add $0x1,%eax
mov %eax,0x2009f7(%rip)
add $0x1,%eax
mov %eax,0x2009f7(%rip)

如果此时的count值是10，那线程1执行了第一条指令取值10至eax，切换线程2进来执行完成三条指令，此时eax是11赋值给了count寄存器。
 再次切换回线程1，线程1的临时变量eax还是10，再进行自增后11赋值给了count寄存器。
 最终这俩个线程++后的值是11，并不是12。所以这就可以解释上面代码为什么没达到理想值了。

 
那我们要怎么做才能让线程1执行++的时候是不让别的线程进来呢？答案就是执行阶段加上一把锁。
 
互斥锁和自旋锁：
 
#include <stdio.h>
#include <pthread.h>

#define THREAD_NUM 10
int count = 0;
pthread_mutex_t mutex;
pthread_spinlock_t spinlock;
void *proc(void *arg)
{
    int i = 0;
    while( i++ < 100000) {
#if 1
        pthread_mutex_lock(&mutex);
        count++;
        pthread_mutex_unlock(&mutex);
#else
        pthread_spin_lock(&spinlock);
        count++;
        pthread_spin_unlock(&spinlock);
#endif
        usleep(1);
    }   
}

int main() 
{
    int i = 0;
    pthread_t id[THREAD_NUM] = {0};
    pthread_mutex_init(&mutex, NULL);
	pthread_spin_init(&spinlock, PTHREAD_PROCESS_SHARED);
	
    for (i = 0; i < THREAD_NUM; i++) {
        pthread_create(&id[i], NULL, proc, NULL);
    }   

    while (1) {
        printf("total %d\n", count);
        sleep(1);
    }   
    return 0;
}
 

打开互斥锁代码就其实加了4行，因为是演示，锁的销毁就没处理，int pthread_mutex_destroy（pthread_mutexattr_t *attr）；
 定义了一个mutex的互斥锁，进行初始化，在进行count++的时候lock，执行完再unlock。

 
看下运行结果
 
[guojunfeng@guojunfeng mutex]$ ./mutex 
total 10
total 158645
total 316088
total 475166
total 635056
total 795857
total 955740
total 1000000
total 1000000
total 1000000
total 1000000
 
其实打开spinlock开关结果也是正确的。
 加锁的这期间是做了什么事情呢？
 spinlock自旋，在线程切换的时候会一直在等待释放锁。
 mutex互斥，在线程切换的时候可能会干其它的事，不会一直瞎等。

 那分别应用在什么场景下？
 mutex是对于处理时间比较长的，比较复杂的
 spinlock对于时间较短，比较简单的
 以线程切换作为一个标准，如果这个处理时间超过切换线程的代价，就采用mutex，相反采用spinlock。