线程死锁
死锁是由于多个线程间相互等待资源,而又不释放资源导致的无穷无尽的等待
造成死锁的条件
- 互斥条件:一个资源每次只能被一个线程使用
- 请求与保持条件:一个线程因请求资源而阻塞时,对已获得的资源保持不放
- 不剥夺条件:线程已获得的资源,在未使用完之前,不能强行剥夺
- 循环等待条件:若干线程之间形成一种头尾相连的循环等待资源关系
只有以上四个条件同时满足时,才会造成死锁,所以破坏死锁的方式也就是只要使得四个条件中的一个不被满足即可
在使用redis操作字符串时发现会变成乱码,这是因为RedisTemplate默认是使用的是JdkSerializationRedisSerializer序列化方式,这里可以使用StringRedisTemplate来进行操作,StringRedisTemplate中默认使用的是StringRedisSerializer
也可以对RedisTemplate进行配置,设置其序列化方式
1 | @Configuration |
保证系统中一个类只有一个实例,并提供一个访问它的全局访问点,根据实例化时机的不同分为两种,饿汉式和懒汉式
饿汉式单例在单例类被加载的时候就实例化一个对象交给自己的引用,其是线程安全的
1 | public class Singleton { |
HTTP的缓存对于web的性能是有很大提升的,在客户端请求服务器时会查询是否有对应的缓存数据,如果没有,则需要请求服务器;如果有,则将数据存储至浏览器的缓存中。
其有两种缓存规则
在进行响应时可以在响应头中来标注需要进行缓存(HTTP1.0中使用的是Expires,HTTP1.1中使用的是Cache-Control),在使用Expires时,其值为数据的到期时间,在进行下一次请求时,如果请求时间小于服务端返回的到期时间,则直接使用缓存数据;
在使用Cache-Control时,Cache-Control常见的取值有
示例:Cache-Control: no-cache, no-store, max-age=0, must-revalidate
在HTTP1.0中,使用Expires来判断资源的refresh或stale
在HTTP1.1中,在1.0的基础上增加了一些cache的新特性,当缓存对象的Age超过Expires时会变成stale对象