一.多线程
1.线程间的通信
通过一个线程,可以操作另外一个线程的状态
2.在什么时候使用通信
当多个线程操作的是同一个资源,但是操作的动作(功能)不同.
3.等待唤醒机制
多线程进行协调操作
wait():等待
notify():唤醒(随机唤醒)
notifyAll():唤醒所有的等待线程
一个线程如果等待,当等待结束以后在原来等待的地方开始往下执行。
注意:
这些方法必须在同步中使用
必须使用资源锁对象来调用
保证这些锁对象是同一个锁对象
二.线程池
就是用来承载线程的容器。
为什么会有线程池的出现,解决了什么问题?
因为当我们去创建一个线程和销毁一个线程的时候,都是会使用本地资源来创建和销毁.
在无形中已经严重的浪费了我们本地资源.为了解决这样的问题,节约资源.使用了线程池.
当我们启动程序的时候,我们会创建出来一部分线程.而是把这些线程都放入到线程池中养起来.
什么时候使用线程,到线程池中去拿.如果使用完成,把线程归还给线程池。这个线程并没有销毁.
线程池的出现就是为了解决线程创建和销毁资源浪费的问题.
线程池的好处:
节约了资源
提高了响应的速度
提高对线程的管理
线程池的使用:
配置一个线程池是比较复杂的,尤其是对线程池原理不是特别清楚的情况下,很有可能配置的不是最优的。
使用官方建议的方式完成 Executors 工厂类 来创建线程池对象
Executors
public static ExecutorService newFixedThreadPool(int size) 返回线程池对象
(创建有界的线程池对象 可以指定最大线程个数)
submit(Runnable task) 提交线程任务
使用步骤
1:获取线程池对象
2:创建要提交的线程池任务
3:提交任务
不做 4:关闭线程池
三.Lambda表达式:他是jdk.8开始有的(2014年)
1.什么是函数式编程思想(思想:就是解决问题的方式)
面向过程:
强调是完成一件事的过程,如何去完成
面向对象:
强调是对象,找谁去完成
函数式编程:
强调的是结果,做什么.
他是不关注形式
注意:必须是一个接口,而且该接口中只能有一个抽象方法,Lamabda操作的是接口中的抽象方法,和非抽象方法没有关系。
2.Lambda标准格式
三部分组成
一些参数
一个箭头
一段代码
标准格式
(参数列表) -> {代码语句}
格式说明
小括号内的语法 与 方法参数列表一致 无参留空 多个参数使用,隔开(代表声明参数)
-> 新的语法格式 代表指向操作 传递的动作
大括号内的语法 与 传统 方法体 要求基本一致 (就是代表方法体)
3.可推导可省略
对于lambda 可推导可省略
Lambda强调 做什么 而不是 怎么做
所以所有可以上下文推断的信息 都可以省略
比如 上面的代码
invokeCalc(120,130,(x, y)-> x+y);
省略规则
1:小括号 参数类型可以省略
2:如果小括号中只有一个参数 则小括号可以省略,参数类型也可以省略
3:如果大括号 有且只有一句话 则无论是否有返回值 都可以省略大括号 return 以及语句的分号
4.什么时候使用Lamabda表达式
1.如果一个接口中,只有一个抽象方法的时候。
2.具备上下文推断
注意:
如果一个方法中的参数是一个接口类型的,而且该接口中只有一个抽象方法.可以使用Lamabda表达式
如果一个接口中,只有一个抽象方法,这种接口称之为"函数式接口"
PS:
- [ ] 能够理解线程通信概念
多个线程间 使用同一资源 线程执行动作不一样
- [ ] 能够理解等待唤醒机制
就是 有效的完成多个线程间通信的机制
举例子
吃包子案例 一个生产者 与 一个消费者问题
- [ ] 能够描述Java中线程池运行原理
使用 池 管理了 线程对象
减少了 创建与销毁 提高了性能
- [ ] 能够理解函数式编程相对于面向对象的优点
简化了 强调的是 做什么 而不是 怎么做
- [ ] 能够掌握Lambda表达式的标准格式
(参数列表)->{代码}
一些参数 一个箭头 一些代码
- [ ] 能够使用Lambda标准格式使用Runnable与Comparator接口
- [ ] 能够掌握Lambda表达式的省略格式与规则
1:小括号中的参数类型可以省略
2:小括号中如果是一个参数 括号可以省略
3:大括号中如果只有一句话 那么 不管有没有 返回值 retun关键字 {} ;都可以省略
- [ ] 能够使用Lambda省略格式使用Runnable与Comparator接口
- [ ] 能够通过Lambda的标准格式使用自定义的接口(有且仅有一个抽象方法)
- [ ] 能够通过Lambda的省略格式使用自定义的接口(有且仅有一个抽象方法)
- [ ] 能够明确Lambda的两项使用前提
1:代替的 有且只有一个抽象方法的接口
2:可以上下文推导 一定是在 在使用我们 接口中的 抽象方法的地方 代替接口的