java相关技术问答（二）

String为何是final的

1. 首先是为了安全性，final表示不可变，不可被继承，不能修改其方法保证安全
2. 在多线程环境下，final类型的String保证线程安全
3. String支持字符串常量池，相同字符串能够指向相同地址

cas原理讲下

1. cas算法包含三个参数，v须要更新的变量，e预期值，n新的值
2. 进入cas算法时，会先记录更新变量值，而后进入compareAndSwap方法，判断v是否等于e，相等说明v值没有被改变，那v值更新成n值

线程池线程数配置多少合适？

1. 须要根据所执行的任务类别来区分
2. 分为cpu密集型和IO密集型
3. cpu密集型线程数和cpu数量相同
4. io密集型，表示任务中须要执行像数据库操做，磁盘操做这类io阻塞等待的操做
5. 这个时候，有公式来算出最佳执行线程=（线程io阻塞时间/io运行时间+1）*cpu数

为何redis单线程还这么快

1. redis虽然是单线程，但他的操做彻底是在内存进行的，内存的速度比IO快不少，能够有效提升cpu的利用率

ThreadPoolExecutor中有哪些参数

1. 核心线程数
2. 最大线程数
3. 最大空闲时间
4. 单位
5. 阻塞队列
6. 超出队列任务处理

jdk7和jdk8特性

1. jdk7可使用switch字符串了
2. jdk7 try-catch资源块，能够自动释放
3. jdk8 lambda表达式 函数式编程
4. jdk8 接口能够实现默认方法了

防盗链方法

1. 判断请求头refered，不是本身的域名，重定向到别的页面
2. 使用nginx，nginx能够设置哪些域名能够访问哪些资源，其余域名访问都会跳到错误页面

跨域问题解决方案

1. 首先经常使用方法，添加请求头head，能够设置哪些域名容许跨域
2. jsonp，前端技术，只支持get求情
3. 使用网关，像nginx
4. 使用httpClient转一道，rpc调用

java中的队列经常使用哪些

1. ArrayBlockingQueue
2. LinkedBlockingQueue
3. DelayQueue
4. PriorityBlockingQueue

Class.forName和classloader的区别

1. Class.forName 只会加载类信息，不会执行类中的static块
2. classloader除了加载类，还会执行static块

让你优化系统，你会作哪些

1. 首选若是条件容许，tomcat集群部署，使用nginx作负载均衡和反向代理，分担压力
2. 这可能会带来问题，好比该tomcat应用不支持集群部署，里面存在定时任务，不容许重复执行，还有session共享问题等等。
3. 因此在集群前先解决上述问题，使用单独的分布式任务调度系统管理全部定时任务，系统代码该优化的优化，接口须要保证幂等性
4. 随着集群化，并发量qps确定能上来。接下来能够并发执行的优化还有数据库方面
5. 开启慢查询，对用时比较长的语句进行explain，对该加索引的地方加上索引，能优化的地方优化。字段能用not null的地方用not null 由于is null的判断可能引发索引失效
6. group by默认会进行排序，若不须要使用order by null禁用排序
7. 还有后端缓存也是一大块，使用好缓存能够减小大量数据库io操做，能够增大qps，可使用redis做为缓存，
8. 前端动静分离，cdn加速
9. 固然若是能有服务器操做权限，也能够适当的进行JVM调优

Redis和Memcached总体对比

1. redis在单核的性能上高于mecached，memcached能够多核处理
2. redis在单纯key-value存储上，memcached利用率更高，但redis使用hash结构的key-value则利用率比mecached高
3. redis支持更丰富的数据操做，list，set，zset，string，hash
4. redis可持久化数据

强引用，软引用，弱引用，虚引用

1. 强引用 最广泛引用，对象引用存在永远不会被垃圾收集器回收
2. 软引用和内存相关，软引用对象内存不足时清除
3. 弱引用，短期可取到对象，二次垃圾回收时清除
4. 虚引用，假的引用，没有实际引用对象。多用于检测对象是否从内存中移除

hashMap在jdk1.7和1.8的区别

1. 1.8在链表的基础上加入了红黑树，当链表长度超过8，链表结构将变成红黑树模式，下降时间复杂度
2. 但要使用这个优点，key必须时间比较接口compare

死锁，活锁和饥饿

1. 死锁，两个以上线程竞争资源致使都得不到资源
2. 活锁，两个线程互相谦让资源致使都得不到资源
3. 饥饿，一条线程一直等着另外一条线程一直持有资源

redis中穿透与雪崩的预防及解决

1. 穿透，同一个不存在数据的请求屡次发起，因为缓存找不到数据，每次会请求数据库，致使缓存穿透
   • 能够经过缓存不存在的值，存入null值，访问到时返回null值处理方法
2. 雪崩，大量缓存在同一时间失效，请求都访问数据库
   • 并发压力经过加锁或队列，当缓存失效时，对某个key只容许一条线程访问，其余等待
   • 缓存失效时间设置不一样，尽可能均匀分布
   • 加二级缓存，二级缓存失效时间大于一级缓存能够作到一级缓存失效，二级缓存能够起到做用
   • 若是能知道某个时间点会存在大量并发，能够设计手动reload，从新加载缓存

ES和solr对比

1. ES自带分布式不须要其余依赖组件，solr须要依赖如zookeeper
2. ES接近实时搜索，效率比solr高
3. ES节点故障自动分配其余节点
4. 对已有数据进行搜索时，solr更快；实时创建索引，ES更快

给定a、b两个文件，各存放50亿个url，每一个url各占64字节，内存限制是4G，让你找出a、b文件共同的url？

1. 方案一
   1. 50亿64字节大概在320G，明细所有加载内存不够
   2. 首先的想法确定是分批对比，如何分，先a文件经过对每一个url hash（url）%1000 获得的数表明文件编号，每一个文件大概300M
   3. 再b文件一样的方式分割出相同数量1000个文件，则相同url所在的文件序号必定是相同的
   4. 由此能够继续对比每一对小文件，先将a1文件存入hashmap，再遍历b1文件，在a1存在则是共同的url
2. 方案二 若容许有必定偏差，可使用bloomfilter
   1. bloom filter 的4G内存能够存储340亿bit
   2. 它的原理就是对存入值进行k散列，而后将数组中对应散列值置1
   3. 判断值是否存在的方法就是散列后对应值都为1，有一个为0就是不存在。所有为1则是很大可能存在