1、简单介绍一下dubbo，dubbo的作用，以及dubbo的原理 。
Dubbo是阿里巴巴公司开源的一个高性能优秀的分布式服务框架。
分析源代码，基本原理如下：
client一个线程调用远程接口，生成一个唯一的ID（比如一段随机字符串，UUID等），Dubbo是使用AtomicLong从0开始累计数字的将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象callback，全部封装在一起，组成一个对象object向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)将ID和打包的方法调用信息封装成一对象connRequest，使用IoSession.write(connRequest)异步发送出去
当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。
服务端接收到请求并处理后，将结果（此结果中包含了前面的ID，即回传）发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到ID，再从前面的ConcurrentHashMap里面get(ID)，从而找到callback，将方法调用结果设置到callback对象里。
监听线程接着使用synchronized获取回调对象callback的锁（因为前面调用过wait()，那个线程已释放callback的锁了），再notifyAll()，唤醒前面处于等待状态的线程继续执行（callback的get()方法继续执行就能拿到调用结果了），至此，整个过程结束。
2、gc回收机制的原理。
用户Java程序运行过程中，Java虚拟机提供了另外一个系统级的线程，专门负责回收不再被使用的对象占用的内存，这一过程称为垃圾回收。垃圾回收需要对堆内存中的对象进行标记，并对堆内存进行整理。这一过程的某些阶段需要暂时终止用户Java线程，等回收工作完成后再恢复执行。因此，频繁地触发虚拟机垃圾回收操作的行为会影响程序的运行效率。那么什么情况下会频繁地出发垃圾回收操作呢？- 比如：堆内存设置过小- 再比如：程序频繁地分配大型局部对象数组
3、过滤器和拦截器区别和项目中如何应用。
过滤器：在目标资源之前进行的操作
过滤所有的内容，比如 action、servlet、jsp、html
拦截器：在目标资源之前进行的操作
不能拦截所有的内容，拦截 action，不能拦截 jsp，不能拦截 html
拦截器和过滤器之间有很多相同之处，但是两者之间存在根本的差别。其主要区别为以下几点：
1）拦截器是基于 JAVA 反射机制的，而过滤器是基于函数回调的。
2）拦截器不依赖于 Servlet 容器，而过滤器依赖于 Servlet 容器
3）拦截器只能对 Action 请求起作用，而过滤器可以对几乎所有的请求起作用。
4）拦截器可以访问 Action 上下文、值栈里的对象，而过滤器不能
5）在 Action 的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调
用一次。
4、scoket的通信的原理 与TCP或UDP的关系。
套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个
TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应
用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
tcp与udp区别：
基于连接与无连接
对系统资源的要求（TCP较多，UDP少）
UDP程序结构较简单
流模式与数据报模式
TCP保证数据正确性，UDP可能丢包
TCP 保证数据顺序，UDP不保证
java编程区别：
tcp是java.net.ServerSocket(用于服务器端)和java.net.Socket(用于客户端);
5、 Nginx实现Tomcat集群的负载均衡有几种方式，你们项目中使用的是那种方式。
一，如果仅是对外提供一个页面访问，不用区分单一用户（不区分每个访问session，不涉及用户权限，用户资料等内容），仅仅配置nginx负载均衡策略即可。
nginx负载均衡策略主要分一下四种：
1)、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器宕机，能自动剔除。
2)、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器。
3)、fair 按后端服务器的响应时间来分配请求，响应时间短的优先分配。
4)、url_hash 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
二，如果涉及到用户session，做一些鉴权缓存、存放临时信息时，就必须做tomcat的session共享。
目前可参考到的session共享方式主要分为两种。
1）利用tomcat自带的组播机制，实现session复制。
对tomcat及应用的若干配置文件进行配置即可实现，网上有很多资料可参考。但这种方式些弊端，看过一些资料，不建议用session复制的方式。在实际使用过程中，也发现有存在session莫名失踪的现象。
2）利用第三方机制存储session。
比较常见的是tomcat集成memcached服务器来存储session。实际项目中，我们采用过利用redis实现session存储，redis高效的存取性能为高效的访问提供了保障，但是目前redis的集群功能似乎没有发布，如何解决redis的单点故障需要研究。
6、 Redis如何实现秒杀业务
1、把商品的数量放到 redis 中。
2、秒杀时使用 decr 命令对商品数量减一。如果不是负数说明抢到。
3、一旦返回数值变为 0 说明商品已售完
7、是否了解工作流？
以请假为例，现在大多数公司的请假流程是这样的
员工打电话（或网聊）向上级提出请假申请——上级口头同意——上级将请假记录下来——月底将请 假记录上交公司——公司将请假录入电脑
采用工作流技术的公司的请假流程是这样的
员工使用账户登录系统——点击请假——上级登录系统点击允许
就这样，一个请假流程就结束了
工作流系统，实现了工作流程的自动化，提高了企业运营效率、改善企业资源利用、提高企业运作的 灵活性和适应性、提高量化考核业务处理的效率、减少浪费
8、使用SVN时发生冲突，如何解决
A、放弃自己的更新，使用svn revert（回滚），然后提交。在这种方式下不需要使用svn resolved（解决）
B、放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行resolved filename并提交(选择文件—右键—解决)。
C、手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行resolved filename来解除冲突，最后提交。
解决冲突：首先应该从版本库更新版本，然后去解决冲突，冲突解决后要执行svn resolved（解决），然后在签入到版本库。在冲突解决之后，需要使用svn resolved（解决）来告诉subversion冲突解决，这样才能提交更新。
