架构师技术栈

实现了Collection接口

List接口特性∶是有序的，元素是可重复的

允许元素为rull

Vector

LinkedList

ArrayList

实现了Collection接口

set接口特性︰无序的，元素不可重复

底层大多数是Map结构的实现

常用的三个子类都是非同步的

HashSet

LinkedHashSet

TreeSet

底层是散列表+红黑树。初始容量为16，装载因子为0.75，每次扩容2倍

允许为null，存储无序

非同步

散列表容量大于64且链表大于8时，转成红黑树

Key的哈希值会与该值的高16位做异或操作，进一步增加随机性

当散列表的元素大于容量*装载因子时，会再散列，每次扩容2倍

如果hashCode相同，key不同则替换元素，否则就是散列冲突

底层是散列表+红黑树+双向链表，父类是HashMap

允许为null，插入有序

非同步

提供插入顺序和访问顺序两种，访问顺序是符合LRU算法的，一般用于扩展(默认是插入顺序)

迭代与初始容量无关(迭代的是维护的双向链表)

大多使用HashMap的API，只不过在内部重写了某些方法，维护了双向链表

底层是红黑树，保证了时间复杂度为log(n)

可以对其进行排序，使用Comparator或者Comparable

只要compare或者CompareTo认定该元素相等，那就相等

非同步

自然排序(手动排序)，元素不能为null

底层是散列表+红黑树，支持高并发操作

key和value都不能为null

线程是安全的，利用CAS算法和部分操作上锁实现

get方法是非阻塞，无锁的。重写Node类，通过volatile修饰next来实现每次获取都是最新设置的值

在高并发环境下，统计数据(计算size...等等)其实是无意义的，因为在下一时刻size值就变化了。

验证

准备

解析

给定一个类名，加载一个雷，返回代表这个类的Class 实例，如果找不到类，则返回异常。

根据给定的字节码流b定义一个类，off表示位置，len表示长度。该方法只有子类可以使用,

查找一个类，也是只能子类使用，这是重载ClassLoader时，最重要的系统扩展点。这个方法会被loadClass 调用，用于自定义查找类的逻辑，如果不需要修改类加载默认机制，只是想改变类加载的形式，就可以重载该方法。

同样的，这个方法也只有子类能够使用，他会去寻找已经加载的类，这个方法是final方法，无法被修改。

负责加载<JAVAHOME>/lib目录中的，或者别-Xbootclasspath参数指定的路径。并且是被虚拟机识别的，如rtjar,名字不符合的类库即使放在ib目录中也不会加载。

负责加载<JAVA_HOME>/lib/ext目录中的。或者被java.ext.dirs系统变量所指定的路径中的所有类库。

由于这个类是ClassLoader 中的getsystemClassLoader方法的返回值，也称为系统类加载器，负或加载用户类路径( ClassPath )上所指定的类库，开发者可以直接使用这个类加载器。一般情况下，这个就是程序中默认的类加载器。

│自定义类加载器用于加载一些特殊途径的类，一段也是用户程序类。

在Java平台中，把核心类(rtjar)中提供外部服务，可由应用层自行实现的接口，通常可以称为Service Provider Interface，即 SPl

在rtjar中的抽象类需要加载继承他们的在应用层的子类实现，但是以目前的双亲机制是无法实现的。

也就是讲类加载放在线程上下文变量中。通过Thread.getContextClassLoader()， ThreadsetContextClassLoader(ClassLoader)这两个方法获取和没ClassLoader，这样，rt.,jar中的代码就可以获取到底层的类加载了。

双亲模式是虚拟机的默认行为，但并非必须这么做，通过重觌ClassLoader可以修改该行为。事实上，很多框架和软件都修改了，比如Tomcat ,OSG1。具体实现则是通过重写loadClass 方法，改变类的加载次序。比如先使用自定义类加载器加载，如果加载不到，则交给双亲加载。

最基础的算法

碎片问题

效率问题

基于标记清除的优化算法，使用2块内存，解决内存碎片

缺点是内存缩小了到了原来的一半

现代虚拟机大都采用这种算法

通常做法

解决对象存活率较高的问题

解决额外空间担保问题

老年代的GC使用该算法

在标记清除的基础上整理碎片

新生代

老年代

目的︰根据各个年代的特点采用最适当的收集算法

引用计数

可达性分析

finalize方法

单线程

独占式

复制算法

-XX:UseSerialGc

Client 默认收集器

CMS的备用处理器

-×X:ParallelGCThreadl指定线程数

一般和CPU数量相当

默认

和ParNew类似，但关注吞吐量

Parallel Old

与PS相反,特点

执行过程

3个注意点

特点

设计— Region

收集过程〔4步骤）

GC组合

只收集eden区的GC一

通常等同于Full Gc

这个堆和方法区进行GC

串行收集器，client 的默认GC，分为年轻代 Serial和老年代Serial Old

1.-XX : +UseSerialGc

2.-XX:+ UseParNewGc

3.-XX:+UseParallelGc

日志标记

Serial的多线程版本

1.-XX:+UseParNewGc

2.-XX:+UseConcMarkSweepGc

3.-XX:ParallelGCThreads={value}

日志标记——

java 8默认垃圾收集器，关注吞吐量，自动调优

1.-XX:MaxGCPauseMillis

2.-xX:GCTimeRatio

3.-XX:+ UseParallelGc

4.-XX:+ UseParalleloldGc

5.-XX:UseAdaptiveSizePolicy

注意点∶

线程数量

日志标记

1.-XX:-CMSPrecleaningEnabled

2.-XX:+ UseConcMarkSweepGc

3.-XX:ParallelGCThreads

4.-XX:ConcGcThreads

5.-XX:CMSInitatingOccupancyFraction

6.-XX:+UseCMscompactAtFullCollection

7.-XX:CMSFullGCsBeforeCompaction

8.XX:+CMSClassUnloadingEnabled

9.-XX:CMSInitiatingPermoccupancyFraction

10.-XX:UseCMSInitiatingOccupancyOnly

11.-XX:CMSwaitDuration=200o

日志格式

Java 9的默认垃圾收集器

1.-XX:+ UseG1Gc——开启G1

2.-xx:MaxGCPauseMillis

3.-xX:InitiatingHeapOccupancyPercent

4.-xX:GCPauseIntervalMillis

1 .XC-+Disable&xplicitGc 

2-XX:+ExplicitGCInwokesConcurrent

3.-XX:-ScavengeBeforeFullGcH

、4.-XX:Max TenuringThreshold =fvalue}

5.-XX:TargetSurvivorRatio=value}

6.-XX.TargetsurvivorRatio={value]

7.-XX:-UseTLAB

8. -XX;TLABSize H

9._-xX:+PrintTLAB

10.-XX:+ReslizeTLAB

-XX:+ PrintGCDateStamps

-XX:+PrintGCDetails

-XX:+ PrintGCTimeStamps

-Xloggc:<filename>

-verbose:gc-

-XX:+PrintGCApplicationStopedTime

XX:+PrintTenuringDistribution

-XX:+HeapDumpOnOutOfMemoryError

Jvisualvm

Jprofile

MAT

jinfo

jmap

jcmd

jps

jstat

YGC优化

FGC无法优化时长，只能优化频率

一定带上GC日志

充分利用多核CPU的运算能力

方便业务拆分

频繁的上下文切换

线程安全（常见的避免死锁的方式）

同步 VS 异步

并发 VS 并行

阻塞 VS 非阻塞

临界区 VS 临界资源

继承Thread类

实现Runnable接口

实现Callable或Runnable接口,FutureTask

NEW

RUNNABLE

WAITING

TIMED_WAITING

TERMINATED

BLOCKED

interrupt

sleep

join

yield

实例域

静态域

数组

线程将数据拷贝到工作内存，再刷新到主存。各个线程通过主存中的数据来完成隐式通信

为了提高执行性能，编译器和处理器会对指令进行重排序

针对编译器重排序，编译器重排序规则会禁止一些特定类型的编译器重排序

针对处理器重排序，编译器会在生成指令的时候插入内存屏障来禁止特定类型的处理器重排序

遵守as-if-serial语义的编译器，runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的

如果A happens-before B，则A操作的结果对操作B可见，且A操作在操作B之前执行

如果指令重排序之后的结果，与按照happens-before关系执行的结果一致，则指令可以重排序

站在程序员角度：为编程人员提供了一个类似强内存的内存结构，方便编程

站在编译器和处理器厂商：在不影响正确结果的前提下，可以让编译器和处理器厂商尽情优化

程序顺序规则

volatile变量规则

监视器锁规则

传递性

start规则

join规则

线程中断规则

对象finnalize规则

实例方法（锁的是实例对象）

静态方法（锁的是类对象）

代码块根据配置，锁的是实例对象也可以是类对象

字节码中会添加monitorenter和monitorexit指令

锁的重入性：同一个锁程，不需要再次申请获取锁

共享变量会刷新到主存中，线程每次会从主存中读取最新的值到自身的工作内存中

锁状态

CAS操作

JAVA对象头

轻量级锁

轻量级锁

重量级锁

各种锁的比较

写volatile变量在编译时添加Lock指令

缓存一致性：每个处理器会通过总线嗅探出自己的工作内存中数据是否发生变化(MESI缓存一致性协议 )

写volatile变量会重新刷新到主存中，其他线程读volatile变量会重新从主存中读取最新值

通过在特定位置处插入内存屏障来防止重排序

变量

方法

类

final域为基本类型

final域为引用类型

插入StoreStore和LoadLoad内存屏障

synchronzied

synchronized

volatile

synchronized

volatile

AQS提供给同步组件实现者，为其屏蔽了同步状态的管理，线程排队等底层操作实现者只需要通过AQS提供的模板方法实现同步组件的语义即可

lock（同步组件）是面向使用者的，定义了接口，隐藏了实现细节

重写protected方法，告诉AQS如何判断当前同步状态获取是否成功或者失败

同步组件调用AQS的模板方法，实现同步语义。而提供的模板方法又会调用被重写的方法

实现自定义同步组件时，推荐采用继承AQS的静态内部类

带头结点的双向链表实现的队列

同步状态获取成功则退出；失败则通过addWaiter方法将当前线程封装成节点加入同步队列，acquireQueued方法使得当前线程等待获取同步状态

如果获取同步状态并且是同步队列中的头结点，则表明获取锁成功，并唤醒后继结点

可响应中断式获取锁以及超时获取锁特性的实现原理

锁获取原理

锁释放原理

可响应中断式获取锁以及可超时获取锁特性的实现原理

低16位用来表示写状态，高16位用来表示读状态

当ReadLock已经被其他线程获取或者WriteLock被其他线程获取，当前线程获取WriteLock失败；否则获取成功。支持重入性

WriteLock释放时将写状态通过CAS操作减一

当WriteLock已经被其他线程获取的话，ReadLock获取失败；否则获取成功。支持重入性

通过CAS操作将读状态减一

按照WriteLock.lock()-->ReadLock.lock()-->WriteLock.unlock()的顺序，WriteLock会降级为ReadLock

WriteLock可以通过newCondition方法生成Condition等待队列，而ReadLock无法生成Conditon等待队列

适用于读多写少的应用场景，比如缓存设计上

Condition能够支持不响应中断，而Object不支持

Lock能够支持多个Condition等待队列，而Object只能支持一个

Condition能够支持设置超时时间的await，而Object不能

针对Object的wait方法：await, awaitNanos,...

针对Object的notify/notifyAll方法：signal，signalAll方法

复用AQS的Node类，由不带头结点的链表实现的队列

将调用await方法的线程封装成Node，尾插入到同步队列中，并通过LockSupport.park方法将当前线程置于WAITING状态，直至其他线程通过signal/signalAll方法将其移入到同步队列中，使其有机会在同步队列中通过自旋获取到Lock，从而当前线程才能从await方法处退出

将等待队列的队头结点移入到同步队列中

可阻塞线程以及唤醒线程，功能实现依赖于Unsafe类

LockSupport通过LockSupport.unpark(thread)可以指定哪个线程被唤醒，而synchronized不能

table：元素为Node类的哈希桶数组

nextTable：扩容时的新数组

sizeCtl：控制数组的大小

Unsafe u：提供对哈希桶数组元素的CAS操作

Node：实现Map.entry接口，存放key，value

TreeNode：继承Node，会被封装成TreeBin

TreeBin：进一步封装TreeNode，链表过长时转换成红黑树时使用

ForwardingNode：扩容时出现的特殊结点

tabAt：查询哈希桶数组的元素

casTabAt：设置哈希桶数组中索引为i的元素

setTabAt：设置哈希桶数组中索引为i的元素

数组长度总是会保证为2的幂次方

1.如果当前数组还未初始化，先进行初始化

2.spread方法重哈希（高16位和低16位异或操作），将哈希值与数组长度与运算，确定待插入结点的索引为i

3.当前哈希桶中i处为null，直接插入

4. i处结点不为null的话并且结点hash>0，说明i处为链表头结点。遍历链表，遇到与key相同的结点则覆盖其value，如果遍历完没有找到，则尾插入新结点

5. i处结点不为null的话并且结点状态为MOVED，则说明在扩容，帮助扩容

6.i处结点不为null的话并且结点位TreeBin，则使用红黑树的方式插入结点

7. 插入新结点后，检查链表长度是否大于8，若大于，则转换成红黑树

8. 检测数组长度，若超过临界值，则扩容

减小锁粒度

采用了synchronized而不是lock，大量使用CAS操作

利用了读写分离的思想；当写线程写入数据的时候会复制新建一个新容器，当数据更新完成后，再将旧容器引用指向新容器。读线程感知数据更新是延时的，也就是说COW是牺牲了数据实时性而保证数据最终一致性

由于写线程写数据是在新容器写入的，因此读线程不会被阻塞

相同点

不同点

适用于读多写少的场景，比如系统的黑名单，白名单设置

COW的实现是采用数组，而数组的引用是volatile修饰，但是数组的元素并不是volatile的。因此数据更新只有当volatile引用指向新数组时才会生效

由于在写数据时，会复制，因此可能会出现内存使用瞬间增加，导致minor GC和major GC

只具有数据最终一致性，对数据实时性要求高的场景不合适

采用“空间换时间的”思想，每个线程拥有变量副本，达到隔离线程的目的，线程间不受影响解决线程安全的问题

操作系统

数据存放在由当前线程Thread维护的ThreadLocalMap中，数据结构为当前ThreadLocal实例为key，值为value的键值对

以当前ThreadLocal为键，从当前线程Thread维护的ThreadLocalMap中获取value

从当前线程Thread维护的ThreadLocalMap中删除以当前ThreadLocal实例为键的键值对

底层数据结构

set方法原理

getEntry方法原理

remove原理

造成内存泄露的原因

怎样来解决内存泄漏

为什么要使用弱引用

使用完ThreadLocal后要remove掉

hibernate管理seesion，每个线程维护其自身的session，彼此不干扰

用于解决对象不能被多个线程共享的问题

ArrayBlockingQueue：由数组实现的有界阻塞队列

LinkedBlockingQueue：由链表实现的有界阻塞队列，可指定长度，如果没有指定则为Integer.MAX_VALUE

PriorityBlockingQueue：支持优先级的无界阻塞队列

SynchronousQueue：不存储任何元素阻塞队列

LinkedTransferQueue：由链表实现的无界阻塞队列

LinkedBlockingDeque：由链表实现的无界阻塞队列

DelayQueue：存在实现了Delayed接口的数据的无界阻塞队列

实现原理

主要采用CAS操作以保证线程安全，并且采用了延时更新的策略，提高吞吐量

由Node构成的链式队列

offer方法实现原理

poll方法实现原理

降低资源损耗

提升系统响应速度

提高线程的可管理性

核心线程corePool，阻塞队列workQueue以及最大线程池maxPool三级缓存的工作方式

coolPoolSize：核心线程池的大小

maximumPoolSize：线程池最大容量

keepAliveTime：空闲线程可存活时间

unit：keepAliveTime的时间单位

workQueue：存放任务的阻塞队列

threadFactory：生产线程的工厂类

handler：饱和丢弃策略。共四种：
AbortPolicy，CallerRunsPolicy，DiscardPolicy，DiscardOldestPolicy

shutdown：正在执行任务的线程，将任务执行完。空闲线程以中断的方式关闭

shutdownNow：停止所有线程，包括正在执行任务的线程。返回未执行的任务列表

showdown将线程池状态设置为SHUTDOWN，而shutdownNow将线程池状态设置为STOP

isTerminated来检查线程池是否已经关闭

CPU密集型：Ncpu+1

IO密集型：2Ncpu

任务按照IO密集型和CPU密集型进行拆分

继承了ThreadPoolExecutor，并实现了ScheduledExecutorService

可 延时执行任务：schedule(.....)

可周期执行任务：scheduledAtFixedRate(...)和scheduledWithFixedDelay

scheduledAtFixedRate和scheduledWithFixedDelay的区别：...AtFixedRate不要求任务结束了才开始统计延时时间，而....WithFixedDelay要求从任务结束开始统计延时时间

可周期执行的异步任务，每一次执行完后会重新设置任务下一次执行的任务，并且会添加到阻塞队列中

按优先级排序的有界阻塞队列，底层数据结构是堆

未启动（还未执行run方法），已启动(已执行run方法），已结束（正常结束，被取消，出现异常）

未启动和已启动状态，get方法会阻塞当前线程直到异步任务执行结束

未启动状态时，调用cancel方法后该异步任务永远不会再执行

已启动状态，调用cancel方法后根据参数是否中断当前执行任务的线程

已结束状态，调用cancel方法时会返回false

当一个线程需要等到另一个任务执行结束后才能继续进行时，可以使用futureTask

futureTask同样可以交由executor执行，获取直接调用run方法执行

1.使用Object的wait/notifyAll方式实现

2.使用lock的condition的await/signalAll方式实现

3. 使用blockingQueue方式实现

数据元素除了“属于同一集合”的关系外，没有其他关系。

数据元素之间存在一对一的关系。如：线性表，栈，队列

数据元素之间存在一对多的关系。如：树

数据元素之间存在若干个多对多关系。如：图

将数据结构中各元素按照其逻辑顺序存放于一片连续的存储空间中。如C语言的一维数组。

优点：随机访问快（可以直接计算数据的地址）

缺点：插入、删除效率低，不利于动态增长

数据结构中各元素可以存放到存储器的不同地方，数据元素之间以指针（地址）链接。

缺点：随机访问慢

优点：便于插入、删除和动态增长

在存储数据的同时，建立一个附加的索引表，即索引存储结构 = 数据 + 索引表。索引表存放各数据元素的地址

索引表的组织方式:

根据数据元素的特殊字段（称为关键字key），计算数据元素的存放地址，然后数据元素按地址存放，所得到的存储结构为散列存储结构(或Hash结构)

插入 3，跨越0层。

1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。

2、Hibernate 换数据库只需换方言和驱动就可以。

1、一个调用者想创建一个对象，只要知道其名称就可以了。

2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。

3、屏蔽产品的具体实现，调用者只关心产品的接口。

1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。

2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。

3、设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。

1、QQ 换皮肤，一整套一起换。

2、生成不同操作系统的程序。

1、一个党只能有一个书记。

2、Windows 是多进程多线程的，在操作一个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。

3、一些设备管理器常常设计为单例模式，比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。

1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。

2、避免对资源的多重占用（比如写文件操作）。

1、要求生产唯一序列号。

2、WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。

3、创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。

1、去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"。

2、JAVA 中的 StringBuilder。

1、建造者独立，易扩展。

2、便于控制细节风险。

1、产品必须有共同点，范围有限制。

2、如内部变化复杂，会有很多的建造类。

1、需要生成的对象具有复杂的内部结构。

2、需要生成的对象内部属性本身相互依赖。

1、当一个系统应该独立于它的产品创建，构成和表示时。

2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。

3、为了避免创建一个与产品类层次平行的工厂类层次时。

4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

1、实现克隆操作，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。

2、原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些"易变类"拥有稳定的接口。

1、细胞分裂。

2、JAVA 中的 Object clone() 方法。

1、性能提高。

2、逃避构造函数的约束。

1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。

2、必须实现 Cloneable 接口。

1、资源优化场景。

2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。

3、性能和安全要求的场景。

4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。

5、一个对象多个修改者的场景。

6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。

7、在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。

1、系统需要使用现有的类，而此类的接口不符合系统的需要。

2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。

3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）

1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。

2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。

3、在 LINUX 上运行 WINDOWS 程序。

4、JAVA 中的 jdbc。

1、可以让任何两个没有关联的类一起运行。

2、提高了类的复用。

3、增加了类的透明度。

4、灵活性好。

1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。

2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。

1、猪八戒从天蓬元帅转世投胎到猪，转世投胎的机制将尘世划分为两个等级，即：灵魂和肉体，前者相当于抽象化，后者相当于实现化。生灵通过功能的委派，调用肉体对象的功能，使得生灵可以动态地选择。

2、墙上的开关，可以看到的开关是抽象的，不用管里面具体怎么实现的。

1、抽象和实现的分离。

2、优秀的扩展能力。

3、实现细节对客户透明。

1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。

2、对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。

3、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。

1、您想表示对象的部分-整体层次结构（树形结构）。

2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

1、算术表达式包括操作数、操作符和另一个操作数，其中，另一个操作符也可以是操作数、操作符和另一个操作数。

2、在 JAVA AWT 和 SWING 中，对于 Button 和 Checkbox 是树叶，Container 是树枝。

1、高层模块调用简单。

2、节点自由增加。

1、Component 类充当抽象角色，不应该具体实现。

2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。

1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。

2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。

1、扩展一个类的功能。

2、动态增加功能，动态撤销。

1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。

2、定义系统的入口。

1、去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。

2、JAVA 的三层开发模式。

1、减少系统相互依赖。

2、提高灵活性。

3、提高了安全性。

1、为复杂的模块或子系统提供外界访问的模块。

2、子系统相对独立。

3、预防低水平人员带来的风险。

1、系统中有大量对象。

2、这些对象消耗大量内存。

3、这些对象的状态大部分可以外部化。

4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。

5、系统不依赖于这些对象身份，这些对象是不可分辨的。

1、JAVA 中的 String，如果有则返回，如果没有则创建一个字符串保存在字符串缓存池里面。

2、数据库的数据池。

1、系统有大量相似对象。

2、需要缓冲池的场景。

1、注意划分外部状态和内部状态，否则可能会引起线程安全问题。

2、这些类必须有一个工厂对象加以控制。

1、Windows 里面的快捷方式。

2、猪八戒去找高翠兰结果是孙悟空变的，可以这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，所以说孙悟空是高翠兰代理类。

3、买火车票不一定在火车站买，也可以去代售点。

4、一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。

5、spring aop。

1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。

2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。

2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。

1、红楼梦中的"击鼓传花"。

2、JS 中的事件冒泡。

3、JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。

1、降低耦合度。它将请求的发送者和接收者解耦。

2、简化了对象。使得对象不需要知道链的结构。

3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。

4、增加新的请求处理类很方便。

1、不能保证请求一定被接收。

2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。

3、可能不容易观察运行时的特征，有碍于除错。

1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。

2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。

3、可动态指定一组对象处理请求。

1、降低了系统耦合度。

2、新的命令可以很容易添加到系统中去。

1、可扩展性比较好，灵活。

2、增加了新的解释表达式的方式。

3、易于实现简单文法。

1、可利用场景比较少。

2、对于复杂的文法比较难维护。

3、解释器模式会引起类膨胀。

4、解释器模式采用递归调用方法。

1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。

2、一些重复出现的问题可以用一种简单的语言来进行表达。

3、一个简单语法需要解释的场景。

1、它支持以不同的方式遍历一个聚合对象。

2、迭代器简化了聚合类。

3、在同一个聚合上可以有多个遍历。

4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。

1、访问一个聚合对象的内容而无须暴露它的内部表示。

2、需要为聚合对象提供多种遍历方式。

3、为遍历不同的聚合结构提供一个统一的接口。

1、后悔药。

2、打游戏时的存档。

3、Windows 里的 ctri + z。

4、IE 中的后退。

5、数据库的事务管理。

1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。

2、实现了信息的封装，使得用户不需要关心状态的保存细节。

1、为了符合迪米特原则，还要增加一个管理备忘录的类。

2、为了节约内存，可使用原型模式+备忘录模式。

1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。

2、西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。

直接setnx

setnx设置一个过期时间

set nx ex

set nx ex 加一个事务id

set nx px + 事务id + lua

redlock

客户端长时间阻塞导致锁失效问题

redis服务器时钟漂移问题

单点实例安全问题

获取当前时间戳（ms）

先设定key的有效时长（TTL），超出这个时间就会自动释放，然后client（客户端）尝试使用相同的key和value对所有redis实例进行设置，每次链接redis实例时设置一个比TTL短很多的超时时间，这是为了不要过长时间等待已经关闭的redis服务。并且试着获取下一个redis实例

client通过获取所有能获取的锁后的时间减去第一步的时间，还有redis服务器的时钟漂移误差，然后这个时间差要小于TTL时间并且成功设置锁的实例数>= N/2 + 1（N为Redis实例的数量），那么加锁成功

如果客户端由于某些原因获取锁失败，便会开始解锁所有redis实例

问题

RedLock并没有完全解决Redis单点故障存在的隐患，也没有解决时钟漂移以及客户端长时间阻塞而导致的锁超时失效存在的问题，锁的安全性隐患依然存在

临时顺序节点

zk通过临时节点，解决掉了死锁的问题，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉，其他客户端自动获取锁

zk通过节点排队监听的机制，也实现了阻塞的原理，其实就是个递归在那无限等待最小节点释放的过程

可重入，创建临时节点时带上线程信息

高可用的，只要半数以上的或者，就可以对外提供服务了

性能上可能并没有缓存服务那么高

网络抖动，客户端和ZK集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了

优点

缺点

优点

缺点

redis set px nx + 唯一id + lua脚本

基于redis的redlock

优点

缺点

ACID（更多指数据库事务层面）

CAP理论

BASE理论

阶段一（准备阶段）

阶段二（提交阶段）

存在的问题

优缺点

流程图

阶段一

阶段二

阶段三

优缺点

流程图

条件

处理流程

优缺点

异常处理

流程图

本地消息表其实就是利用了 各系统本地的事务来实现分布式事务。
本地消息表顾名思义就是会有一张存放本地消息的表，一般都是放在数据库中，然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中，这样就能保证消息放入本地表中业务肯定是执行成功的。
然后再去调用下一个操作，如果下一个操作调用成功了好说，消息表的消息状态可以直接改成已成功。
如果调用失败也没事，会有 后台任务定时去读取本地消息表，筛选出还未成功的消息再调用对应的服务，服务更新成功了再变更消息的状态。
这时候有可能消息对应的操作不成功，因此也需要重试，重试就得保证对应服务的方法是幂等的，而且一般重试会有最大次数，超过最大次数可以记录下报警让人工处理。
可以看到本地消息表其实实现的是最终一致性，容忍了数据暂时不一致的情况。

子主题

子主题

拆分分布式事务为多个本地事务，由saga引擎负责协调，如果过程中出现部门失败，调用补偿操作。恢复策略：向前恢复和向后恢复，向前恢复对失败的节点采取最大努力不断重试，保证数据库的操作最终一定保证数据一致性，如果最终多次重试失败则根据相关日志主动通知开发人员手工介入。向后恢复对之前的成功节点执行回滚的事务操作，保证数据一致性。Saga比TCC少了Try操作，因此会直接提交数据库，然后出现失败进行补偿。

使用

优点

缺点

使用

优点

缺点

使用

优点

缺点

使用

优点

缺点

使用

优点

缺点

时间戳 + 工作机器id + 序列号

介绍

使用

优点

缺点

图解

介绍

原理

接入方式

建议

优点

缺点

介绍

组成

使用

建议

优点

缺点

介绍

使用

优点

缺点

客户端调用方代码实现，负责发起RPC调用，为调用方用户提供使用API

负责RPC调用通过网络传输的内容进行序列化与反序列化，不同的RPC框架有不同的实现机制

屏蔽RPC调用过程中复杂的网络处理逻辑，使得RPC调用透明化，能够保持与本地调用一样的代码风格

作为RPC框架底层的通信传输模块，一般通过Socket在客户端与服务器端之间传递请求与应答消息

服务端服务业务逻辑具体的实现

支持真正的面向对象的多态性

Java独有，不支持其他语言

使用java原生的序列化机制，所有序列化对象必须实现java.io.Serializable接口

底层通信基于BIO(同步阻塞I/O)实现Socket完成

由于使用了java原生序列化机制与BIO通信机制(因为存在性能问题)，所以导致RMI的性能较差

CXF

Axis2

Thrift

gRPC

HTTP Client

是将对象的状态信息转换成为可存储或传输的形势过程

是序列化的逆过程，将字节数组反序列化为对象，把字节序列恢复为对象的过程

优点

缺点

优点

缺点

是一种轻量级的数据交换格式

相比XML，它的码流更小，而且保留了XML可读性好的优势

开源工具

优点

优点

缺点

优点

优点

缺点

需要编写以.thrift结尾的IDL文件，再使用thrift提供的编译器编译生成对应的代码

特点

优点

特性

两种序列化编码方式

优点

序列化空间开销，即序列化结果产生的码流大小，码流过大会对带宽、存储空间造成较大的压力

序列化时间开销，即徐丽华过程消耗的时长，序列化消耗时间过长会拖慢整个服务的响应时间

序列化协议是否支持跨平台、跨语言，公司内部存在异构系统通信需求时，往往要求RPC架构采用的序列化协议支持跨平台、跨语言

可扩展性/兼容性

成熟度及支持的数据结构的丰富性也是一个需要重点考量的方面

技术的流行程度，背后是否有大公司技术支撑，是否是一个长期发展的持续进化的技术，是否已经得到业界的充分验证

学习难度和易用性

对于公司间的系统调用，性能要求在100ms以上的服务，基于XML的SOAP洗衣是一个值得考虑的方案

基于Web Browser的Ajax，以及Mobile APP与服务器之间的通信，JSON协议是首选。对于性能要求不太高，或者动态类型语言为主，或者传输数据载荷很小的运用场景，JSON也是一个非常不错的选择

对于调试环境比较恶劣的场景，采用JSON或XML能够极大的提高调试效率，降低系统开发成本

对于性能和简洁性有极高要求的场景，Hessian，protobuf，Thrift，Avro之间具有一定的竞争关系。其中Hessian是在性能和稳定性同时考虑下最优的序列化协议

对于T级别的数据持久化应用场景，protobuf和Avro是首要选择。如果持久化后的数据存在Hadoop子项目里，Avro会是更好的选择

由于Avro的设计理念偏向于动态类型语言，对于以动态语言为主的应用场景，Avro是更好的选择

对于持久层非Hadoop项目，以静态类型语言为主的应用场景，protobuf会更符合静态类型语言工程师的开发习惯

对需要提供一个完成的RPC解决方案，Thrift是一个好的选择

对于序列化后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景，Protobuf可以优先考虑

服务启动的时候，将服务提供者信息主动上报到服务注册中心进行服务注册

服务调用者启动的时候，将服务提供者信息从注册中心下拉到读物调用者机器本地缓存，服务调用者从本地缓存的服务提供者地址列表中，基于某种服务负载均衡策略选择一台服务提供者发起远程调用

服务注册中心能够感知服务提供者集群中某一台机器下线，将该机器服务提供者信息从服务注册中心删除，并主动通知服务调用者集群中的每一台机器，使得服务调用者不在调用该机器

软负载及透明化服务路由：服务提供者和服务调用者之间相互解耦，服务调用者不需要硬编码服务提供者地址

服务动态发现及可伸缩能力：服务提供者机器增减能被服务调用者通过注册中心动态感知，而且通过增减机器可以实现服务的弹性伸缩

通过注册中心可以动态地监控服务运行质量及服务依赖，为服务提供服务治理能力

服务注册中心还可以用来收集服务消费者信息，以达到实现部分服务治理功能的目的。在服务消费端，通过将服务消费者信息写入ZooKeeper临时节点，一旦消费者机器下线，断开与ZooKeeper的连接，该临时节点将被自动删除，达到通过ZooKeeper自动收集消息者信息的目的

实现流程

服务提供端将服务接口注册到服务中心ZooKeeper中，如user.api，然后消费端先将ZooKeeper中心的所有机器上的所有服务同步到本地，然后本地动态地组合访问地址，如http://127.0.0.1:8080/user.httpInvoker。然后通过rmi,httpInvoker或hessian访问服务提供端的服务。这样就是一个完整的消费端访问服务端的服务的过程

这样的实际应用就是服务消费端不用固定的配置服务的地址(ip,port等)，当一台服务提供端机器挂掉的时候，我们可以访问其他的机器，同时我们在对服务提供端的机器可以动态地添加或删除。更加动态化

调用方发起调用请求，在没有返回结果之前，调用方线程被挂起，处于一直等待状态

非阻塞和阻塞的概念相对应，调用方发起请求，当线程不会等待挂起，而会立刻返回。后续可以通过轮询等手段来获取调用结果状态

在发出一个功能调用时，在没有得到结果之前，该调用就会返回

异步和同步的概率相对。当一个异步过程调用发出后，调用者不会立刻得到结果，通过回调等措施来处理这个调用

所有的输出流都继承抽象类OutputStream,所有的输入流都继承抽象InputStream。注意output和Input是针对内存，写进内存是input，从内存写出到其他地方是output

ByteArrayOutputStream/ByteArrayInputStream

FileOutputStream/FileInputStream

FilterOutputStream/FilterInputStream

BufferedOutputStream/BufferedInputStream

DataOutputStream/DataInputStream

PrintStream

ObjectOutputStream/ObjectInputStream

PipedOutputStream/PipedInputStream

所有的输出流都继承抽象类Writer,所有的输入流都继承抽象Reader。注意writer和reader是针对内存，写进内存是writer，从内存写出到其他地方是reader

BufferedWriter/BufferedReader

CharArrayWriter/CharArrayReader

OutputStreamWriter/InputStreamReader

StringWriter/StringReader

PipedWriter/PipedReader

PrintWriter

因为一个字节8bit，而一个字符是16bit，字符串由字符组成，字符串类型天然处理的是字符而不是字节。更重要的是，字节流无法知道字符集及其字符编码

缓冲区实质上是一个数组。抽象类是Buffer

所有缓冲区的属性

Stream VS Channel

Channel在Selector上注册，Selector通过不断轮询注册在骑上的Channel，能够感知到Channel可读或者可写事件。通过这种机制，可以使用一个或者少数几个线程管理大量的网络连接。用较少的线程处理大量的网络连接有很大的好处，可以减少线程之间的切换开销，而且线程本身也需要占用系统资源。

将请求按照某种策略分布到多台机器上，使得系统能够实现横向扩展，是应用实现可伸缩性的关键技术

分布式服务架构中实现负载均衡是通过软件算法来实现的，有别于基于硬件设备实现负载均衡

分布式服务框架中，负载均衡是在服务消费端实现的

获取服务列表大小范围内的随机数，将该随机数作为列表索引，从服务提供列表中获取服务提供者

在随机算法的基础上针对权重做了处理。首先根据加权数放大服务提供者列表，比如服务提供者A加权数为3，放大之后变为A，A，A，存放在新的服务提供者列表，然后对新的服务提供者列表应用随机算法

定义

原理

首先根据加权数放大服务提供者列表，再在放大后的服务提供者基础上使用轮询算法获取服务提供者

定义

原理

由于注册中心都是保存的路径，所以在路劲中加入分组名。注册中心加入服务分组名路径之后，指定消费摸个服务组的消费端将该服务组下的服务提供者列表获取到本地缓存，消费端服务调用的时候，将按照指定的软负载算法从本地缓存中选取一个服务调用者发起调用

服务提供者信息与对应的服务消费者信息在注册中心已经存在了，所需要做的，不过是提供获取服务提供者信息与消费者信息列表的接口方法，从注册中心查找对应的信息

在服务调用发起方生成标识本次调用的唯一ID，传递到服务提供方，然后将该ID使用ThreadLocal保存起来，在应用的业务代码里面使用拦截器统一从ThreadLocal中获取出来。

会脏读

会产生不可重复读

会产生幻读

public interface BeanPostProcessor {
@Nullable
default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
return bean;
}

@Nullable
default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
}

@FunctionalInterface
public interface BeanFactoryPostProcessor {
           void postProcessBeanFactory(ConfigurableListableBeanFactory var1) throws BeansException;
}

public interface DisposableBean {
      void destroy() throws Exception;
}

原sql是:
select * from ORDER_00 where create_tm >= ? and create_tm <= ? limit 10 ,10 ;
select * from ORDER_01 where create_tm >= ? and create_tm <= ? limit 10 ,10 ;
select * from ORDER_02 where create_tm >= ? and create_tm <= ? limit 10 ,10 ;
会被改写成:
select * from ORDER_00 where create_tm >= ? and create_tm <= ? limit 0 ,20 ;
select * from ORDER_01 where create_tm >= ? and create_tm <= ? limit 0 ,20 ;
select * from ORDER_02 where create_tm >= ? and create_tm <= ? limit 0 ,20 ;

原sql是:
select * from ORDER_00 where create_tm >= ? and create_tm <= ? limit 20 ,10 ;
select * from ORDER_01 where create_tm >= ? and create_tm <= ? limit 20 ,10 ;
select * from ORDER_02 where create_tm >= ? and create_tm <= ? limit 20 ,10 ;
会被改写成:
select * from ORDER_00 where create_tm >= ? and create_tm <= ? limit 0 ,30 ;
select * from ORDER_01 where create_tm >= ? and create_tm <= ? limit 0 ,30 ;
select * from ORDER_02 where create_tm >= ? and create_tm <= ? limit 0 ,30 ;

日志地址

慢于多少秒记录

请求次数

并发数

尽可能的缩短锁持有的时间

减少锁的粒度

放弃使用独占锁，使用读写锁

存储对象的内存空间，对象的创建和释放、垃圾回收都在这里进行

是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

分类

与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。

JVM栈（JVM Stacks）

本地方法栈（Native Method Stacks）

总结：方法区和堆是所有线程共享的内存区域；而Java栈、本地方法栈和程序计数器是运行是线程私有的内存区域。

Eden Space

From

To

经过多次Young GC，某些对象会在From和To多次复制，如果超过某个阈值对象还未释放，则将该对象复制到老年区。如果老年区空间用完，就会触发Full GC

串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。

-XX:+UseSerialGC 串行收集器

ParNew收集器其实就是Serial收集器的多线程版本，新生代并行，老年代串行；新生代复制算法、老年代标记-压缩

-XX:+UseParNewGC ParNew收集器

-XX:ParallelGCThreads 限制线程数量

Parallel Scavenge收集器类似ParNew收集器，Parallel收集器更关注系统的吞吐量

-XX:+UseParallelGC 使用Parallel收集器+ 老年代串行（并行收集器）

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法

-XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行（并行老年代收集器）

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器

-XX:+UseConcMarkSweepGC 使用CMS收集器（并发收集器）

-XX:+ UseCMSCompactAtFullCollection Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长

-XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后，进行一次碎片整理

-XX:ParallelCMSThreads 设定CMS的线程数量（一般情况约等于可用CPU数量）

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征

特点

-Xmn:年轻代大小

-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4

-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5

子主题

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

join操作问题

事物问题

成本问题

单台数据库服务器一般来说能支撑10万用户量级的业务

将表中某些不常用且占了大量空间的列拆分出去

参考：单表超过五千万条建议分表

路由算法

问题

实现方式

myisam（B树）

innodb（B+树）

合理使用索引

反范式设计

使用查询缓存

使用搜索引擎

使用key-value数据库

需要经过复杂运算得到的数据

分布式环境下，对缓存更新操作进行加锁保护，保证只有一个线程能够进行操作

缓存有效期设置为永久，后台定时更新

缓存预热

MD5withRSA

SHA1withRSA

keytool

OpenSSL

MapReduce

Hive SQL

存储在关系型数据库中，一般包含Hive的表属性，桶信息和分区信息

spout数据流输入

bolt对数据做解析

第一次读取本地失败后，根据路由规则去另外一个机房读取

Mysql同步

session id不同步，本地机房没有该id的情况下，根据路由去另外一个机房获取

session id在另外一个机房未获取到，则让用户重新登录

独立的服务器负责数据分区的分配（Namenode）

选举一台服务器做数据分区的分配（master node）

纯理论算法，特别复杂，是其他算法的鼻祖

为工程实践而设计，Paxos算法的不完整版

cat -n access.log 显示行数

Enter：下一行，空格：下一页，F：下一屏，B：上一屏

对内容进行排序

-n

-r

-k

-t

统计指定文件的字符数、字数、行数

-l

查看重复出现的行

sort uniqfile | uniq -c

cat access.log | cut -f1 -d " " | sort |uniq -c | sort -k 1 -n -r |head -10

cat access.log | sort -k 2 -n -r | head -10

查看系统的load

st

查看指定进程

查看磁盘剩余空间，-d 1表示递归深度

查看系统的网络状况

查看系统的IO

查看内存使用情况

swap过高，表示物理内存不够用

查看当前swap的IO情况

优点

缺点

优点

缺点

位于传输层的四层负载

方式

优点

缺点

以反向代理的方式进行负载均衡的，通过upstream来实现

方式

优点

缺点

对后端服务器的健康检查，只支持通过端口来检测，不支持通过 ur l来检测。不支持 Session 的直接保持，但能通过 ip_hash 来解决

HAProxy 的优点能够补充 Nginx 的一些缺点，比如支持 Session 的保持，Cookie 的引导；同时支持通过获取指定的 url 来检测后端服务器的状态

HAProxy 跟 LVS 类似，本身就只是一款负载均衡软件；单纯从效率上来讲 HAProxy 会比 Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx 的

HAProxy 支持 TCP 协议的负载均衡转发，可以对 MySQL 读进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，大家可以用 LVS+Keepalived 对 MySQL 主从做负载均衡

HAProxy 负载均衡策略非常多：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）

了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bonded Context，Repository等等这些概念。更进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。

所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制要求把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了。
注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程
通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。
下沉的过程如下图所示，假设两个use case中，我们发现uc1的step3和uc2的step1有类似的功能，我们就可以考虑让其下沉到Domain层，从而增加代码的复用性。

把需要扩展的部分封装、抽象成需要被组合的对象，然后对其进行扩展，比如星环的能力扩展点就是这种方式

分支主题

分支主题

分支主题

分支主题

分支主题

心力是指不将就的匠心，不妥协的好奇心，不放弃的恒心。

脑力是指那些必要的思维能力、学习能力、思考能力、思辨能力。

之所以说“业务理解-->领域建模-->流程分解-->矩阵分析”是体力，是因为实现它们就像是在做填空题，只要你愿意花时间，再复杂的业务都可以按部就班的清晰起来。