什么是GIL锁，有什么作用？python的垃圾回收机制是什么样的？解释为什么计算密集型用多进程，io密集型用多线程。

1 什么是gil锁，有什么作用？
2 python的垃圾回收机制是什么样的？
3 解释为什么计算密集型用多进程，io密集型用多线程。

1 什么是gil锁，有什么作用？

1 GIL：Global Interpreter Lock又称全局解释器锁。本质就是一个互斥锁，
2 保证了cpython进程中得每个线程必须获得这把锁才能执行，不获得不能执行
3 使得在同一进程内任何时刻仅有一个线程在执行
4 gil锁只针对于cpython解释器----》JPythonPyPyCPython***作用：***1 保护Python对象免受多线程并发访问的破坏。2 确保在多线程环境中只有一个线程执行Python字节码。3 GIL的存在使得在CPU密集型任务中，Python的多线程并不能充分发挥多核CPU的优势。因为只有一个线程能够执行字节码，其他线程会被阻塞。***为什么要有gil锁？***python是动态强类型语言，因为有垃圾回收机制，如果同一个进程下有多个线程同时在执行，垃圾回收是垃圾回收线程【同一个进程下变量是共享的】，该线程做垃圾回收时，如果其他线程在运行，就可能会出并发安全的问题【数据安全的问题】，由于当时，只有单核cup【即便开启多线程，同一时刻，也只有一个线程在运行】，作者就强行做了一个GIL锁，保证在一个进程内，同一时刻只有一个线程执行，目的是为了防止垃圾回收线程做垃圾回收时，出现数据紊乱问题，所以加了gil锁**垃圾回收**是垃圾回收线程，它在执行的时候，其他线程是不能执行的，而限于当时的条件，只有单核cpu，所以作者直接做了个GIL锁，保证一个进程内同一时刻只有一个线程在执行。python使用引用计数为主，标记清楚和隔代回收为辅来进行内存管理。所有python脚本中创建的对象，都会配备一个引用计数，来记录有多少个指针来指向它。当对象的引用技术为0时，会自动释放其所占用的内存。假设有2个python线程同时引用一个数据（a=100，引用计数为1），2个线程都会去操作该数据，由于多线程对同一个资源的竞争，实际上引用计数为3，但是由于没有GIL锁，导致引用计数只增加1（引用计数为2）这造成的后果是，当第1个线程结束时，会把引用计数减少为1；当第2个线程结束时，会把引用计数减少为0；当下一个线程再次视图访问这个数据时，就无法找到有效的内存了

import threading# 共享变量
counter = 0def count_up():global counterfor _ in range(1000000):counter += 1def count_down():global counterfor _ in range(1000000):counter -= 1# 创建两个线程分别执行计数操作
t1 = threading.Thread(target=count_up)
t2 = threading.Thread(target=count_down)# 启动线程
t1 .start()
t2.start()# 等待两个线程执行完成
t1 .join()
t2.join()print("Counter:", counter)在上述代码中，我们有两个线程，一个递增 counter，一个递减 counter。
理论上，counter 的最终值应该是 0。但是由于GIL的存在，多线程并发执行时，由于GIL的保护，
实际上可能并不会得到正确的结果。在这个例子中，counter 的最终值可能不是 0，
因为两个线程在修改 counter 时可能会发生竞争条件。

2 python的垃圾回收机制是什么样的？

1 参考文章：https://www.jianshu.com/p/52ab268901142 什么是垃圾回收？编程语言在运行过程中会定义变量--->申请了内存空间---》后期变量不用了---》这个内存空间应该释放掉，有些编程语言，这个操作，需要程序员自己做(c)，像java，python，go这些语言，都自带垃圾回收机制，可以自动回收内存空间，gc机制。3 不同语言垃圾回收的方式是不一样的，python是使用如下三种方式做gc，以引用计数为主，标记-清除和分代回收两个算法为辅(1)引用计数算法(reference counting)：每个对象都有一个引用次数的计数属性，如果对象被引用了，那这个数就会 加1，如果引用被删除，引用计数就会 减1，那么当该对象的引用计数为0时，就说明这个对象没有被使用，垃圾回收线程就会把它回收掉，释放内存。-有问题：循环引用问题---》回收不了(2) 标记-清除算法(Mark and Sweep)：-解决引用计数无法回收循环引用的问题对象之间通过引用连在一起，节点就是各个对象，从一个根对象向下找对象，可以到达的标记为活动对象，不能到达的是非活动对象，而非活动对象就是需要被清除的。(3) 分代回收算法(Generational garbage collector)：-分代回收是解决垃圾回收效率问题算法原理是Python把对象的生命周期分为三代，分别是第0代、第1代、第2代。每一代使用双向链表来标记这些对象。每一代链表都有总数阈值，当达到阈值的时候就会出发GC回收，将需要清除的清除掉，不需要清除的移到下一代。以此类推，第2代中的对象存活周期最长的对象。注意：python垃圾回收最核心是：引用计数----》标记清除解决引用计数的循环引用问题---》分代回收解决垃圾回收的效率问题。

import gc# 创建一个循环引用的对象
class CircularReference:def __init__(self):self.circular_ref = None# 创建循环引用
obj1 = CircularReference()
obj2 = CircularReference()
obj1.circular_ref = obj2
obj2.circular_ref = obj1# 手动断开引用，使引用计数变为零
obj1 = None
obj2 = None# 手动触发垃圾回收
gc.collect()# 由于循环引用，垃圾回收器会将它们回收
print(gc.garbage)在上述代码中，`CircularReference` 类创建了两个对象 `obj1` 和 `obj2`，
它们相互引用形成了循环引用。当手动断开对 `obj1` 和 `obj2` 的引用后，手动调用 `gc.collect()` 
来触发垃圾回收。垃圾回收器会检测到这个循环引用并将其回收。回收后，`gc.garbage` 列表中将包含被
回收的对象，我们可以通过查看这个列表来确认回收是否成功。

3 解释为什么计算密集型用多进程，io密集型用多线程。

计算是消耗cpu的：代码执行，算术，for都是计算
io不消耗cpu：打开文件，写入文件，网络操作都是io-如果遇到io，该线程会释放cpu的执行权限，cpu转而去执行别的线程由于python有GIL锁，开启多条线程，同一时刻，只能有一条线程在执行。
如果是***计算密集型***开了多线程，同一时刻，只有一个线程在执行，多核cpu，就会浪费多核优势；
如果是计算密集型，我们希望多个核(cpu),都干活，同一个进程下绕不过gil锁。所以我们开启多进程，
gil锁只能锁住某个进程中的线程，开启多个进程，就能利用多核优势。***io密集型***只要遇到io，就会释放cpu执行权限，进程内开了多个io线程，线程多半都在等待，
开启多进程是不能提高效率的，反而开启进程很耗费资源，所以使用多线程即可。计算密集型任务主要是由CPU计算驱动，对CPU的利用率要求较高。
I/O密集型任务主要是由I/O操作驱动，对CPU的利用率较低。

计算密集型任务使用多进程

import multiprocessingdef calculate_square(numbers):result = []for number in numbers:result.append(number * number)print("Result (in process):", result)if __name__ == "__main__":numbers = list(range(1, 6))# 使用多进程process = multiprocessing.Process(target=calculate_square, args=(numbers,))process.start()process.join()print("Main process continues...")

I/O密集型任务使用多线程

import threading
import timedef simulate_io_operation():print("Start I/O operation...")time.sleep(2)  # 模拟I/O操作，比如文件读写或网络请求print("I/O operation completed.")if __name__ == "__main__":# 使用多线程t1= threading.Thread(target=simulate_io_operation)t2= threading.Thread(target=simulate_io_operation)t1.start()t2.start()t1.join()t2.join()print("Main thread continues...")

在这两个例子中，计算密集型任务使用了多进程，而I/O密集型任务使用了多线程。这是因为计算密集型任务中的 GIL 限制了多线程的效果，而I/O密集型任务中可以充分利用多线程的并发性。