一.多线程
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：可以上下文推导 一定是在 在使用我们 接口中的 抽象方法的地方 代替接口的