Java技术学习路线
2022-01-13 17:45:15 0 举报AI智能生成
登录查看完整内容
Java技术学习路线
作者其他创作
大纲/内容
如何做CTO
定价要考虑渠道利益
子主题
渠道制胜策略
所谓营销渠道，也就是分销渠道，他指产品由生产者向最终消费者或用户流动所经过的途径或缓解，或者说是指企业将产品传递给最终购买者的过程中所使用的各种中间商的集合
减少交易行为就可以节省交易成本
营销渠道策略又称渠道战略，他是整个营销系统的重要组成部分，是规划中的重中之重，他对降低企业成本和提高企业竞争力具有重要意义
了解渠道策略含义及作用
营销中介机构的类型多种多样
影响渠道建立的因素也很多
渠道具有非常大的惯性
渠道级数是指产品所经过渠道的环节数目，用渠道的级数表示渠道的长度
技术性强的产品需要售前和售后服务水平
保鲜要求高
顾客少，地理上集中
企业规模大，有一定的营销能力
短渠道
单价低，标准化的日用品
顾客多，地理上分散
企业规模小
长渠道
考虑渠道的长度
渠道宽度定义：企业在某一市场上并列地使用多少个中间商
如：生产和经营名牌
如：高档消费品
如：技术性强，价格较高的工业用品
独家分销是指在一定地区，一定时间内只选择一家中间商经销或代理，授予对方独家经营权
中间商经营积极性高
责任心强
优点
市场覆盖面相对较窄，而且有一定风险
缺点
独家分销
广泛分销又称密集性分销，即使用尽可能多的中间商从事产品的分销，使渠道尽可能的加宽，价格低，购买频率搞得日用消费品，工业用品中的标准件，通用小工具等，多采用此种分销方式
市场覆盖面广，潜在顾客有较多的机会接触到产品
中间商的经营积极性较低，责任心差
广泛分销
如：消费品
如：工业用品，零部件
选择性分销，在市场上选择部分中间商经营本企业产品，介于广泛分销和独家分销一种分销形式
选择性分销
渠道制定宽度策略
考虑渠道的宽度
学会如何制定企业营销渠道
熟知营销渠道策略
如何管理企业营销渠道
洞察市场
市场与营销
每个线程都有一个程序计数器，是线程私有的，就是一个指针，指方法区中的方法字节码（用来存储指向的地址，也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，计划可以忽略不记
PC寄存器
方法区是被所有线程共享的，所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单的说，所有定义的方法的信息都保存在该区域，此区域属于共享区间静态变量+常量+类信息（构造方法/接口定义）+运行时常量池存在方法区中
常量池是方法区的一个部分，class文件除了有类的版本，字段，方法，接口等描述信息外，还有一项信息就是常量池，这部分内容将在类加载后进入方法区的运行时常量池中存放
方法区
本地接口的作用是融合不同的编程语言为Java所用
Native Interface 本地接口
栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命周期是跟随线程的生命周期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就over，生命周期和线程一直，是线程私有的。8中基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配
本地变量：输入参数和输出参数以及方法内的变量
栈操作：记录出栈，入栈的操作
栈帧数据：包扣文件，方法等
栈存储什么？
栈是什么
新生区（Young Generation Space）
养老区(Tenure grneration space)
永久区(Permanent Space)
jdk1.7以前一个jvm实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类，方法，常变量放到堆内存中，保存所有的引用类型的真实信息，以方便执行器执行，堆内存分为三部分：
由于永久代内存经常不够用或发生内存泄露，爆出异常java.lang.OutOfMemoryError: PermGen
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。理论上取决于32位/64位系统可虚拟的内存大小。可见也不是无限制的，需要配置参数。
为什么废弃永久代
实战
堆
JVM体系结构
双亲委派模型的式作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完全这个加载请求时，子加载器才会尝试自己去加载。
栈->程序=算法+数据结构
程序=框架+业务逻辑
类加载器
jvm体系结构
对象创建
连续分配地址空间，通过指针碰撞的方式分配内存，如图
可能会出现线程安全问题，多线程同时分配空间的时候如果没有做线程安全会导致同一个空间被两个线程同时占有，导致数值错误
指针碰撞
会有一个分配的历史记录，通过历史记录标记哪些是空余的，如下图：
空间列表
对象分配内存
线程同步
为每一个线程分配一个空间，如下图：
本地线程分配缓冲（TLAB）
线程安全问题
Mark Word
好处：对象地址变化对栈没有影响
缺点是两侧访问
句柄：在java中我们在实例化完对象后，在对其进行操作时，用来去操作对象的就叫做句柄。他代表了当前对象的唯一一个标识，并不能代表当前对象的内存地址。例如：Tree t1 = new Tree();t1就属于当前新建对象的句柄，它指向新建对象的实例，我们通过他去操作对象。
缺点：是两侧访问
优点：对象地址变化对其没有影响
使用句柄
优点：速度快
缺点：变化之后要重新指向
使用指针
对象的访问定位
对象的结构
在对象中添加一个引用计数器，当有地方引用这个对象的时候，计数器+1，当时失效的时候，计数器-1
-verbose:gc-XX:+PrintGCDetails
引用计数器无法解决双向引用的问题
引用计数法
作为GCROOt的对象：
虚拟机栈
方法区的类属性所引用的对象
方法区的常量所引用的对象
本地方法栈所引用的对象
可达性分析法
如何判断对象为垃圾对象
free-list 对象分配的空间列表
标记清除
复制算法
标记整理
分代算法
垃圾回收算法策略：
单线程的垃圾收集器
Serial
多线程的垃圾收集器
ParNew
gc设置太频繁会影响吞吐量
Parallel Scavenge
GMS收集器无法处理浮动垃圾，可能出现”Concurrent mode failure”失败而导致一次Full GC产生。原因是GMS清除阶段，用户线程还在运行着，所以不断会有新的垃圾产生，而这一部分垃圾是没有办法在这一次清除，只好留到下一次再清理。也是由于GMS并发清除时，用户线程还在运行着，所以要为用户线程保留足够的内存空间。默认设置下，GMS在老年代使用了68%的空间后激活，如果应用中老年代增涨不是很快，可以适当调高该值：-XX:CMSInitiatingOccupancyFraction若GMS运行期间，预留的空间满足不了应用程序的需求，就会触发一次”Concurrent mode failure”，这时候虚拟机启动备选方案，临时启用SerialOld收集器来重新进行老年代的垃圾收集。如果-XX:CMSInitiatingOccupancyFraction设置过高，很容易导致Concurrent mode failure，反而降低性能GMS还有一个缺点：由于GMS采用的是标记清除算法，这意味着每次回收可能产生大量的碎片，导致可能找不到足够大的内存区域分配给大对象，这时不得不提前出发一次Full GC
标记清除收集器，工作在老年代是一种以获取最短回收停顿时间为目标的收集器收集算法：采用的是标记-清除算法实现
CMS
既可以在新生代，也可以再老生带收集
G1
ZGC
垃圾回收器：
概要
逃逸分析，对象或者变量有没有出方法的范围
栈上分配，依据逃逸分析方法把没有分配的在栈上进行分配
逃逸分析与栈上分配
如何回收
垃圾回收
GC调优
Class文件是一组8位字节码为基础的单位的二进制流，各个数据项目严格按照顺序紧凑的排列在class文件之中，中间没有添加任何分隔符，这使得整个class文件中存储的内容几乎全部是程序运行的必要数据，没有空隙存在
当遇到需要占用8位字节以上的空间的数据项时，则会按照高位在前的方式分割成若干个8位字节进行存储。
class 文件只有两种数据类型：无符号数和表
Class文件结构
性能调优
jvm调优
理解B+tree的索引机制
索引能极大的减少存储引擎需要扫描的数据量
索引可以把随机IO变成顺序IO
索引可以帮助我们在进行分组、排序等操作时，避免使用临时表
为什么要用索引
二叉树查找
所有的节点的高度差不会超过1
数据处的（高）深度决定着他的IO操作次数，IO操作耗时大
它太深了
每一个磁盘块（节点/页）保存的数量太小了
没有很好的的利用操作磁盘IO的数据交换特性，也没有利用好磁盘IO的预读能力（空间局部性原理），从而带来频繁的IO操作
IO操作非常耗时
它太小了
mysql不用平衡二叉树的原因：
平衡二叉树
多路平衡查找树，B-Tree
支节点不保存数据，所有的数据都放到叶子节点
加强版多路平和查找树，B+Tree
B+Tree节点关键字搜索采用闭合区间
B+Tree非叶子节点不保存数据相关信息，只保存关键字和子节点的引用
B+关键字对应的数据保存在叶子节点中
B+叶子节点是顺序排列的，并且相邻节点具有顺序引用的关系
B+ Tree与B-Tree的区别
为什么选择B+Tree
为什么是B+Tree
.myd表定义文件是每个存储引擎都会有的
索引是保存在.MYI文件中
B+Tree索引的体现形式
离散性越高，索引的选择性越好
列的离散型
最左匹配原则
联合索引
如果查询列可通过索引节点中的关键字直接返回，则该索引称之为覆盖索引
覆盖索引可以减少数据库IO，将随机IO变为顺序IO，可提高查询性能
覆盖索引
索引补充
下面我们看个例子来理解：name的列的离散性 x1 = 5 : 5 = 1sex的列的离散性 x2 = 2 : 5 = 0.4x1>x2，所以sex的列的离散性低，可选择性差。可选择性差是什么意思呢？比如有如上100W的数据，现在我们要查找sex=男的，那么在索引中我们可选择的范围太大了，因为只有男或者女，查询效率就很低在mysql查询优化器中，如果列的离散性低的话，可能就不走索引，直接全表扫描
列的离散性在索引中是一种很重要的指标。列的离散性 x = count(distinct col) : count(col)比例越大，离散性越高，选择性就越好
列的离散性
能不能用到索引还是要基于列的离散性
索引的使用注意事项
理解mysql的体系结构
1，插拔式的插件方式
2，存储引擎是指定在表之上的，即一个库中的每一个表都可以指定专用的存储引擎
3，不管表采用什么样子的存储引擎，都会在数据区，产生对应的一个frm文件
插拔式存储引擎
用的较少，一般会用应用缓存代替，比如Redis
CSV存储引擎
各大存储引擎介绍
2，查询缓存
3，查询优化处理
调用插件式的存储引擎的原子API的功能进行执行计划的执行
4，查询执行引擎
1、有需要做缓存的，执行缓存操作
开始生成一条结果时，MySQL就开始往请求方逐步返回数据，好处：MySQL服务器无需保存过多的数据，浪费内存用户体验好，马上就拿到了数据
2、增量的返回结果
5，返回客户端
业务驱动
测试驱动
慢查询日志
如何定位慢SQL
事务
锁
MVCC
Mysql查询优化
基于查询执行路径理解查询机制
MySQL调优
MYSQL
Eureka
服务注册与发现
Netflix oss Ribbon
服务调用
负载均衡
Hystrix
服务熔断
服务降级
服务消息队列
spring cloud config
配置中心管理
zuul
服务网关
服务监控
全链路追踪
自动化构建
定时任务与调度
分布式架构应该具备
1，解耦是降低业务耦合度
2，重用是关心复用
3，微服务强调的是RESTFUl
面向服务（SOA）与微服务的区别就是SOA注重重用，微服务注重解耦
分布式是部署模型
SOA与微服务都属于分布式
分布式与微服务的区别
共同点就是都是服务化思想的最佳实践方向
SOA是微服务的超集
从单体架构到微服务
运维上的困难
服务的管理（服务注册）
服务的稳定性（限流，熔断）
服务的链路监控
服务治理
微服务带来的困扰
SpringBoot+dubbo 做微服务
因为springboot提供一种标准，可以使不同团队提供更好的合作
构建自动化运维体系也更加简单
为什么用springboot来整合dubbo呢？
很多公司用dubbo来做服务治理
简述Service Mesh
微服务治理之Alibaba or Netflix
分布式服务治理
MQ是基于AMQP协议实现的，即Advanced Message Queuing Protocl，一个提供统一消费服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件同产品，不同的开发语言等条件的限制
可靠性
灵活的路由
消息集群
高可用
多种协议
多语言客户端
管理界面
插件机制
RabbitMQ的特性
工作模型
基本介绍
Java API编程
进阶知识
Spring配置方式集成RabbitMQ
分布式消息通信之RabbitMQ
分布式消息RocketMQ
官网:https://redis.io/topics/data-types-intro
Redis诞生历程
RDBMS
NOSQL
数据库与NOSQL
特性与分析
定位与特性
服务安装
客户端安装
上手
String
Hash
根据插入顺序排序的字符串元素的集合。它们基本上是链表
List
类似于Sets的排序集合，但每个字符串元素都与一个称为score的浮点值相关联。元素总是按它们的分数排序，因此与Sets不同，可以检索一系列元素
Set
Sorted Set
这是一个概率数据结构，用于估计集合的基数。
Hyperloglog
可以使用特殊命令像位数组一样处理字符串值：您可以设置和清除单个位，计数所有设置为1的位，找到第一个设置或未设置的位，等等。
Geo
提供抽象日志数据类型的类地图项的仅追加集合。
Streams
类型
存储类型
基本操作命令
底层原理
1、缓存
2、分布式Session
3、set NX EX 分布式锁
4、incr 全局ID
5、Incr 计数器
6、incr 限流
用0，1标记用户是否在线
7、位操作
应用场景
维度
Redis数据类型
基础篇
pub/sub发布订阅
transactions事务
LUA脚本
高级特性
Redis为什么这么快
内存回收
持久化机制
原理剖析
高特性与原理篇
防止故障（可用性）
扩容（水平扩展）
负载（性能）
为什么需要集群
主从复制
可用性保证：Redis Sentinel
RedisSharding(jedis)
客户端
Twemproxy-Twitter+LVS+Keepalived
Codis-豌豆荚
代理
RedisCluster
查询路由
分布式有哪些解决方案
分布式篇
pipeline
Jedis
Luttece
Redission
客户端介绍
分布式锁实现
应用
数据一致性
热点数据发现
缓存击穿
缓存穿透
雪崩
高并发
实战篇
分布式缓存之Redis
ZK是通过一个特殊的文件系统，帮我们系统分布式系统间的协调。
节点特性（持久化，临时节点，有序节点，同级节点必须唯一，临时节点不能存在子节点）
它很像数据结构当中的树，也很像文件系统的目录
树是由节点所组成，Zookeeper 的数据存储也同样是基于节点，这种节点叫做 Znode但是，不同于树的节点，Znode 的引用方式是路径引用，类似于文件路径：/汽车/宝马这样的层级结构，让每一个 Znode 节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离。
Zookeeper 的数据模型
集群方案（leader，follower）
1 防止单点故障
必须要有leader，leader、master、Redis-cluster
2 每个节点的数据一致的
3 leader 挂了怎么办
leader是整个zookeeper的核心，它起到了主导整个集群的作用，比如事务请求的调度和处理，保证事务处理的顺序性
follower是处理客户端的非事务请求以及请求转发给leader服务器，follower主要处理读请求，如果是写请求，那么这个请求会转发给leader去处理
observer是观察者的角色，相当于了解集群中的情况变化并且同步，不参与事务请求的投票
除了Leader和Follow模式之外，还有第三种模式：Observer模式。
分布式事务，2PC
4 如何保证事务的一致性
zookeeper的设计思想
Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议 ，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。
使用一个单一的主进程（Leader）来接收并处理客户端的事务请求（也就是写请求），并采用了Zab的原子广播协议，将服务器数据的状态变更以 事务proposal （事务提议）的形式广播到所有的副本（Follower）进程上去。
保证一个全局的变更序列被顺序引用。Zookeeper是一个树形结构，很多操作都要先检查才能确定是否可以执行，比如P1的事务t1可能是创建节点\"/a\"，t2可能是创建节点\"/a/bb\"，只有先创建了父节点\"/a\"，才能创建子节点\"/a/b\"。为了保证这一点，Zab要保证同一个Leader发起的事务要按顺序被apply，同时还要保证只有先前Leader的事务被apply之后，新选举出来的Leader才能再次发起事务。
当主进程出现异常的时候，整个zk集群依旧能正常工作。
Zab 协议实现的作用
当leader失去了过半的follower节点的联系
当leader服务挂了，集群就会进入崩溃恢复阶段
1.已经被处理的消息不能丢失，当leader收到合法的数量的follower的ack以后，就会向各个follower广播消息（commit命令），同时自己也会commit这条事务消息。如果follower节点收到commit命令前。leader挂了，会导致部分节点收到commit，部分节点没有收到。那么zab协议需要保证已经被处理的消息不能丢失
2.被丢弃的消息不能再次出现，当leader收到事务请求，并且还未发起事务投票之前，leader挂了
数据恢复
崩溃恢复
原子广播
1.zxid是最大的
2.epoch的概念，每生产一个新的leader，那么新的leader的epoch会+1，zxid是64位的数据，低32位表示消息计数器（自增）、高32位（epoch编号）
zab的设计思想
Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。
发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。
同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。
广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。
Zab协议原理
zab协议
zookeeper
技术架构的发展从单体到分布式，是一种顺势而为的架构演进，也是一种被 逼无奈的技术变革。架构的复杂度能够体现公司的业务的复杂度，也能从侧 面体现公司的产品的发展势头是向上的。 和传统的单体架构相比，分布式多了一个远程服务之间的通信，不管是 soa 还是微服务，他们本质上都是对于业务服务的提炼和复用。那么远程服务之 间的调用才是实现分布式的关键因素。 而在远程通信这个领域，其实有很多的技术，比如 Java 的 RMI、WebService、 Hessian、Dubbo、Thrift 等 RPC 框架，现在我们接触得比较多的应该就是 RPC 框架 Dubbo 以及应用协议 Http。其实每一个技术都是在某一个阶段产 生它的价值，随着架构的变化以及需求的变化，技术的解决方案也在变。所 以我们才需要不断的学习
远程通信背景
我认为到目前为止，还只是满足了通信的基础需求，但是当企业开始大规模 的服务化以后，远程通信带来的弊端就越来越明显了。比如说1. 服务链路变长了，如何实现对服务链路的跟踪和监控呢?2. 服务的大规模集群使得服务之间需要依赖第三方注册中心来解决服务的发现和服务的感知问题3. 服务通信之间的异常，需要有一种保护机制防止一个节点故障引发大规模 的系统故障，所以要有容错机制4. 服务大规模集群会是的客户端需要引入负载均衡机制实现请求分发而这些对于服务治理的要求，传统的 RPC 技术在这样的场景中显得有点力 不从心，因此很多企业开始研发自己的 RPC 框架，比如阿里的 HSF、Dubbo; 京东的 JSF 框架、当当的 dubbox、新浪的 motan、蚂蚁金服的 sofa 等等 又技术输出能力的公司，都会研发适合自己场景的 rpc 框架，要么是从 0 到 1 开发，要么是基于现有的思想结合公司业务特色进行改造。而没有技术输 出能力的公司，遇到服务治理的需求时，会优先选择那些比较成熟的开源框笔记仅仅提供与课后复习，为了达到更好的学习效果，请自己进行梳理，转载请注明《咕泡学院》 架。而 Dubbo 就是其中一个
大规模服务化对于服务治理的要求
dubbo 主要是一个分布式服务治理解决方案，那么什么是服务治理?服务 治理主要是针对大规模服务化以后，服务之间的路由、负载均衡、容错机制、 服务降级这些问题的解决方案，而 Dubbo 实现的不仅仅是远程服务通信， 并且还解决了服务路由、负载、降级、容错等功能。
什么是dubbo
为什么要用Dubbo
网络通信
序列化
负债均衡
链路监控
通信异常容错
dubbo核心
Dubbo
分布式
Atomikos
Jotm
分布式事务的解决方案
强一致性（ACID）
消息队列来辅助
弱一致性（BASE）
CAP理论，Base
支付宝的异步通知，每个订单的异步通知实行分频率发送，15s->3m 10m 30 m 1h 2h 6h 15h
主动查询（调单查询）
最大化重试
最终一致性
避免分布式事务方法
分布式事务一致性
分布式事务
开源框架
docker脑图
docker
场景：针对同一类型问题，有多种处理方式，每一种都能独立解决问题；算法需要自由切换的场景；需要屏蔽算法规则的场景；
策略模式 使用的就是面向对象的继承和多态机制，从而实现同一行为在不同场景下具备不同实现。
策略模式 本质：分离算法，选择实现
主要解决在有多种算法相似的情况下，使用 if...else 或 switch...case 所带来的复杂性和臃肿性。
优点算法多样性，且具备自由切换功能；有效避免多重条件判断，增强了封装性，简化了操作，降低出错概率；扩展性良好，策略类遵顼 里氏替换原则，可以很方便地进行策略扩展；缺点策略类数量增多，且所有策略类都必须对外暴露，以便客户端能进行选择；
策略模式
观察者模式
简单工厂模式(Simple Factory Pattern)是指由一个工厂对象决定创建出哪一种产品类 的实例，但它不属于 GOF，23 种设计模式
简单工厂适用 于工厂类负责创建的对象较少的场景，且客户端只需要传入工厂类的参数，对于如何创 建对象的逻辑不需要关心。
简单工厂模式
工厂方法模式(Fatory Method Pattern)是指定义一个创建对象的接口，但让实现这个 接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行。在工厂方法 模式中用户只需要关心所需产品对应的工厂，无须关心创建细节，而且加入新的产品符 合开闭原则。
工厂方法模式主要解决产品扩展的问题，在简单工厂中，随着产品链的丰富，如果每个 课程的创建逻辑有区别的话，工厂的职责会变得越来越多，有点像万能工厂，并不便于 维护
工厂方法适用于以下场景:1、创建对象需要大量重复的代码。 2、客户端(应用层)不依赖于产品类实例如何被创建、实现等细节。 3、一个类通过其子类来指定创建哪个对象。工厂方法也有缺点:1、类的个数容易过多，增加复杂度。2、增加了系统的抽象性和理解难度。
工厂方法模式
抽象工厂模式(Abastract Factory Pattern)是指提供一个创建一系列相关或相互依赖，对象的接口无需指定具体的类
抽象工厂模式
工厂模式
在实例使用之前，不管你用不用，我都先new出来再说，避免了线程安全问题
饿汉式
懒汉式
注册登记式
枚举式
序列化与反序列化的时候出现多例
解决一个并发访问的时候线程安全问题保证单例的技术方案有很多种：
单例模式
常用的设计模式
1、Runnable接口
2、继承Thread类（本质上是对Runnable接口的实现）
3、Callable/Future带返回值的线程
4、ThreadPool
Java中如何应用线程
文件跑批
收益文件
对账文件
BIO模型优化
多线程应用场景
1、NEW；2、RUNNABLE（运行状态）；3、BLOCKED；4、WAITING；5、TIMED_WAITING；6、TERMINATED（终止状态）；
1、出现锁等待的时候会出现BLOCKED状态；2、TIMED_WAITING带等待时间；3、WAITING 不带等待时间
线程一共有6中状态
生命周期
通过start（）的方法
start()方法会调用start0()的本地方法
本地方法会调用操作系统来实现不同的线程创建和启动指令
线程的启动
interrupt（）线程终止，底层就是用_interrupted标记去判断当前的线程的中断标记然后去处理和自己定义一个volatile成员属性一样，然后再线程里面去判断这个属性是否true还是false一样
可以通过Thread.interrupt()去重置
interruptException 来进行重置
线程终止
1，修饰实例方法
2，修饰静态方法
3，修饰代码块
synchronized的基本使用
synchronized(重量级锁)
三种方式代表了锁的力度
对象头就是MarkWord
1，对象在内从中的布局
无锁
偏向锁
轻量级锁
当去获得锁的时候如果存在线程竞争会把线程挂起来，等获得锁的线程释放以后再唤醒线程，这就叫重量级锁，性能消耗很大
重量级锁
synchronized的锁的存储
线程安全
并发基础
并发编程
线程可以合理的利用多核心CPU资源，提高线程的吞吐量
Java Bean是由Applet Bean演变而来
EJB（Enterprise Java beans）
POJO（plain ordinary Java Object 简单的javabean）
一切从bean开始
基于pojo的轻量级和最小侵入性编程
通过依赖注入和面向接口松耦合
基于切面和惯性进行声明式编程
通过切面和模板减少样板式代码
spring简化开发四个基本策略
DI AOP 依赖于IOC
DI IOC AOP 之间的关系
Spring 5
Spring 命名规则
Context结尾的是入口
定位：用Reader结尾的是定位
加载：BeanDefinition保存类信息，包括OOP关系是加载
注册：Factory、Context 就是把用户所定义的Bean放到IOC容器中也就是个Map
Spring 实现的基本思路
ClassPathXmlApplictionContext 通过main启动
DispatchServlet
FileSystem
Plugin
Lisenter
Spring IOC的启动入口
Spring 依赖注入
Spring5核心原理
初始化最核心的方法就是refresh（）
把所有的bean重新构造一遍
spring中最核心的方法refresh();
maven
服务于框架的框架
Spring Boot的基本认识
1，maven的目录结构（默认会以jar的方式打包/默认会有resource文件夹）
2，spring-boot-starter-web 内置Tomcat，resource/{template/static}
3，默认application.properties
什么是约定优于配置
从Spring常见的注解切入，@Configuration/@ComponentScan
Spring Boot核心之自动装配的原理
Spring中
Spring boot的自动装配机制的原理
Spring Boot
图片2
分布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶
springCloud定义
https://github.com/spring-projects/spring-boot/releases/
Git源码地址
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Release-Notes
通过上面官网发现，Boot官方强烈建议你升级到2.X以上版本
springboot2.0新特性
官网看springboot版本
springboot版本选择
https://github.com/spring-projects/spring-cloud
git源码地址
https://spring.io/projects/spring-cloud
https://www.bookstack.cn/read/spring-cloud-docs/docs-index.md
spring cloud中文文档
官网
官网看cloud版本
springcloud版本选择
https://spring.io/projects/spring-cloud#overview
依赖
springcloud和springboot之间的依赖关系如何看
Eureka采用cs的设计架构，EurekaServer 作为服务注册功能的服务器，他是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server 来监控系统中的各个微服务是否正常运行。在服务注册与发现中，有一个注册中心。当服务启动的时候会把当前自己服务器的信息比如服务地址通讯地址等以别名的方式注册到注册中心上。另一方面（消费者|提供服务者），以该别名的法式注册中心上获取实际的服务通讯地址，然后再实现本地RPC调用RPC远程调用框架核心设计思想：在注册中心，因为使用注册中心管理服务与服务之间的一个依赖关系（服务治理概念）。在任何RPC远程框架中都会有一个注册中心（存放服务地址相关信息）
Eureka Server 提供服务注册服务各个微服务节点通过配置启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以再界面上直接观看到
EurekaClien通过注册中心进行访问是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮训（round-robin）负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会服务注册表中把这个节点服务移除（默认90s）
Eureka包含两个组件：Eureka server 和 Eureka Client
Eureka停止更新
Eureka停止更新了怎么办
SpringCloud整合Zookeeper替代Eureka
Zookeeper
Consul
Nacos 推荐（经过了百万的流量考验）
服务注册中心
Ribbon
LoadBalancer
Feign
OpenFign
Hystrix（不在更新）
resilience4j(国外在用，国内很少)
sentienl(推荐)
Zuul（不在使用了）
gateway
Config不推荐使用
Nacos
服务配置
Bus
服务总线
springcloud部分组件停更替换方案
Eureka(服务注册中心) Consul/etcd/zookeeper
配置中心（Config）
熔断（Hystrix）
SpringCloud 服务治理
spring是 万能的粘合剂
Spring中大部分的组件都是做整合
SpringCloud 是一种标准
Spring Cloud 生态
Spring Cloud 提供了一些可以让开发者快速构建分布式应用的工具
JDK 8新特性
技术提高
一种工具
一份报告
一页纸项目管理表格（one page project manager）OPPM
项目的中心
需要完成的工作的细节
如何做（how）
做什么（what）
为什么要做（why）
度量上与实际上何时完成
时间线可能是弹性的
何时完成（when）
硬性成本：咨询/机器成本
软性成本：雇佣成本
花费（how much）
谁负责哪些任务
谁应该得到哪些嘉奖
谁需要帮助
谁做项目（who）
项目的核心要素
项目管理
大数据
技术栈
职业：架构师
0 条评论
回复 删除
下一页
