python死锁案例_Python每日3题什么是死锁？

每日3题是麦叔的面试系列专题之一&＃xff0c;每天包括初级&＃xff0c;中级&＃xff0c;高级难度题目各一道。

每日3题&＃xff0c;100天之后成为大牛&＃xff01;

如果有不明白的&＃xff0c;给麦叔留言。

[Easy] python中进程与线程的使用场景&＃xff1f;

思考30秒再往下翻...

多进程适合在CPU密集操作(cpu操作指令比较多&＃xff0c;如位多的的浮点运算)。

多线程适合在IO密性型操作(读写数据操作比多的的&＃xff0c;比如爬虫)

[Normal] 什么是死锁&＃xff1f;

思考30秒再往下翻...

若干子线程在系统资源竞争时&＃xff0c;都在等待对方对某部分资源解除占用状态&＃xff0c;结果是谁也不愿先解锁&＃xff0c;互相干等着&＃xff0c;程序无法执行下去&＃xff0c;这就是死锁。

GIL锁 全局解释器锁

作用&＃xff1a;限制多线程同时执行&＃xff0c;保证同一时间只有一个线程执行&＃xff0c;所以cython里的多线程其实是伪多线程&＃xff01;

所以python里常常使用协程技术来代替多线程&＃xff0c;协程是一种更轻量级的线程。

进程和线程的切换时由系统决定&＃xff0c;而协程由我们程序员自己决定&＃xff0c;而模块gevent下切换是遇到了耗时操作时才会切换

三者的关系&＃xff1a;进程里有线程&＃xff0c;线程里有协程。

下面的例子,程序会永远卡在那里

[Hard] Session,COOKIE,JWT的理解

思考30秒再往下翻...

为什么要使用会话管理

众所周知&＃xff0c;HTTP协议是一个无状态的协议&＃xff0c;也就是说每个请求都是一个独立的请求&＃xff0c;请求与请求之间并无关系。但在实际的应用场景&＃xff0c;这种方式并不能满足我们的需求。举个大家都喜欢用的例子&＃xff0c;把商品加入购物车&＃xff0c;单独考虑这个请求&＃xff0c;服务端并不知道这个商品是谁的&＃xff0c;应该加入谁的购物车&＃xff1f;因此这个请求的上下文环境实际上应该包含用户的相关信息&＃xff0c;在每次用户发出请求时把这一小部分额外信息&＃xff0c;也做为请求的一部分&＃xff0c;这样服务端就可以根据上下文中的信息&＃xff0c;针对具体的用户进行操作。所以这几种技术的出现都是对HTTP协议的一个补充&＃xff0c;使得我们可以用HTTP协议&＃43;状态管理构建一个的面向用户的WEB应用。

Session 和COOKIE的区别

这里我想先谈谈session与COOKIEs,因为这两个技术是作为开发最为常见的。那么session与COOKIEs的区别是什么&＃xff1f;个人认为session与COOKIEs最核心区别在于额外信息由谁来维护。利用COOKIEs来实现会话管理时&＃xff0c;用户的相关信息或者其他我们想要保持在每个请求中的信息&＃xff0c;都是放在COOKIEs中,而COOKIEs是由客户端来保存&＃xff0c;每当客户端发出新请求时&＃xff0c;就会稍带上COOKIEs,服务端会根据其中的信息进行操作。当利用session来进行会话管理时&＃xff0c;客户端实际上只存了一个由服务端发送的session_id,而由这个session_id,可以在服务端还原出所需要的所有状态信息&＃xff0c;从这里可以看出这部分信息是由服务端来维护的。

除此以外&＃xff0c;session与COOKIEs都有一些自己的缺点&＃xff1a;

COOKIEs的安全性不好&＃xff0c;攻击者可以通过获取本地COOKIEs进行欺骗或者利用COOKIEs进行CSRF攻击。使用COOKIEs时,在多个域名下&＃xff0c;会存在跨域问题。session 在一定的时间里&＃xff0c;需要存放在服务端&＃xff0c;因此当拥有大量用户时&＃xff0c;也会大幅度降低服务端的性能&＃xff0c;当有多台机器时&＃xff0c;如何共享session也会是一个问题.(redis集群)也就是说&＃xff0c;用户第一个访问的时候是服务器A&＃xff0c;而第二个请求被转发给了服务器B&＃xff0c;那服务器B如何得知其状态。实际上&＃xff0c;session与COOKIEs是有联系的&＃xff0c;比如我们可以把session_id存放在COOKIEs中的。

JWT是如何工作的

首先用户发出登录请求&＃xff0c;服务端根据用户的登录请求进行匹配&＃xff0c;如果匹配成功&＃xff0c;将相关的信息放入payload中&＃xff0c;利用算法&＃xff0c;加上服务端的密钥生成token&＃xff0c;这里需要注意的是secret_key很重要&＃xff0c;如果这个泄露的话&＃xff0c;客户端就可以随机篡改发送的额外信息&＃xff0c;它是信息完整性的保证。生成token后服务端将其返回给客户端&＃xff0c;客户端可以在下次请求时&＃xff0c;将token一起交给服务端&＃xff0c;一般是说我们可以将其放在Authorization首部中&＃xff0c;这样也就可以避免跨域问题。

支持麦叔&＃xff0c;请点在看&＃xff0c;谢谢&＃xff01;