java面试题(中)

67、分布式理论懂多少，说一下（CAP，Base，paxos）

CAP理论：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的两项。

Base理论：BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性(Strong consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

 Paxos（分布式一致性算法）作为分布式系统的基石。

 

 

68、分布式事务有了解吗

69、RabbitMQ消息队列丢失消息，重复消费问题  

70，Redis和memcached 

71、看你项目用到Spring boot，那有用过Spring cloud吗

72、RPC说一下

73、说一下你对微服务的理解，与SOA的区别 

74、跟我介绍一下区块链~

75、怎么看待国内区块链的发展 

 

数据库数据同步

tomcat 分库jar包管理

读写锁

1、明确项目是做什么的

2、明确项目的价值。（为什么做这个项目，它解决了用户什么痛点，它带来什么价值？）

3、明确项目的功能。（这个项目涉及哪些功能？）

4、明确项目的技术。（这个项目用到哪些技术？）

5、明确个人在项目中的位置和作用。（你在这个项目的承担角色？）

6、明确项目的整体架构。

7、明确项目的优缺点,如果重新设计你会如何设计。

8、明确项目的亮点。（这个项目有什么亮点？）

9、明确技术成长。（你通过这个项目有哪些技术成长？）

Java基础

1、List 和 Set 的区别

1.List和Set都是接口继承于Collection接口。

2.最大的不同就是List是可以重复的。而Set是不能重复的。（注意：元素虽然无放入顺序，但是元素在set中的位置是有该元素的HashCode决定的，其位置其实是固定的） 

3.List接口有三个实现类：LinkedList，ArrayList，Vector ，Set接口有两个实现类：HashSet(底层由HashMap实现)，LinkedHashSet

4.List适合经常追加数据，插入，删除数据。但随机取数效率比较低。

5.Set适合经常地随机储存，插入，删除。但是在遍历时效率比较低。

 

2、HashSet 是如何保证不重复的 ?

在向hashSet中add()元素时，判断元素是否存在的依据，不仅仅是hash码值就能够确定的，同时还要结合equles方法。

 

3、HashMap 是线程安全的吗，为什么不是线程安全的（最好画图说明多线程环境下不安全）?

不是线程安全的。

不安全的原因. resize死循环 

 

4、HashMap 的扩容过程

使用一个容量更大的数组来代替已有的容量小的数组，transfer()方法将原有Entry数组的元素拷贝到新的Entry数组里。 

 

5、HashMap 1.7 与 1.8 的 区别，说明 1.8 做了哪些优化，如何优化的？

 

JDK1.7用的链表散列结构，JDK1.8用的红黑树

在扩充HashMap的时候，JDK1.7的重新计算hash，

JDK1.7只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap；

DK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，

JDK1.8不会倒置

 

 

 

6、final finally finalize

final修饰符（关键字）。被final修饰的类，就意味着不能再派生出新的子类，不能作为父类而被子类继承。

finally是在异常处理时提供finally块来执行任何清除操作。不管有没有异常被抛出、捕获，finally块都会被执行。

finalize是方法名。java技术允许使用finalize（）方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。

 

7、强引用 、软引用、 弱引用、虚引用

• 强引用

        new一个对象，强引用不会被GC回收。

• 软引用(SoftReference)、

        如果一个对象只具有软引用，那就类似于可有可物的生活用品。

• 弱引用（WeakReference）

        如果一个对象只具有弱引用，那就类似于可有可物的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。

        在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。

• 虚引用（PhantomReference）

        虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。

        当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中

        

8、Java反射

        反射就是把java类中的各种成分映射成一个个的Java对象

9、Arrays.sort 实现原理和 Collection 实现原理

在jdk7以前的版本中sort()的实现原理是：基本类型使用优化后的快速排序，其他类型使用优化后的归并排序，jdk7以后如果jdk7以后修改了排序策略：如果JVM启动参数配置了-Djava.util.Arrays.useLegacyMergeSort%3Dtrue+那么就会执行上面所说的排序策略(优化的归并排序)，否则将会执行TimSort排序。&oq=在jdk7以前的版本中sort()的实现原理是：基本类型使用优化后的快速排序，其他类型使用优化后的归并排序，jdk7以后如果jdk7以后修改了排序策略：如果JVM启动参数配置了-Djava.util.Arrays.useLegacyMergeSort%3Dtrue++那么就会执行上面所说的排序策略(优化的归并排序)，否则将会执行TimSort排序。

 

事实上Collections.sort方法底层就是调用的array.sort方法

 

10、LinkedHashMap的应用

   LinkedHashMap是Map接口的哈希表和链接列表实现，具有可预知的迭代顺序。LinkedHashMap实现与HashMap的不同之处在于，LinkedHashMap维护着一个运行于所有条目的双重链接列表。此链接列表定义了迭代顺序，该迭代顺序可以是插入顺序（insert-order）或者是访问顺序，其中默认的迭代访问顺序就是插入顺序，即可以按插入的顺序遍历元素，这点和HashMap有很大的不同。

 

 

11、cloneable接口实现原理

其实，Cloneable接口在这里起到了一种标识的作用，表明实现它的类具备了实例拷贝功能

因为如果不继承自Cloneable接口，当调用clone()时会抛出CloneNotSupportedException异常

12、异常分类以及处理机制

抛出异常有三种形式，一是throw,一个throws，还有一种系统自动抛异常。 

针对性处理方式：捕获异常

13、wait和sleep的区别

 

sleep() 方法是线程类（Thread）的静态方法，让调用线程进入睡眠状态，让出执行机会给其他线程，等到休眠时间结束后，线程进入就绪状态和其他线程一起竞争cpu的执行时间。  

wait()是Object类的方法，当一个线程执行到wait方法时，它就进入到一个和该对象相关的等待池，同时释放对象的机锁，使得其他线程能够访问，可以通过notify，notifyAll方法来唤醒等待的线程

 

14、数组在内存中如何分配

1、简单的值类型的数组，每个数组成员是一个引用（指针），引用到栈上的空间（因为值类型变量的内存分配在栈上）

2、引用类型，类类型的数组，每个数组成员仍是一个引用（指针），引用到堆上的空间（因为类的实例的内存分配在堆上）

 

 

Java 并发

1、synchronized 的实现原理以及锁优化？

原理：synchronized底层是通过一个monitor的对象阻塞和获取。

    对代码同步：指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。 

    对方法同步：常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。

    重量级锁：Mutex Lock 监视器锁monitor本质就是依赖于底层的操作系统的Mutex Lock来实现的。

    

2、volatile 的实现原理？

JVM就会向处理器发送一条Lock前缀的指令,将这个变量所在缓存行的数据写回到系统内存。但是就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题，所以在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里。

3、Java 的信号灯？

Semaphore可以维护当前访问自身的线程个数，并提供了同步机制。使用Semaphore可以控制同时访问资源的线程个数，例如，实现一个文件允许的并发访问数。

Semaphore实现的功能就类似厕所有5个坑，假如有十个人要上厕所，那么同时能有多少个人去上厕所呢？同时只能有5个人能够占用，当5个人中的任何一个人让开后，其中在等待的另外5个人中又有一个可以占用了。

另外等待的5个人中可以是随机获得优先机会，也可以是按照先来后到的顺序获得机会，这取决于构造Semaphore对象时传入的参数选项。

单个信号量的Semaphore对象可以实现互斥锁的功能，并且可以是由一个线程获得了“锁”，再由另一个线程释放“锁”，这可应用于死锁恢复的一些场合。

 

4、synchronized 在静态方法和普通方法的区别？

synchronized修饰不加static的方法，锁是加在单个对象上，不同的对象没有竞争关系；修饰加了static的方法，锁是加载类上，这个类所有的对象竞争一把锁。

 

 

5、怎么实现所有线程在等待某个事件的发生才会去执行？

栅栏CyclicBarrier

设置栅栏的初始值为1，当事件发生时，调用barrier.wait()冲破设置的栅栏，将调用指定的Runable线程执行，在该线程中启动N个新的子线程执行。这个方法并不是让执行中的线程全部等待在某个点，待某一事件发生后继续执行。

 

CountDownLatch

CountDownLatch是一个计数器闭锁，主要的功能就是通过await()方法来阻塞住当前线程，然后等待计数器减少到0了，再唤起这些线程继续执行。 这个类里主要有两个方法，一个是向下减计数器的方法:countdown(),其实现的核心代码如下:

public boolean tryReleaseShared(int releases) {   // Decrement count; signal when transition to zero   for (;;) {    int c = getState();      if (c == 0)     return false;      int nextc = c-1;     if (compareAndSetState(c, nextc))     return nextc == 0;     }    }    

很简单，如果取得当前的状态为0,说明这个锁已经结束，直接返回false;如果没有结束，然后去设置计数器减1,如果compareAndSetState不成功，则继续循环执行。 而其中的一直等待计数器归零的方法是await()。 

通过CountDownLatch可以做几件事情：

1. 主线程控制同时启动一组线程

 

2. 主线程等待各子线程全部执行完毕后再往下执行:

 

Semaphore

Semaphore与CountDownLatch相似，不同的地方在于Semaphore的值被获取到后是可以释放的，并不像CountDownLatch那样一直减到底。它也被更多地用来限制流量，类似阀门的 功能。如果限定某些资源最多有N个线程可以访问，那么超过N个主不允许再有线程来访问，同时当现有线程结束后，就会释放，然后允许新的线程进来。有点类似于锁的lock与 unlock过程。相对来说他也有两个主要的方法：

1. 用于获取权限的acquire(),其底层实现与CountDownLatch.countdown()类似;
2. 用于释放权限的release()，其底层实现与acquire()是一个互逆的过程。

用Semaphore来实现限流代码详见：semaphore例子

CyclicBarrier

CyclicBarrier是用来一个关卡来阻挡住所有线程，等所有线程全部执行到关卡处时，再统一执行下一步操作，它里面最重要的方法是await()方法，其实现如下：

 

即每个线程执行完后调用await(),然后在await()里，线程先将计数器减1,如果计数器为0，则执行定义好的操作，然后再继续执行原线程的内容。 

这个类比之前两个类的一个好处是有点类似于切面编程，可以让我们在同类线程的某个切面切入一块逻辑，并且可以同步所有的线程的执行速度。

 

 

 

 

6、CAS？CAS 有什么缺陷，如何解决？

CAS解决高并发时数据一致性问题，只需要在进行set操作时，compare一下初始值，如果初始值变换，不允许set成功。

++i是cas操作，利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法。其它原子操作都是利用类似的特性完成的。

CAS的缺点：

1.CPU开销较大

在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

2.不能保证代码块的原子性

CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

3.ABA问题

这是CAS机制最大的问题所在。

• 什么是ABA问题？

 引用原书的话：如果在算法中的节点可以被循环使用，那么在使用“比较并交换”指令就可能出现这种问题，在CAS操作中将判断“V的值是否仍然为A？”，并且如果是的话就继续执行更新操作，在某些算法中，如果V的值首先由A变为B，再由B变为A，那么CAS将会操作成功。

• 怎么避免ABA问题？

在变量前面追加上版本号

Java 1.5中提供了AtomicStampedReference和AtomicMarkableReference来解决ABA问题。 

 

 

7、synchronized 和 lock 有什么区别？

synchronized是java中的一个关键字，也就是说是Java语言内置的特性。

Lock是一个接口  Lock接口中每个方法的使用，lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。

8、Hashtable 是怎么加锁的 ？

HashTable是线程安全的，内部的方法基本都是synchronized。

9、HashMap 的并发问题？

 resize死循环 

10、ConcurrenHashMap 介绍？1.8 中为什么要用红黑树？

java8不是用红黑树来管理hashmap，而是在hash值相同的情况下（且重复数量大于8），用红黑树来管理数据。 红黑树相当于排序数据。可以自动的使用二分法进行定位。性能较高。

在ConcurrentHashMap中，就是把Map分成了N个Segment，put和get的时候，都是现根据key.hashCode()算出放到哪个Segment中： 

ConcurrentHashMap中默认是把segments初始化为长度为16的数组。

根据ConcurrentHashMap.segmentFor的算法，3、4对应的Segment都是segments[1]，7对应的Segment是segments[12]。

（1）Thread1和Thread2先后进入Segment.put方法时，Thread1会首先获取到锁，可以进入，而Thread2则会阻塞在锁上：

（2）切换到Thread3，也走到Segment.put方法，因为7所存储的Segment和3、4不同，因此，不会阻塞在lock()：

人很聪明，真的很聪明。既然不能全锁（HashTable）又不能不锁（HashMap），所以就搞个部分锁，只锁部分，用到哪部分就锁哪部分。一个大仓库，里面有若干个隔间，每个隔间都有锁，同时只允许一个人进隔间存取东西。但是，在存取东西之前，需要有一个全局索引，告诉你要操作的资源在哪个隔间里，然后当你看到隔间空闲时，就可以进去存取，如果隔间正在占用，那你就得等着。聪明！！

 

 

 

11、AQS

抽象的队列式的同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch...。

AQS提供了一种原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。

 

 

12、如何检测死锁？怎么预防死锁？

 

有两个容器，一个用于保存线程正在请求的锁，一个用于保存线程已经持有的锁。每次加锁之前都会做如下检测:

1)检测当前正在请求的锁是否已经被其它线程持有,如果有，则把那些线程找出来

2)遍历第一步中返回的线程，检查自己持有的锁是否正被其中任何一个线程请求

 如果第二步返回真,表示出现了死锁

三种用于避免死锁的技术：

1、加锁顺序（线程按照一定的顺序加锁）

2、加锁时限（线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁）

3、死锁检测

13、Java 内存模型？

14、如何保证多线程下 i++ 结果正确？

1. volatile解决了线程间共享变量的可见性问题
2. 使用volatile会增加性能开销
3. volatile并不能解决线程同步问题
4. 解决i++或者++i这样的线程同步问题需要使用synchronized或者AtomicXX系列的包装类,同时也会增加性能开销

15、线程池的种类，区别和使用场景？

一个线程从被提交（submit）到执行共经历以下流程：

• 线程池判断核心线程池里是的线程是否都在执行任务，如果不是，则创建一个新的工作线程来执行任务。如果核心线程池里的线程都在执行任务，则进入下一个流程
• 线程池判断工作队列是否已满。如果工作队列没有满，则将新提交的任务储存在这个工作队列里。如果工作队列满了，则进入下一个流程。
• 线程池判断其内部线程是否都处于工作状态。如果没有，则创建一个新的工作线程来执行任务。如果已满了，则交给饱和策略来处理这个任务。

 

任务拒接策略？

 有4种内置的实现策略和一个用户自定义拒绝策略。

AbortPolicy       为java线程池默认的阻塞策略，不执行此任务，而且直接抛出一个运行时异常，切记ThreadPoolExecutor.execute需要try catch，否则程序会直接退出。 

DiscardPolicy        直接抛弃，任务不执行，空方法 。

DiscardOldestPolicy   从队 列里面抛弃head的一个任务，并再次execute 此task。

CallerRunsPolicy        在调用execute的线程里面执行此command，会阻塞入口 。 

用户自定义拒绝策略   实现RejectedExecutionHandler，并自己定义策略模式。

 

再次需要注意的是，ThreadPoolExecutor.submit（） 函数，此方法内部调用的execute方法，并把execute执行完后的结果给返回，但如果任务并没有执行的话（被拒绝了），则submit返回的future.get()会一直等到。

future 内部其实还是一个runnable，并把command给封装了下，当command执行完后，future会返回一个值。

 

 

newCachedThreadPool：

• 底层：返回ThreadPoolExecutor实例，corePoolSize为0；maximumPoolSize为Integer.MAX_VALUE；keepAliveTime为60L；unit为TimeUnit.SECONDS；workQueue为SynchronousQueue(同步队列)
• 通俗：当有新任务到来，则插入到SynchronousQueue中，由于SynchronousQueue是同步队列，因此会在池中寻找可用线程来执行，若有可以线程则执行，若没有可用线程则创建一个线程来执行该任务；若池中线程空闲时间超过指定大小，则该线程会被销毁。
• 适用：执行很多短期异步的小程序或者负载较轻的服务器

newFixedThreadPool：

• 底层：返回ThreadPoolExecutor实例，接收参数为所设定线程数量nThread，corePoolSize为nThread，maximumPoolSize为nThread；keepAliveTime为0L(不限时)；unit为：TimeUnit.MILLISECONDS；WorkQueue为：new LinkedBlockingQueue<Runnable>() 无解阻塞队列
• 通俗：创建可容纳固定数量线程的池子，每隔线程的存活时间是无限的，当池子满了就不在添加线程了；如果池中的所有线程均在繁忙状态，对于新任务会进入阻塞队列中(无界的阻塞队列)
• 适用：执行长期的任务，性能好很多

newSingleThreadExecutor:

• 底层：FinalizableDelegatedExecutorService包装的ThreadPoolExecutor实例，corePoolSize为1；maximumPoolSize为1；keepAliveTime为0L；unit为：TimeUnit.MILLISECONDS；workQueue为：new LinkedBlockingQueue<Runnable>() 无解阻塞队列
• 通俗：创建只有一个线程的线程池，且线程的存活时间是无限的；当该线程正繁忙时，对于新任务会进入阻塞队列中(无界的阻塞队列)
• 适用：一个任务一个任务执行的场景

NewScheduledThreadPool:

• 底层：创建ScheduledThreadPoolExecutor实例，corePoolSize为传递来的参数，maximumPoolSize为Integer.MAX_VALUE；keepAliveTime为0；unit为：TimeUnit.NANOSECONDS；workQueue为：new DelayedWorkQueue() 一个按超时时间升序排序的队列
• 通俗：创建一个固定大小的线程池，线程池内线程存活时间无限制，线程池可以支持定时及周期性任务执行，如果所有线程均处于繁忙状态，对于新任务会进入DelayedWorkQueue队列中，这是一种按照超时时间排序的队列结构
• 适用：周期性执行任务的场景

线程池任务执行流程：

1. 当线程池小于corePoolSize时，新提交任务将创建一个新线程执行任务，即使此时线程池中存在空闲线程。
2. 当线程池达到corePoolSize时，新提交任务将被放入workQueue中，等待线程池中任务调度执行
3. 当workQueue已满，且maximumPoolSize>corePoolSize时，新提交任务会创建新线程执行任务
4. 当提交任务数超过maximumPoolSize时，新提交任务由RejectedExecutionHandler处理
5. 当线程池中超过corePoolSize线程，空闲时间达到keepAliveTime时，关闭空闲线程
6. 当设置allowCoreThreadTimeOut(true)时，线程池中corePoolSize线程空闲时间达到keepAliveTime也将关闭

16、分析线程池的实现原理和线程的调度过程？

ThreadPoolExecutor

调度线程执行器ScheduledThreadPoolExecutor是线程执行器ThreadPoolExecutor的扩展，在ThreadPoolExecutor基础之上添加了在一定时间间隔之后调度任务的核心功能，也包括之后的按既定时间间隔去调度任务的功能。

 

17、线程池如何调优，最大数目如何确认？

线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程。

 

18、ThreadLocal原理，用的时候需要注意什么？

  ThreadLocal，很多地方叫做线程本地变量，也有些地方叫做线程本地存储，ThreadLocal为变量在每个线程中都创建了一个副本，那么每个线程可以访问自己内部的副本变量。

19、CountDownLatch 和 CyclicBarrier 的用法，以及相互之间的差别?

20、LockSupport工具

21、Condition接口及其实现原理

22、Fork/Join框架的理解

23、分段锁的原理,锁力度减小的思考

24、八种阻塞队列以及各个阻塞队列的特性

25、 ReenTrantLock可重入锁（和synchronized的区别）总结

可重入性：

从名字上理解，ReenTrantLock的字面意思就是再进入的锁，其实synchronized关键字所使用的锁也是可重入的，两者关于这个的区别不大。两者都是同一个线程没进入一次，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。

 

锁的实现：

Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的，有什么区别，说白了就类似于操作系统来控制实现和用户自己敲代码实现的区别。前者的实现是比较难见到的，后者有直接的源码可供阅读。

 

性能的区别：

在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。

 

功能区别：

便利性：很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。

锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized

 

ReenTrantLock独有的能力：

1.      ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。

2.      ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。

3.      ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。

 

ReenTrantLock实现的原理：

在网上看到相关的源码分析，本来这块应该是本文的核心，但是感觉比较复杂就不一一详解了，简单来说，ReenTrantLock的实现是一种自旋锁，通过循环调用CAS操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。

 

什么情况下使用ReenTrantLock：

答案是，如果你需要实现ReenTrantLock的三个独有功能时。

Spring

1、BeanFactory 和 FactoryBean？

区别：BeanFactory是个Factory，也就是IOC容器或对象工厂，FactoryBean是个Bean。在Spring中，所有的Bean都是由BeanFactory(也就是IOC容器)来进行管理的。但对FactoryBean而言，这个Bean不是简单的Bean，而是一个能生产或者修饰对象生成的工厂Bean,它的实现与设计模式中的工厂模式和修饰器模式类似

 

2、Spring IOC 的理解，其初始化过程？

　在创建ApplicationContext实例对象过程中会创建一个spring容器，该容器会读取配置文件"cjj/models/beans.xml",并统一管理由该文件中定义好的所有bean实例对象，如果要获取某个bean实例，使用getBean方法就行了。例如我们只需要将Person提前配置在beans.xml文件中（可以理解为注入），之后我们可以不需使用new Person()的方式创建实例，而是通过容器来获取Person实例，这就相当于将Person的控制权交由spring容器了，差不多这就是控制反转的概念。

3、BeanFactory 和 ApplicationContext？

BeanFacotry是spring中比较原始的Factory。如XMLBeanFactory就是一种典型的BeanFactory。原始的BeanFactory无法支持spring的许多插件，如AOP功能、Web应用等。 

  ApplicationContext接口,它由BeanFactory接口派生而来，因而提供BeanFactory所有的功能。ApplicationContext以一种更向面向框架的方式工作以及对上下文进行分层和实现继承，ApplicationContext包还提供了以下的功能： 

  • MessageSource, 提供国际化的消息访问  

  • 资源访问，如URL和文件  

  • 事件传播  

  • 载入多个（有继承关系）上下文 ，使得每一个上下文都专注于一个特定的层次，比如应用的web层  

4、Spring Bean 的生命周期，如何被管理的？

1. 实例化一个Bean，也就是我们通常说的new

2. 按照Spring上下文对实例化的Bean进行配置，也就是IOC注入

3. 如果这个Bean实现了BeanNameAware接口，会调用它实现的setBeanName(String beanId)方法，此处传递的是Spring配置文件中Bean的ID

4. 如果这个Bean实现了BeanFactoryAware接口，会调用它实现的setBeanFactory()，传递的是Spring工厂本身（可以用这个方法获取到其他Bean）

5. 如果这个Bean实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文，该方式同样可以实现步骤4，但比4更好，以为ApplicationContext是BeanFactory的子接口，有更多的实现方法

6. 如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用After方法，也可用于内存或缓存技术

7. 如果这个Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法

8. 如果这个Bean关联了BeanPostProcessor接口，将会调用postAfterInitialization(Object obj, String s)方法

注意：以上工作完成以后就可以用这个Bean了，那这个Bean是一个single的，所以一般情况下我们调用同一个ID的Bean会是在内容地址相同的实例

9. 当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean接口，会调用其实现的destroy方法

10. 最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法

5、Spring Bean 的加载过程是怎样的？

 

一个是populateBean,一个是initializeBean，这两个方法完成了bean的赋值与初始化。

这里有一个BeanDefinitionValueResolver，这个类用来解析property里的value，如果是依赖其他bean则会到容器中找是否存在如果有则返回，没有则创建一个。spring又为每个对象的属性定义了一个数据结构：PropertyValue,这样做加大了容器对bean属性的修改的灵活性，上面的方法就是对每个属性进行处理然后通过beanWapper的setPropertyValues进行赋值。

这里注意一下，bean有singleton和prototype两种 ，对于prototype，spring采用了原型模式，使用对象的deepcopy。

至此，spring完成了对实例的赋值，然后就是调用initializeBean：

6、如果要你实现Spring AOP，请问怎么实现？

实现AOP的技术，主要分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；二是采用静态织入的方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码。

7、如果要你实现Spring IOC，你会注意哪些问题？

8、Spring 是如何管理事务的，事务管理机制？

Spring 支持两种方式事务管理

一：编程式的事务管理

通过TransactionTemplate手动管理事务

在实际应用中很少使用，原因是要修改原来的代码，加入事务管理代码 （侵入性 ）

 

二：声明式事务管理（XML配置文件方式或注解方式）

Spring的声明式事务是通过AOP实现的（环绕通知）

开发中经常使用（代码侵入性最小）--推荐使用！

注：后面会演示声明式事务管理的两种方式：xml配置文件方式和注解方式，不演示编程式方式

 

Spring的事务机制包括声明式事务和编程式事务。

编程式事务管理：Spring推荐使用TransactionTemplate，实际开发中使用声明式事务较多。

声明式事务管理：将我们从复杂的事务处理中解脱出来，获取连接，关闭连接、事务提交、回滚、异常处理等这些操作都不用我们处理了，Spring都会帮我们处理。

声明式事务管理使用了AOP面向切面编程实现的，本质就是在目标方法执行前后进行拦截。在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。

 

 

9、Spring 的不同事务传播行为有哪些，干什么用的？

10、Spring 中用到了那些设计模式？

11、Spring MVC 的工作原理？

12、Spring 循环注入的原理？

13、Spring AOP的理解，各个术语，他们是怎么相互工作的？

14、Spring 如何保证 Controller 并发的安全？

Netty

1、BIO、NIO和AIO

BIO（Blocking I/O）同步阻塞I/O

这是最基本与简单的I/O操作方式，其根本特性是做完一件事再去做另一件事，一件事一定要等前一件事做完，这很符合程序员传统的顺序来开发思想，因此BIO模型程序开发起来较为简单，易于把握。

 

NIO (New I/O) 同步非阻塞I/O

关于NIO，国内有很多技术博客将英文翻译成No-Blocking I/O，非阻塞I/O模型 ，当然这样就与BIO形成了鲜明的特性对比。NIO本身是基于事件驱动的思想来实现的，其目的就是解决BIO的大并发问题，在BIO模型中，如果需要并发处理多个I/O请求，那就需要多线程来支持，NIO使用了多路复用器机制

 

AIO (Asynchronous I/O) 异步非阻塞I/O

Java AIO就是Java作为对异步IO提供支持的NIO.2

 

AIO相对于NIO的区别在于，NIO需要使用者线程不停的轮询IO对象，来确定是否有数据准备好可以读了，而AIO则是在数据准备好之后，才会通知数据使用者，这样使用者就不需要不停地轮询了。

 

 

2、Netty 的各大组件

1 Bootstrap 

一个应用通常有一个Bootstrap 开始，他主要是配置整个Netty 程序，串联各个组件，Bootstrap 有两种类型，ServerBootstrap 和 Bootstrap 分别用于Serber 端和 Client 端 

2 Channel 渠道 （ChannelFuture） 

代表一个Socker链接 或者其他的IO相关组件 

3 EventLoop （NioEventLoopGroup 

） 

为Channel 处理I/O操作 一个EventLoop 可以为多个Channel 服务，理解为一个线程。 

4 EventLoopGroup 

一个EventLoopGroup 包含多个EventLoop 可以理解为一个线程池 

5 Handler 

3、Netty的线程模型

4、TCP 粘包/拆包的原因及解决方法

如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题。

 但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

 

 

发生TCP粘包或拆包有很多原因，现列出常见的几点，可能不全面，欢迎补充，

1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。

2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。

3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

 

 

通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：

1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

 

 

5、了解哪几种序列化协议？包括使用场景和如何去选择

 

Serializable

JSON

Fastjson是一个Java语言编写的高性能功能完善的JSON库。

Thrift并不仅仅是序列化协议，而是一个RPC框架。

 

 

6、Netty的零拷贝实现

Zero-copy, 就是在操作数据时, 不需要将数据 buffer 从一个内存区域拷贝到另一个内存区域. 因为少了一次内存的拷贝, 因此 CPU 的效率就得到的提升.

 

7、Netty的高性能表现在哪些方面

从大的方面看，netty性能高效主要体现在：

1.io线程模型

使用reactor模式，同步非阻塞。这决定了可以用最少的资源做更多的事。

2.内存零拷贝

使用直接缓存

3.内存池设计

申请的内存可以重用，主要指直接内存。

内部实现是用一颗二叉查找树管理内存分配情况。

4.串形化处理socket读写，避免锁，即一个指定socket的消息是串形化处理的。这样性能比多个线程同时 处理一个socket对应消息要好，因为多线程处理会有锁。

5.提供对protobuf等高性能序列化协议支持

 

分布式相关

1、Dubbo的底层实现原理和机制

–高性能和透明化的RPC远程服务调用方案

–SOA服务治理方案

 

Dubbo缺省协议采用单一长连接和NIO异步通讯，

适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况

 

 

2、描述一个服务从发布到被消费的详细过程

务。首先先获取zk的配置信息，然后获取需要暴露的url，然后调用registry.register方法将url注册到zookeeper上去。

3、分布式系统怎么做服务治理

针对互联网业务的特点，eg 突发的流量高峰、网络延时、机房故障等，重点针对大规模跨机房的海量服务进行运行态治理，保障线上服务的高SLA，满足用户的体验，常用的策略包括限流降级、服务嵌入迁出、服务动态路由和灰度发布等

 

4、接口的幂等性的概念

幂等的意思是同一个操作，重复执行多次，跟执行一次结果一致。消息幂等，即消息发送操作对于消息消费来说是幂等。也就是相同的消息发送多次，跟发送一次是一样的，这个消息只会被消费一次。

 

 

5、消息中间件如何解决消息丢失问题

为了解决消息丢失问题，我们引入了一些重发机制，但也带来的另外一个问题：消息重复，我们来看下都有哪些情况会导致消息重复：

 

消息发送超时，处于不确定状态，导致重试发送消息，有可能之前的消息已经发送成功，会出现消息重复的情况。解决的思路是，每个消息生成一个消息id，如果发送的消息Broker已经存在了，则丢弃。这种解决办法需要维护一个已经接收的消息的message id list。

 

消息在Broker中只有一份，但是consumer重启前，未及时更新offset，导致consumer重启之后重复消费消息。

上游业务给每个message 分配一个message ID，下游业务在接收到message之后，执行业务并且保存message ID，而且要讲两部分放到同一个事务中，保证业务执行成功，message ID肯定保存，业务执行失败，message ID肯定不会保存下来，利用db中存储的message id来做幂等。我们可以重新封装producer client和consumer client，将这部分message ID分配和判重的逻辑封装到client lib里面。

 

 

6、Dubbo的服务请求失败怎么处理

dubbo启动时默认有重试机制和超时机制。

超时机制的规则是如果在一定的时间内，provider没有返回，则认为本次调用失败，

重试机制在出现调用失败时，会再次调用。如果在配置的调用次数内都失败，则认为此次请求异常，抛出异常。

 

7、重连机制会不会造成错误

dubbo在调用服务不成功时，默认会重试2次。

Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。

但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，

系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。

8、对分布式事务的理解

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。  

事务的ACID特性 原子性  一致性 隔离性 持久性

消息事务+最终一致性

CC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

 

 

9、如何实现负载均衡，有哪些算法可以实现？

 经常会用到以下四种算法：随机（random）、轮训（round-robin）、一致哈希（consistent-hash）和主备（master-slave）。

 

 

10、Zookeeper的用途，选举的原理是什么？

11、数据的垂直拆分水平拆分。

12、zookeeper原理和适用场景

13、zookeeper watch机制

Znode发生变化（Znode本身的增加，删除，修改，以及子Znode的变化）可以通过Watch机制通知到客户端。那么要实现Watch，就必须实现org.apache.zookeeper.Watcher接口，并且将实现类的对象传入到可以Watch的方法中。Zookeeper中所有读操作（getData()，getChildren()，exists()）都可以设置Watch选项。

 

14、redis/zk节点宕机如何处理

15、分布式集群下如何做到唯一序列号

 

Redis生成ID 这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

 

 

16、如何做一个分布式锁

17、用过哪些MQ，怎么用的，和其他mq比较有什么优缺点，MQ的连接是线程安全的吗

RabbitMQ 支持 AMQP（二进制），STOMP（文本），MQTT（二进制），HTTP（里面包装其他协议）等协议。Kafka 使用自己的协议。

Kafka 自身服务和消费者都需要依赖 Zookeeper。

RabbitMQ 在有大量消息堆积的情况下性能会下降，Kafka不会。毕竟AMQP设计的初衷不是用来持久化海量消息的，而Kafka一开始是用来处理海量日志的。

总的来说，RabbitMQ 和 Kafka 都是十分优秀的分布式的消息代理服务，只要合理部署，不作，基本上可以满足生产条件下的任何需求。

 

 

 

18、MQ系统的数据如何保证不丢失

在数据生产时避免数据丢失的方法：

只要能避免上述两种情况，那么就可以保证消息不会被丢失。

1）就是说在同步模式的时候，确认机制设置为-1，也就是让消息写入leader和所有的副本。

2）还有，在异步模式下，如果消息发出去了，但还没有收到确认的时候，缓冲池满了，在配置文件中设置成不限制阻塞超时的时间，也就说让生产端一直阻塞，这样也能保证数据不会丢失。

在数据消费时，避免数据丢失的方法：如果使用了storm，要开启storm的ackfail机制；如果没有使用storm，确认数据被完成处理之后，再更新offset值。低级API中需要手动控制offset值。

 

数据重复消费的情况，如果处理

（1）去重：将消息的唯一标识保存到外部介质中，每次消费处理时判断是否处理过；

（2）不管：大数据场景中，报表系统或者日志信息丢失几条都无所谓，不会影响最终的统计分析结

 

19、列举出你能想到的数据库分库分表策略；分库分表后，如何解决全表查询的问题

：业务拆分、主从复制，数据库分库与分表

使用用户ID是最常用的分库的路由策略。用户的ID可以作为贯穿整个系统用的重要字段。因此，使用用户的ID我们不仅可以方便我们的查询

垂直分表

水平分表

 

 

20、zookeeper的选举策略

在zookeeper集群中也是一样，每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了。

zookeeper中有三种选举算法，分别是LeaderElection,FastLeaderElection,AuthLeaderElection，

FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果，而是不断的统计结果，一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。

 

21、全局ID

Snowflake

redis

 

数据库

1、mysql分页有什么优化

一般分页查询

一般的分页查询使用简单的 limit 子句就可以实现。limit 子句声明如下：

 

使用子查询优化

这种方式先定位偏移位置的 id，然后往后查询，这种方式适用于 id 递增的情况。

 

使用 id 限定优化

这种方式假设数据表的id是连续递增的，则我们根据查询的页数和查询的记录数可以算出查询的id的范围，可以使用 id between and 来查询：

 

 

2、悲观锁、乐观锁

3、组合索引，最左原则

最左前缀：顾名思义，就是最左优先，上例中我们创建了lname_fname_age多列索引,相当于创建了(lname)单列索引，(lname,fname)组合索引以及(lname,fname,age)组合索引。 

注：在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。

 

 

4、mysql 的表锁、行锁

开销、加锁速度、死锁、粒度、并发性能

• 表锁：开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低
• 行锁：开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高

5、mysql 性能优化

6、mysql的索引分类：B+，hash；什么情况用什么索引

 

很简单 用plsql developer 按F5 执行计划分析

你只要看出来的对话框中间节点的表述，是full 表示你走的是全表遍历

如果是hash或其他的 则表示走的是索引

看看cost也能知道时间消耗情况

 

 

，也就是b tree或者 b+ tree，重要的事情说三遍：“平衡树，平衡树，平衡树”。当然， 有的数据库也使用哈希桶作用索引的数据结构 ， 然而， 主流的RDBMS都是把平衡树当做数据表默认的索引数据结构的。

我们平时建表的时候都会为表加上主键， 在某些关系数据库中， 如果建表时不指定主键，数据库会拒绝建表的语句执行。 事实上， 一个加了主键的表，并不能被称之为「表」。一个没加主键的表，它的数据无序的放置在磁盘存储器上，一行一行的排列的很整齐， 跟我认知中的「表」很接近。如果给表上了主键，那么表在磁盘上的存储结构就由整齐排列的结构转变成了树状结构，也就是上面说的「平衡树」结构，换句话说，就是整个表就变成了一个索引。

B+Tree索引

B+Tree是mysql使用最频繁的一个索引数据结构，是Inodb和Myisam存储引擎模式的索引类型。相对Hash索引，B+Tree在查找单条记录的速度比不上Hash索引，但是因为更适合排序等操作，所以它更受欢迎。毕竟不可能只对数据库进行单条记录的操作。

带顺序访问指针的B+Tree

B+Tree所有索引数据都在叶子节点上，并且增加了顺序访问指针，每个叶子节点都有指向相邻叶子节点的指针。

这样做是为了提高区间效率，例如查询key为从18到49的所有数据记录，当找到18后，只要顺着节点和指针顺序遍历就可以以此向访问到所有数据节点，极大提高了区间查询效率。

大大减少磁盘I/O读取

数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点需要一次I/O就可以完全载入。

 

 

 

 

 

7、事务的特性和隔离级别

•     数据库事务的几个特性：

    原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。

•     数据库事务怎么保证一致性？

    数据库进行任何写入操作的时候都是要先写日志的，同样的道理，我们在执行事务的时候数据库首先会记录下这个事务的redo操作日志，然后才开始真正操作数据库，

    在操作之前，首先会把日志文件写入磁盘，那么当突然断电的时候，即使操作没有完成，在重新启动数据库时候，数据库会根据当前数据的情况进行undo回滚或者是redo前滚，

    这样就保证了数据的强一致性。

•     数据库隔离级别：

    ① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。

　　② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。

　　③ Read committed (读已提交)：可避免脏读的发生。

　　④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。

缓存

1、Redis用过哪些数据数据，以及Redis底层怎么实现

Redis对象类型简介

Redis是一种key/value型数据库，其中，每个key和value都是使用对象表示的。

 

 

2、Redis缓存穿透，缓存雪崩

缓存穿透

什么是缓存穿透？

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

 

如何避免？

1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。

2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。【感觉应该用的不多吧】

缓存雪崩

什么是缓存雪崩？

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

如何避免？

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

2：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

3：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期（此点为补充）

 

 

3、如何使用Redis来实现分布式锁

4、Redis的并发竞争问题如何解决

5、Redis持久化的几种方式，优缺点是什么，怎么实现的

redis两种持久化的方式

• RDB持久化可以在指定的时间间隔内生成数据集的时间点快照
• AOF持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集,AOF文件中全部以redis协议的格式来保存,新命令会被追加到文件的末尾,redis还可以在后台对AOF文件进行重写,文件的体积不会超出保存数据集状态所需要的实际大小,
• redis还可以同时使用AOF持久化和RDB持久化,在这种情况下,当redis重启时,它会有限使用AOF文件来还原数据集,因为AOF文件保存的数据集通常比RDB文件所保存的数据集更加完

 

 

6、Redis的缓存失效策略

7、Redis集群，高可用，原理

8、Redis缓存分片

分片(partitioning)就是将你的数据拆分到多个 Redis 实例的过程，这样每个实例将只包含所有键的子集。本文第一部分将向你介绍分片的概念，第二部分将向你展示 Redis 分片的可选方案。

 

9、Redis的数据淘汰策略

在一台 8G 机子上部署了 4 个 redis 服务点，每一个服务点分配 1.5G 的内存大小，减少内存紧张的情况，由此获取更为稳健的服务。

redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。 

 

 

10、redis和memcached的区别（总结）

1、Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等；

2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储；

3、虚拟内存--Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘；

4、过期策略--memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10；

5、分布式--设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从；

6、存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）；

7、灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；

8、Redis支持数据的备份，即master-slave模式的数据备份；

 

11、Redis的高并发和快速原因很多，总结一下几点：

        1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。

        2. 再说一下IO，Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。

        3. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。

        4. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

        5. 还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

 

JVM

1、详细jvm内存模型

2、讲讲什么情况下回出现内存溢出，内存泄漏？

1>当程序在申请内存后,,无法释放已经申请的内存空间(例如一个对象或者变量使用完成后没有释放,这个对对象一直占用着内存),一次内存泄漏的危害可以忽略,但是内存泄露堆积的后果很严重,无论多少内存,迟早会被占光,内存泄露最终会导致内存溢出

2>当程序申请内存时,没有足够的内存空间供其使用,出现了out of memory;比如申请了一个int,但给他存放了long才能存下的数,就是内存溢出.

3、说说Java线程栈

 

4、JVM 年轻代到年老代的晋升过程的判断条件是什么呢？

 

 

5、JVM 出现 fullGC 很频繁，怎么去线上排查问题？

我们知道Full GC的触发条件大致情况有以下几种情况：

1. 程序执行了System.gc() //建议jvm执行fullgc，并不一定会执行
2. 执行了jmap -histo:live pid命令 //这个会立即触发fullgc
3. 在执行minor gc的时候进行的一系列检查
4. 执行Minor GC的时候，JVM会检查老年代中最大连续可用空间是否大于了当前新生代所有对象的总大小。 
5. 使用了大对象 //大对象会直接进入老年代
6. 在程序中长期持有了对象的引用 //对象年龄达到指定阈值也会进入老年代

 

 

6、类加载为什么要使用双亲委派模式，有没有什么场景是打破了这个模式？

7、类的实例化顺序

父静-子静 父初-父构-子初-子构

8、JVM垃圾回收机制，何时触发MinorGC等操作

堆内存分为 年轻代 老年代 和持久代

年轻代 又分为 eden 区和 survivor 区 

这两个区如果满了 触发的就是 minor gc

 

 

9、JVM 中一次完整的 GC 流程（从 ygc 到 fgc）是怎样的

1.YGC和FGC是什么 

   YGC ：对新生代堆进行gc。频率比较高，因为大部分对象的存活寿命较短，在新生代里被回收。性能耗费较小。

   FGC ：全堆范围的gc。默认堆空间使用到达80%(可调整)的时候会触发fgc。以我们生产环境为例，一般比较少会触发fgc，有时10天或一周左右会有一次。

2.什么时候执行YGC和FGC

   a.edn空间不足,执行 young gc

   b.old空间不足，perm空间不足，调用方法System.gc() ，ygc时的悲观策略, dump live的内存信息时(jmap –dump:live)，都会执行full gc

 

10、各种回收器，各自优缺点，重点CMS、G1

CMS收集器

  CMS收集器是一种以获取最短回收停顿时间为目标的收集器。基于“标记-清除”算法实现，它的运作过程如下：

1）初始标记

2）并发标记

3）重新标记

4）并发清除

  初始标记、从新标记这两个步骤仍然需要“stop the world”，初始标记仅仅只是标记一下GC Roots能直接关联到的对象，熟读很快，并发标记阶段就是进行GC Roots Tracing，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生表动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长点，但远比并发标记的时间短。

 

  CMS是一款优秀的收集器，主要优点：并发收集、低停顿。

缺点：

1）CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。

2）CMS收集器无法处理浮动垃圾，可能会出现“Concurrent Mode Failure（并发模式故障）”失败而导致Full GC产生。

浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就会有新的垃圾不断产生，这部分垃圾出现的标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC中再清理。这些垃圾就是“浮动垃圾”。

3）CMS是一款“标记--清除”算法实现的收集器，容易出现大量空间碎片。当空间碎片过多，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

2、G1收集器

G1是一款面向服务端应用的垃圾收集器。G1具备如下特点：

1、并行于并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

2、分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。它能够采用不同的方式去处理新创建的对象和已经存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果。

3、空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

4、可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和ＣＭＳ共同的关注点，但Ｇ１除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，

5、G1运作步骤：

1、初始标记；2、并发标记；3、最终标记；4、筛选回收

上面几个步骤的运作过程和CMS有很多相似之处。初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS的值，让下一个阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这一阶段需要停顿线程，但是耗时很短，并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段时耗时较长，但可与用户程序并发执行。而最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remenbered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这一阶段需要停顿线程，但是可并行执行。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。

11、各种回收算法

      关于垃圾回收的机制，这里不再解释，这篇文章我主要介绍常见的垃圾回收算法，当然还有其他的。

算法一：引用计数法。

            这个方法是最经典点的一种方法。具体是对于对象设置一个引用计数器，每增加一个变量对它的引用，引用计数器就会加1，没减少一个变量的引用，

            引用计数器就会减1，只有当对象的引用计数器变成0时，该对象才会被回收。可见这个算法很简单，但是简单往往会存在很多问题，这里我列举最明显的两个问题，

            一是采用这种方法后，每次在增加变量引用和减少引用时都要进行加法或减法操作，如果频繁操作对象的话，在一定程度上增加的系统的消耗。

            二是这种方法无法处理循环引用的情况。再解释下什么是循环引用，假设有两个对象 A和B，A中引用了B对象，并且B中也引用了A对象，

                     那么这时两个对象的引用计数器都不为0，但是由于存在相互引用导致无法垃圾回收A和 B，导致内存泄漏。

算法二：标记清除法。

            这个方法是将垃圾回收分成了两个阶段：标记阶段和清除阶段。

            在标记阶段，通过跟对象，标记所有从跟节点开始的可达的对象，那么未标记的对象就是未被引用的垃圾对象。

            在清除阶段，清除掉所以的未被标记的对象。

            这个方法的缺点是，垃圾回收后可能存在大量的磁盘碎片，准确的说是内存碎片。因为对象所占用的地址空间是固定的。对于这个算法还有改进的算法，就是我后面要说的算法三。

算法三：标记压缩清除法（Java中老年代采用）。

            在算法二的基础上做了一个改进，可以说这个算法分为三个阶段：标记阶段，压缩阶段，清除阶段。标记阶段和清除阶段不变，只不过增加了一个压缩阶段，就是在做完标记阶段后，

            将这些标记过的对象集中放到一起，确定开始和结束地址，比如全部放到开始处，这样再去清除，将不会产生磁盘碎片。但是我们也要注意到几个问题，压缩阶段占用了系统的消耗，

            并且如果标记对象过多的话，损耗可能会很大，在标记对象相对较少的时候，效率较高。

算法四：复制算法（Java中新生代采用）。

           核心思想是将内存空间分成两块，同一时刻只使用其中的一块，在垃圾回收时将正在使用的内存中的存活的对象复制到未使用的内存中，然后清除正在使用的内存块中所有的对象，

           然后把未使用的内存块变成正在使用的内存块，把原来使用的内存块变成未使用的内存块。很明显如果存活对象较多的话，算法效率会比较差，并且这样会使内存的空间折半，但是这种方法也不会产生内存碎片。

算法五：分代法（Java堆采用）。

          主要思想是根据对象的生命周期长短特点将其进行分块，根据每块内存区间的特点，使用不同的回收算法，从而提高垃圾回收的效率。

          比如Java虚拟机中的堆就采用了这种方法分成了新生代和老年代。然后对于不同的代采用不同的垃圾回收算法。

          新生代使用了复制算法，老年代使用了标记压缩清除算法。

算法六：分区算法。

           这种方法将整个空间划分成连续的不同的小区间，每个区间都独立使用，独立回收，好处是可以控制一次回收多少个小区间。

 

 总结：各种回收算法都有各自的优缺点，没有一种算法可以完全替代其他的算法，在具体的使用中应该结合具体的环境来选择。

12、OOM错误，stackoverflow错误，permgen space错误

 

堆内存溢出

 

【情况一】： 

　　java.lang.OutOfMemoryError: Java heap space：这种是java堆内存不够，一个原因是真不够，另一个原因是程序中有死循环； 

　　如果是java堆内存不够的话，可以通过调整JVM下面的配置来解决： 

　　< jvm-arg>-Xms3062m < / jvm-arg> 

　　< jvm-arg>-Xmx3062m < / jvm-arg> 

　　 

【情况二】 

　　java.lang.OutOfMemoryError: GC overhead limit exceeded 

　　【解释】：JDK6新增错误类型，当GC为释放很小空间占用大量时间时抛出；一般是因为堆太小，导致异常的原因，没有足够的内存。 

　　【解决方案】： 

　　1、查看系统是否有使用大内存的代码或死循环； 

　　2、通过添加JVM配置，来限制使用内存： 

　　< jvm-arg>-XX:-UseGCOverheadLimit< /jvm-arg> 

　　 

【情况三】： 

　　java.lang.OutOfMemoryError: PermGen space：这种是P区内存不够，可通过调整JVM的配置： 

　　< jvm-arg>-XX:MaxPermSize=128m< /jvm-arg> 

　　< jvm-arg>-XXermSize=128m< /jvm-arg> 

　　【注】： 

　　JVM的Perm区主要用于存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space，这个区域成为年老代，GC在主程序运行期间不会对年老区进行清理，默认是64M大小，当程序需要加载的对象比较多时，超过64M就会报这部分内存溢出了，需要加大内存分配，一般128m足够。 

　　 

【情况四】： 

　　java.lang.OutOfMemoryError: Direct buffer memory 

　　调整-XX:MaxDirectMemorySize= 参数，如添加JVM配置： 

　　< jvm-arg>-XX:MaxDirectMemorySize=128m< /jvm-arg> 

　　 

【情况五】： 

　　java.lang.OutOfMemoryError: unable to create new native thread 

　　【原因】：Stack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小了。 

　　【解决】：由于JVM没有提供参数设置总的stack空间大小，但可以设置单个线程栈的大小；而系统的用户空间一共是3G，除了Text/Data/BSS /MemoryMapping几个段之外，Heap和Stack空间的总量有限，是此消彼长的。因此遇到这个错误，可以通过两个途径解决： 

　　1.通过 -Xss启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError）； 

　　2.通过-Xms -Xmx 两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）。 

　　 

【情况六】： 

　　java.lang.StackOverflowError 

　　【原因】：这也内存溢出错误的一种，即线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小。 

　　【解决】：优化程序设计，减少方法调用层次；调整-Xss参数增加线程栈大小。 

 

 

WebX框架是阿里巴巴集团开发的，它建立在SpringEx的基础上，具有超强的扩展能力。

一、Webx的层次结构（从里到外）

（1）SpringExt：基于Spring，提供扩展组件的能力

（2）Webx Framework：基于Servlet API，提供基础服务

（3）Webx Turbine：基于Webx Framework，实现具体的网页功能

二、Webx的初始化

位置：/WEB-INF/web.xml文件

 

结果：自动搜索/WEB-INF目录下的XML配置文件，并创建级联的Spring容器。

/WEB-INF/webx.xml->/WEB-INF/web-app1.xml->/WEB-INF/webx-app2.xml

三、初始化日志系统

添加方式：

 

四、Webx响应请求

Webx响应请求的流程：

（1）WebxFrameworkFilter接收请求

（2）WebxRootController创建和处理request context，路由到子应用，并提供处理异常、开发模式功能。

（3）WebxController进行apps' pipeline

当一个HTTP请求到达时，WebxFrameworkFilter接收请求的模板配置（/WEB-INF/webx.xml）如下：

 

为什么使用filter而不是servlet？如果webx发现某个请求不应该由webx来处理，就会把控制“返还”给原来的控制器，而Servlet不具备“返还控制”的机制。

RequestContext对象的标准模板如下：

五、Webx Turbine

它的基本准则是：约定胜于配置，即：工程师只需要根据一定的规则，将模板放在指定的目录、按照预定的方式命令module（也就是screen、action、control等），就不再需要额外的配置。

Turbine的基本页面组成为：

 

（1）Screen：代表页面的主体

（2）Layout：代表页面的布局

（3）Control：代表嵌在screen和layout中的页面片段

页面布局图如下：

六、Webx Turbine处理页面的基本流程

Webx Turbine的处理流程被定义在pipeline中，pipeline推荐的配置如下：

 

流程具体解读如下：

（1） 分析URL：：用户访问的主页target

（2） 进入choose，进行多重分支选择

（3）performAction执行action

（4） performTemplateScreen查找并执行screen

假设target为xxx/yyy/zzz，那么Webx Turbine查找screen模块的顺序为：

Screen.xxx.yyy.zzz

Screen.xxx.yyy.Default

Screen.xxx.Default

Screen.Default

（5） 渲染模板

首先映射成screen template，以及映射成layout template

假设target为xxx/yyy/zzz，那么Webx Turbine会查找下面的screen模板：/templates/screen/xxx/yyy/zzz。Screen模板如果未找到，就会报404 Not Found错误。 找到screen模板以后，Webx Turbine还会试着查找下面的layout模板：

    /templates/layout/xxx/yyy/zzz

    /templates/layout/xxx/yyy/default

    /templates/layout/xxx/default

/templates/layout/default

Layout模板如果找不到，就直接渲染screen模板；如果存在，则把渲染screen模板后的结果嵌入到layout模板中。

七、Filter的用途

页面授权：根据登录用户的权限，阻止或许可用户访问特定的页面。

日志和审计：记录和检查用户访问WEB应用的情况。

图片转换：改变图片的格式、精度、尺寸等。

页面压缩：压缩页面内容，加快下载速度。

本地化：显示本地语言和风格的页面。

XSLT转换：对XML内容进行XSLT转换，使之适用于多种客户端。

高速缓存：高速缓存页面，提高响应速度。

使用方法：

 

Webx提供了Request Contexts服务以及Pipeline作为对Filter功能缺陷的补充，作用分别如下：

（1） Request Contexts：负责访问和修改request和response，但不负责改变应用执行的流程

（2） Pipeline：提供应用执行的流程，但不关心和request和response

八、Spring中依赖注入的限制

小作用域的对象不能被注入到大作用域的对象。你不能把request和response作用域的对象注入到singleton对象中。前者在每次WEB请求时，均会创建新的实例，每个线程独享这个request/session作用域的对象；后者是在Spring初始化或第一次使用时被创建，然后被所有的线程共享。假如把某个request/session作用域的对象意外注入到singleton对象中，将可能产生致命的应用错误，甚至导致数据库的错乱。

在Webx中，这样做是可以的！奥秘在于Request Contexts服务对上表所列的这些短期对象作了特殊的处理，使它们可以被注入到singleton对象中。事实上，被注入的只是一个“空壳”，真正的对象是在被访问到的时候才会从线程中取得的。

九、buffered缓存response中内存的实现原理

Webx支持用layout/screen/control等部件共同构成一个页面。其中，每个layout可包含一个screen和多个control，每个screen可包含多个control，每个control还可以在包含其他的control。

一般页面比如通过out.println("

hello world

");就直接输出了，为了还能分开然后再一起显示呢。例如，一个screen中包含了一个control，那么screen可以获得它所调用的control的完整的渲染内容。

这个玄机就是靠来实现的。改变了response的输出流，包括output stream和writer，使写到输出流中的内容被暂存在内存中。当需要时，可以取得缓存中的所有内容。

Buffered机制会延迟服务器对用户的响应，所以某些场景需要关闭该服务。

十、表单验证的模板

该文件form.xml位于WEB-INF的每个子目录中，用于表单的验证

 

 

十一、Eclipse中开发Webx应用

（1）Webx工程目录结构 

srcmain：存放开发代码

src est：存放开发自测代码，如单元测试代码

mainjava：存放java代码

main esources：存放资源定义文件

mainwebapp：web应用配置文件

webapp目录包含（举例）：

 

1）子应用模板目录admin、home、store、user，每个模板目录又由layout、control、screen三个子目录组成，包含对应的模板文件(.vm文件)

2）通用模板目录common

3）WEB-INF目录

这是java web应用必备的配置目录，包含了web.xml（java web应用必备的配置文件）、webx.xml（webx配置文件）、日志配置文件（log4j.xml、logback.xml）、子应用配置文件（webx-admin.xml、webx-home.xml、webx-store.xml、webx-user.xml）；另外还有对应每个子应用的文件夹，用于存放form定义文件（form.xml）和访问权限定义文件（access.xml）；common文件夹中的pipeline.xml和pipeline-exception.xml定义了相关的管道操作流程。

（2）页面获取JAVA层的数据PullTool

在velocity模板中使用pulltool方便我们进行页面输出内容的控制，组织页面的展示，或者是直接取得web层相关的一些对象，直接在vm中调用。由页面拉动业务逻辑，获取并控制需要展示的内容，而非应用程序推动push，这符合webx的页面驱动的模式。

1）是否启动pull服务：

 

在webx.xml文件中进行总的控制

2）指定获取数据的JAVA处理模块

   

指定了获取的数据位于com.xx.web.ui.module.*

3）在/xx/templates/screen下创建testMain.vm（M需要大写）文件，内容如下：

  

4）在/src/main/java/com/web/ui/module/screen下创建文件TestMain.java（webx会自动匹配同名的文件），内容如下：

 

package com.yunos.tv.openbase.web.ui.module.screen;

 

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import com.alibaba.citrus.turbine.Context;

 

public class TestMain {

public void execute(HttpServletRequest request, HttpServletResponse response, Context context) throws Exception{

context.put("name", "Hugh");

}

 

}

 execute方法就是专门用来处理对应请求的，是webx潜规则的地方，它是页面渲染之前处理的方法。

有些参数为：public void execute(@Param("systemVersion") String systemVersion,HttpServletRequest request, HttpServletResponse response, Context context, Navigator nav)，说明如下：第一个参数为传进来的信息，context对象负责页面渲染时部分数据的修改。

 

（2）实现form表单功能

实现用户账号登陆的功能，如果用户不输入则提示用户输入相关信息，效果如下：

 

 

 

其具体代码如下：

login.vm文件：

 

form.xml文件：

 

 

关键点说明如下：

1.

 

这表示提交之后执行的是LoginAction.java，这里的value值login_action在程序内部会被处理成 LoginAction，因此这里如果写成value="LoginAction"，结果是一样的

 

2.

这里提交后表示执行的方法是doUserInfoSumbit方法，如果你要执行其他方法请修改name值name="event_submit_你的方法"

 

3.关联form.xml：首先 #set ($group = $form.loginInfoGroup.defaultInstance)[固定写法，loginInfoGroup对应form.xml中的services:group name="loginInfoGroup"]，然后

 

name对应到form.xml中的规则，group.username.message就是需要显示的错误信息。

 

4.$csrfToken.hiddenField是必须要添加的，防止跨站请求伪造攻击。如果不添加的话，数据是不会从显示层传送给JAVA层的。

 

（3）实现form表单往JAVA层传送数据功能

1、构造与表单对应的类LoginInfo：

package com.yunos.tv.openbase.biz.dataobject;

 

public class LoginInfo {

private String username;

private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

 

}

、1q     其中username和password的值需要和form.xml中定义的保持一致，否则两者无法建立联系。

（2）   2.编辑业务功能LoginAction.java：

     

import com.alibaba.citrus.turbine.dataresolver.FormGroup;

import com.yunos.tv.openbase.biz.dataobject.LoginInfo;

 

public class LoginAction {

 

public void doUserInfoSumbit(@FormGroup("loginInfoGroup")LoginInfo userLoginInfo, HttpServletResponse response, Context context, Navigator nav) throws Exception{

System.out.println("hello");

System.out.println(userLoginInfo.getUsername());

   3.     

            3.如果数据模型LoginInfo和LoginAction不在同一个工程中，则LoginAction应该探测不到LoginInfo.class，需要LoginInfo先编译生成class文件，然后LoginAction才可以使用LoginInfo类。在LoginInfo所在的工程使用mvn clean install命令重新进行编译，然后在LoginAction刷新下引入该类。

         

（

   3

};

 

}

     （

2、

 

   

 

 

 

 

 

 

WEB-INF文件夹下各个配置文件说明

• logback.xml：日志配置；
• web.xml：WEB工程初始化配置信息；
• webx.xml：webx通用配置，webx容器初始化的Bean能够让所有子业务容器依赖。
• webx-app1.xml：webx子业务配置，子业务配置能够创建spring容器，但子业务容器之间是不能互相注入的。

具体内容可以查看框架说明书《3.1. Webx的初始化》

 

WEB-INF/common文件夹下各个配置文件说明

• pipeline.xml：拦截器配置文件，相当于SpringMVC(Struts)中的Interceptor。
• pipeline-exception.xml：异常拦截配置文件。
• resources.xml：资源文件加载配置，负责资源的重定向、重命名等。
• uris.xml：外部地址url调用配置文件。
• webx-component-and-root.xml：配置模板渲染引擎、映射规则等。
• webx-component.xml：定义模板页面能够直接使用的工具类。

从这些配置可以看出，webx与我们接触的SpringMVC、Struts类似，只不过前者控制更加细粒度化，而后者我们更多的是使用开源的封装，所以配置量较少。

 

代码结构及编写

对于开发人员来说，最关心的莫过于上手去用这个框架。从工程接收请求到服务器响应并返回信息这整个过程，webx有自己的规则，与我们所接触的开源框架有所区别。如下图：

根据Http请求中所带参数中是否有action，Webx在代码层执行的内容也有所区别。

 

不带action参数请求

webx执行步骤如下：

步骤一、若控制层screen中存在Login.java代码，则执行Login.java代码。

步骤二、执行模板层layout中login.vm（若layout中没有对应名字的布局模板，则会调用默认模板default.vm）。

步骤三、执行模板层screen中的login.vm。

 

带action参数请求

webx执行步骤如下：

步骤一、执行控制层action中LoginController.java代码，指定类必须存在，否则会出现404异常。

步骤二、若控制层screen中存在Login.java代码，则执行Login.java代码。

步骤三、执行模板层layout中login.vm（若layout中没有对应名字的布局模板，则会调用默认模板default.vm）。

步骤四、执行模板层screen中的login.vm。

 

控制层action、screen层编写

Webx规定了action、screen层的默认入口函数为execute，即当类名与路径能够匹配的时候（路径与类名可以以驼峰命名方式，也可以中间以下划线“_”来连接，只有首字母能够忽略大小写），webx会执行类名下execute()方法。示例：

 

工程中常用的方法

控制层action：处理用户操作动作，比如登录、提交数据等。

控制层screen：处理页面展示所需内容。

在老版本的webx中（version小于webx3.0.9）screen层一个Java类只能处理一个页面。而action层可以处理多个不同业务动作。

 

action层代码有所变化，具体示例如下：

（1）提交时必须指明访问的具体方法，且需要有“event_submit_”前缀。

（2）指定具体的action时，需要注意包路径。

 

拦截器

Webx中针对拦截器的配置主要集中在pipeline.xml中。在日常业务开发中免不了要进行登录、权限等验证，而这部分业务作为拦截器再适合不过了。详细配置方式可以查看框架说明书《6.3.3. Pipeline的使用》。