python爬虫cookie登录、ip代理、互斥锁、死锁

1.爬虫程序添加cookie登录

在爬取“个人主页”的信息时，这个时候我们需要加一些身份信息，在哪儿加呢？ 在 cookie。cookie 中保存了用户的登录状态。

复制 cookie 信息，添加到 headers 中，然后再发起请求：

2. ip代理设置

在爬虫的过程中，我们经常会遇见很多网站采取了防爬取技术，或者说因为自己采集网 站信息的强度和采集速度太大，给对方服务器带去了太多的压力。

如果你一直用同一个代理 ip 爬取这个网页，很有可能 ip 会被禁止访问网页，所以基本 上做爬虫的都躲不过去 ip 的问题。

通常情况下，爬虫用户自己是没有能力去自己维护服务器或者是自己搞定代理 ip 的问题的，一来是因为技术含量太高，二来是因为成本太高。

当然，也有很多人会在网上放一些免费的代理 ip，但是从实用性、稳定性以及安全性来考虑，不推荐大家使用免费的 ip。网上公布的代理 ip 不一定是可用的，很可能你在使用过 程中会发现 ip 不可用或者已失效的情况。所以现在，许许多多的代理服务器应运而生，基本都能提供 ip 代理的服务，区别在于价格和有效性。

如果需要使用代理，你可以通过为任意请求方法提供 proxies 参数来配置单个请求：

3.互斥锁

互斥锁：当多个线程几乎同时修改某一个共享数据的时候，需要进行同步控制。线程同步能够保证多个线程安全访问“竞争资源”，最简单的同步机制就是引用互斥锁。互斥锁为资 源引入一个状态：锁定/非锁定状态。某个线程要更改共享数据时，先将其锁定，此时资源 状态为“锁定”，其它线程不能更改;直到当前线程释放资源，将资源变成"非锁定"状态，其它 的线程才能再次锁定该资源。互斥锁保证了每次只有一个线程进行“写操作”，从而保证多个线程数据正确性。

在 threading 模块当中，定义一个 Lock 类，可以方便的处理锁定：

分析：一个变量被锁住之后，必须解锁才可以重新使用。否则不可使用。而且锁住之后 只能运行一个线程，降低了效率。

锁的好处：

（1）确定了某段代码只能由一个线程从头到尾完整地执行。
（2）全局变量的安全

锁的坏处：

（1）阻止了多线程的并发执行，包含锁的某段代码实际上只能以单线程模块执行，效率大大地下降了。
（2）由于可以存在多个锁，不同的线程持有不同的锁，并试图获取对方持有的锁的时，可能会造成“死锁”。

4.死锁

死锁概念：在线程间共享多个资源的时候，如果两个线程分别占有一部分资源并且同时等待对方的资源时，就会造成死锁。尽管死锁很少发生，但一旦发生就会造成应用的停止响应。

死锁的两种情况：
（1）同一个线程先后两次调用 lock，在第二次调用时，由于锁已经被自己占用，该线程会挂起等待自己释放锁，由于该线程已被挂起而没有机会释放锁，因此它将一直处于挂起等待状态，变为死锁；
（2）线程 A 获得了锁 1，线程B 获得了锁 2，这时线程 A 调用 lock 试图获得锁 2，结果是需要挂起等待线程 B 释放锁 2，而这时线程 B 也调用lock试图获得锁 1，结果是需要挂起等待线程 A 释放锁 1，于是线程 A 和 B 都在等待对方释放自己才释放，从而造成两个都永远处于挂起状态，造成死锁。

产生死锁的必要条件：

1 互斥条件：指线程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一 个线程占用。如果此时还有其它线程程请求资源，则请求者只能等待，直至占有资源的进程 用毕释放。

2 请求和保持条件：指线程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求线程阻塞，但又对自己已获得的其它资源保持不放。

3 不剥夺条件：指线程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时 由自己释放。

4 环路等待条件：指在发生死锁时，必然存在一个线程——资源的环形链，即线程集合 {P0，P1，P2，···，Pn}中的P0 正在等待一个P1 占用的资源；P1 正在等待P2 占用的资源，……Pn 正在等待已被 P0 占用的资源。

死锁避免：

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、线程调度等方面注意如何能够不让这四个必要条 件成立，如何确定资源的合理分配算法，避免线程永久占据系统资源。此外，也要防止线程 在处于等待状态的情况下占用资源，在系统运行过程中，对线程发出的每一个系统能够满足 的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配。因此，对资源的分配要给予合理的规划。

5.银行家算法原理（选学）

银行家算法是避免死锁的一种重要方法。

操作系统按照银行家制定的规则为线程分配资 源，当线程首次申请资源时，要测试该线程对资源的最大需求量，如果系统现存的资源可以 满足它的最大需求量则按当前的申请量分配资源，否则就推迟分配。当线程在执行中继续申 请资源时，先测试该线程已占用的资源数与本次申请的资源数之和是否超过了该线程对资源 的最大需求量。若超过则拒绝分配资源，若没有超过则再测试系统现存的资源能否满足该进 程尚需的最大资源量，若能满足则按当前的申请量分配资源，否则也要推迟分配。