1.sychronized
1>当线程 A 调用某对象的synchronized 方法 或者 synchronized 代码块时，若同步锁未释放，其他线程调用同一对象的synchronized 方法 或者 synchronized 代码块时将被阻塞，直至线程 A 释放该对象的同步锁。
2>synchronized 方法 和 synchronized 代码块的不同之处在于 synchronized 方法 作用域较大，作用于整个方法，而 synchronized 代码块 可控制具体的作用域，更精准控制提高效率。（毕竟阻塞的都是时间啊）
3>当线程 A 调用某对象的synchronized 方法 或者 synchronized 代码块时，若同步锁未释放，其他线程调用同一对象的其他synchronized 方法 或者 synchronized 代码块时将被阻塞，直至线程 A 释放该对象的同步锁。（注意：重点是其他）
4>当线程 A 调用某对象的synchronized 方法 或者 synchronized 代码块时，无论同步锁是否释放，其他线程调用同一对象的其他 非 synchronized 方法 或者 非 synchronized 代码块时可立即调用。
2.关于threadlocal
threadlocal存在一个线程里面。也就是一个线程里面的变量。可以保证线程安全。使用场景是在一个线程里面put进去的值，在这个线程里面的任何一个地方都可以用。缺点是传值时可能过大。
看另外一个场景，一个请求过来，会带有一堆的c参数（可以理解为客户端的一些标志），我们的应用处理过程中，大部分地方又不需要关心该参数，可能在某个请求他人接口的时候需要了，如果我们把所有代码都带上这个c参数，那么未免代码看着太过丑陋，这种情况下，我们可以构建一个filter，在请求过来的时候，在filter中将c参数放置到ThreadLocal中，在整个调用链中如果需要使用，直接从ThreadLocal中获取即可。
3.关于Volatile
Volatile关键字主要的作用是把值强刷到内存中。一定程度上能保证线程安全，但是它不能保证原子性。主要的用处为：
boolean stop = false;
while(!stop){
doSomething();
}
//线程2
stop = true;
下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过，每个线程在运行过程中都有自己的工作内存，那么线程1在运行的时候，会将stop变量的值拷贝一份放在自己的工作内存当中。
那么当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。
不能保证原子性的为i++操作。
4.关于== 和 equal
1）对于==，如果作用于基本数据类型的变量，则直接比较其存储的 “值”是否相等；
如果作用于引用类型的变量，则比较的是所指向的对象的地址
2）对于equals方法，注意：equals方法不能作用于基本数据类型的变量
如果没有对equals方法进行重写，则比较的是引用类型的变量所指向的对象的地址；
诸如String、Date等类对equals方法进行了重写的话，比较的是所指向的对象的内容。
5.其实getParameter()和getAttribute()最简单的两点区别就是
1）赋值方式不一样，前者是客户端如浏览器端将请求参数值送给服务器端，而后者则是在请求到达服务器端之后，在服务器进行存放进去
2）两者的返回值类型不一样，前者永远返回字符串，后者返回任意对象
既然parameter和attribute都是传递参数，为什么不直接使用parameter呢？
原因有2：
1）从上面分析可以找到getParameter获取的是客户端发送的参数，而且在服务器端不能通过setParameter(key， value)来添加参数，因为没有这个函数所以如果需要在服务器端进行跳转，并需要想下个页面发送新的参数时，则没法实现。但是attribute可以，可以通过setAttribute()，将值放入到request对象，然后在其他页面使用getAttribute获取对应的值，这样就达到一次请求可以在多个页面共享一些对象信息
2）parameter返回值是字符串，意味着不能传递其他的对象，如List，但是attribute则可以存放任意类型的Java对象
问题：
dubbo是如何负载均衡的。
小财迷所用的dubbo版本为2.8.4
1.dubbo的集群容错：
<dubbo:service cluster="failfast"/>
属性：cluster 类型：string 是否必须：可选 缺省值：failover 作用：性能调优 可选方式：failover/failfast/failsafe/failback/forking 兼容性：dubbo的2.0.5以上版本
1.1.failover（dubbo缺省配置）
失败自动切换，当出现失败，重试其它服务器(缺省)。通常用于读操作，但重试会带来更长延迟。可通过retries="2"来设置重试次数(不含第一次),retries的值是根据你的服务部署了多少台机器来设置的，比如你的同一个服务在三台机器上都部署了，那么retries的值就设置为2.如果设置为0，则相当于failfast了。 可以在消费端和服务提供端配置。
1.2.failfast
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
可以在服务提供方和服务消费方都可以配置。如：
服务提供方：<dubbo:service cluster="failfast" /> 服务消费方：<dubbo:reference cluster="failfast" />
1.3.failsafe
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。服务提供方和服务消费方都可以。
1.4.failback
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。服务提供方和服务消费方都可以。
1.5.forking
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过forks="2"来设置最大并行数。服务提供方和服务消费方都可以。
注意：一般情况下failover（读操作）和failfast(写操作)就可以满足需求；failover集群容错的retries的属性值改为"0"时等价于failfast、
2.dubbo的负载均衡：
2.1.Random
随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
2.2.RoundRobin
轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
2.3.LeastActive
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
2.4.ConsistentHash
一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
配置方式：
<dubbo:service interface="..." loadbalance="roundrobin" />