5月22日
OA(办公自动化),电子商务涉及到的线程都比较少;经典例子:生产者消费者模式。
线程
进程和线程:
- 进程:包含多个线程,被分配了cpu时钟周期和内存的应用程序。进程内部是串行的
- 线程:可以独立运行,一个进程里面共享资源的小进程,共享500M的内存。
- 开辟线程 == 开辟了可以申请资源的单元
- 例子:泡方便面,电水壶烧水,一边撕调料倒入桶中
程序就是进程,进程包含了线程
这是进程:
线程的状态:
实现线程
- 继承Thread类
- 最多的API可以使用
- 实现Runnable接口
- callable接口
线程安全问题
原子性:
- 可以使用synchronized或者lock保证原子性
- 原子性:多个操作要么全部执行 && 执行的过程不被打断,要么都不执行。
- 原子操作:不会被线程调度机制打断的操作。
synchronized加锁
在servlet里面比较常见,因为servlet是单例的。
没有加锁会把别人的数据给挤掉,servlet是单例的,后请求的会覆盖前面单例的属性。(在JVM中的 i++操作)
让servlet的速度加快
不能设置成员变量,秒杀就是抢资源
12306脚本就是直接用代码去抢票,而不用解析页面。
直接访问的是请求购票的最后一步。
可见性:
eg: 多个线程里面操作是不可见的,一般情况下线程1做完操作之后不会立即把新的值刷新到主内存中,会先在自己的工作内存中呆一会;而线程2是看不到另一个线程的工作内存中的新值的。
- 需要经过store、load来进行交互
- 当我们的变量被volatile修饰的时候一旦被修改,会马上更新到主内存之中。
- 而 synchronized和 lock也可以保证可见性,因为同一时间只有一个线程在执行同步代码块,执行完毕之后释放锁之前会把变量刷回主内存中,保证了可见性。
活跃性问题(锁的问题):
锁
- 死锁:环形的等待锁关系,双方都在等待对方释放锁,永远的阻塞。
- 活锁:双方都在不断的修改自身的状态,但是一直保持着这种持续不断的修改避让状态。
- 饥饿:无异常但是却无法运行
- 高优先级的线程一直占用CPU,低优先级的一直处于等待状态;
- 一些线程被永久的阻塞在一个等待进入同步块的状态,而其他的线程一直占用同步块。
- “哲学家用餐”:两把叉子才能吃!那肯定有人饿着,要么因为优先级不够,要么没有释放锁
多线程性能问题:
- 线程创建开销
- 线程上下文切换需要CPU分配时间片给线程
解决多线程的性能问题:【线程池】
第一:降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的销耗。
第二:提高响应速度。当任务到达时,任务可以不需要等待线程创建就能立即执行。
第三:提高线程的可管理性。线程是稀缺资源,如果无限制的创建,不仅会销耗系统资源,还会降低系统的稳定性,使用线程池可以进行统一的分配,调优和监控。
生产者消费者模式
线程 操作 资源类
1、创建资源类
2、资源类里创建同步方法、同步代码块
class Product111 {
int num = 0;
Lock lock = new ReentrantLock();
public void increment() {
lock.lock();
try {
num++;
System.out.println(Thread.currentThread().getName() + "操作后" + num);
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
public void decrement() {
lock.lock();
try {
num--;
System.out.println(Thread.currentThread().getName() + "操作后" + num);
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
public class Product03 {
public static void main(String[] args) {
Product111 p = new Product111();
new Thread(p::increment, "小光").start();
new Thread(p::decrement, "小光").start();
new Thread(p::increment, "小光").start();
}
}
可重入锁:
class X {
private final ReentrantLock lock = new ReentrantLock();
public void m() {
lock.lock();
//block until condition holds
try {
//method body
} finally {
lock.unlock();
}
}
}