面试内容（最新发布）

（*）支付实现
1）那么多人进行支付，都是用微信或支付宝的第三方支付平台。那么到底怎么区分到底是那个用户的支付接口呢？
用户在申请微信支付接口的时候，将会生成以下签名：
1.appid：微信公众帐号或开放平台app的唯一标识（贵公司恒天财富app申请支付接口的话，会分配一个id唯一标识）
2.mch_id：商户号/支付号/匹配号（配置文件的partner）
3.partnerkey：商户秘钥/支付秘钥
4.sign：数字签名，根据微信官方提供的秘钥和一套算法生成的加密信息，就是为了保证交易的安全性
2）我们呢是用的二维码支付：因为二维码能存更多信息，也能表示更多的数据类型，且容错能力强
3）我们用的二维码生成插件是qrious.js

（1）dubbox
**1）dubbo服务治理中间件：
随着互联网的发展，网站的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，所以有了dubbox 这样的分布式服务框架的需求。
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor（监控器）: 统计服务的调用次数和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时发送一次统计数据到监控中心。
2）dubbox项目架构
①表现层拆分成一个单独的war包
②服务层拆分成一个单独的war包
③web层和service服务层通过dubbox服务治理中间件远程调用
1.rpc 远程调用 hessain2 二进制序列化
2.nio 异步通信 netty
3）Dubbox和Dubbo本质上没有区别，名字的含义扩展了Dubbo而已，以下扩展出来的功能，也是选择Dubbox很重要的考察点。

支持REST风格远程调用（HTTP + JSON/XML)； 支持基于Kryo和FST的Java高效序列化实现； 支持基于Jackson的JSON序列化； 支持基于嵌入式Tomcat的HTTP remoting体系； 升级Spring至3.x； 升级ZooKeeper客户端； 支持完全基于Java代码的Dubbo配置； Dubbox：相对于Dubbo支持了REST，估计是很多公司选择Dubbox的一个重要原因之一，但如果使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖，各有利弊，懂的取舍吧。 4）Dubbo服务治理 特性 描述 透明远程调用 就像调用本地方法一样调用远程方法；只需简单配置，没有任何API侵入； 负载均衡机制 Client端LB，可在内网替代F5等硬件负载均衡器； 容错重试机制 服务Mock数据，重试次数、超时机制等； 自动注册发现 注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者； 性能日志监控 Monitor统计服务的调用次调和调用时间的监控中心； 服务治理中心 路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等手动配置。 自动治理中心 无，比如：熔断限流机制、自动权重调整等； **5） <!-- 指定dubbo发布服务端口 --> <dubbo:protocol port="20881"></dubbo:protocol> <!-- 指定服务名称 --> <dubbo:application/> <!-- 指定服务注册中心地址 --> <dubbo:registry address="zookeeper://192.168.25.128:2181"/> <!-- 注解方式发布服务 --> <dubbo:annotation package="com.pyg.manager.service.impl" /> 6）默认使用Dubbo协议 连接个数：单连接 连接方式：长连接 传输协议：TCP 传输方式：NIO异步传输 序列化：Hessian二进制序列化 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要使用dubbo协议传输大文件或超大字符串 使用场景：常规远程服务方法调用 从上面的适用范围总结，dubbo适合小数据量大并发的服务调用，以及消费者机器远大于生产者机器数的情况，不适合传输大数据量的服务比如文件、视频等，除非请求量很低。

（2）谈一谈对集合的理解？
实现Collection接口的集合是单列集合，常用的有：set(集)、list(列表)。
*list：list中有ArrayList，LinkedList，Vector。ArrayList，Vector底层都是基于array数组的，不同的是ArrayList是不同步的，线程不安全。Vector是同步的，加synchronized锁，是线程安全的。所以在性能上ArrayList优于Vector。LinkedList不同于前面两种List，不是基于array的，它是基于Node节点的，当LinkedList增删数据时，不需要像基于Array的List一样，必须进行大量的数据移动，只需要更改nextNode就行了，这也是LinkedList的优势。
*set：
HashSet：虽然Set同List都实现了Collection接口，但是他们的实现方式却大不一样。List基本上都是以Array为基础。但是Set则是 在HashMap的基础上来实现的，这个就是Set和List的根本区别。HashSet的存储方式是把HashMap中的Key作为Set的对应存储项。看看 HashSet的add(Object obj)方法的实现就可以一目了然了。
public boolean add(Object obj){
return map.put(obj, PRESENT) == null;
}
这个也是为什么在Set中不能像在List中一样有重复的项的根本原因，因为HashMap的key是不能有重复的。

LinkedHashSet:HashSet的一个子类，一个链表。 TreeSet:SortedSet的子类，它不同于HashSet的根本就是TreeSet是有序的。它是通过SortedMap来实现的。(HashSet和TreeSet均为有序的顺序由小到大) 实现Map接口的Map是双列集合，常用的有：HashMap、LinkedHashMap，TreeMap不常用。HashMap初始容量16，默认加载因子0.75 加载因子越大,填满的元素越多,好处是,空间利用率高了,但:冲突的机会加大了.链表长度会越来越长,查找效率降低。 反之,加载因子越小,填满的元素越少,好处是:冲突的机会减小了,但:空间浪费多了.表中的数据将过于稀疏（很多空间还没用，就开始扩容了） 冲突的机会越大,则查找的成本越高. 因此,必须在 "冲突的机会"与"空间利用率"之间寻找一种平衡与折衷. 这种平衡与折衷本质上是数据结构中有名的"时-空"矛盾的平衡与折衷. 　　 如果机器内存足够，并且想要提高查询速度的话可以将加载因子设置小一点；相反如果机器内存紧张，并且对查询速度没有什么要求的话可以将加载因子设置大一点。不过一般我们都不用去设置它，让它取默认值0.75就好了。 1.集合的安全性问题 1）ArrayList、HashSet、HashMap都不是线程安全。在集合中Vector（Vector是基于Array的List）和HashTable倒是线程安全的。你打开源码会发现其实就是把各自核心方法添加上了synchronized 关键字。