招聘 Java 技术栈

laofo · 2017年05月08日 · 2 次阅读

java 技术栈 参考了众多资料,这里就不再详细列举了,可以自行去搜索

1 java 基础: 1.1 算法 1.1 排序算法:直接插入排序、希尔排序、冒泡排序、快速排序、直接选择排序、堆排序、归并排序、基数排序 1.2 二叉查找树、红黑树、B 树、B+ 树、LSM 树(分别有对应的应用,数据库、HBase) 1.3 BitSet 解决数据重复和是否存在等问题 1.2 基本 2.1 字符串常量池的迁移 2.2 字符串 KMP 算法 2.3 equals 和 hashcode 2.4 泛型、异常、反射 2.5 string 的 hash 算法 2.6 hash 冲突的解决办法:拉链法 2.7 foreach 循环的原理 2.8 static、final、transient 等关键字的作用 2.9 volatile 关键字的底层实现原理 2.10 Collections.sort 方法使用的是哪种排序方法 2.11 Future 接口,常见的线程池中的 FutureTask 实现等 2.12 string 的 intern 方法的内部细节,jdk1.6 和 jdk1.7 的变化以及内部 cpp 代码 StringTable 的实现 1.3 设计模式 单例模式 工厂模式 装饰者模式 观察者设计模式 ThreadLocal 设计模式 。。。 1.4 正则表达式 4.1 捕获组和非捕获组 4.2 贪婪,勉强,独占模式 1.5 java 内存模型以及垃圾回收算法 5.1 类加载机制,也就是双亲委派模型

5.2 java 内存分配模型(默认 HotSpot)

线程共享的:堆区、永久区 线程独享的:虚拟机栈、本地方法栈、程序计数器

5.3 内存分配机制:年轻代(Eden 区、两个 Survivor 区)、年老代、永久代以及他们的分配过程

5.4 强引用、软引用、弱引用、虚引用与 GC

5.5 happens-before 规则

5.6 指令重排序、内存栅栏

5.7 Java 8 的内存分代改进

5.8 垃圾回收算法:

标记 - 清除(不足之处:效率不高、内存碎片)

复制算法(解决了上述问题,但是内存只能使用一半,针对大部分对象存活时间短的场景,引出了一个默认的 8:1:1 的改进,缺点是仍然需要借助外界来解决可能承载不下的问题)

标记整理

5.8 常用垃圾收集器:

新生代:Serial 收集器、ParNew 收集器、Parallel Scavenge 收集器

老年代:Serial Old 收集器、Parallel Old 收集器、CMS(Concurrent Mark Sweep)收集器、 G1 收集器(跨新生代和老年代)

5.9 常用 gc 的参数:-Xmn、-Xms、-Xmx、-XX:MaxPermSize、-XX:SurvivorRatio、-XX:-PrintGCDetails

5.10 常用工具: jps、jstat、jmap、jstack、图形工具 jConsole、Visual VM、MAT

1.6 锁以及并发容器的源码 6.1 synchronized 和 volatile 理解 6.2 Unsafe 类的原理,使用它来实现 CAS。因此诞生了 AtomicInteger 系列等 6.3 CAS 可能产生的 ABA 问题的解决,如加入修改次数、版本号 6.4 同步器 AQS 的实现原理 6.5 独占锁、共享锁;可重入的独占锁 ReentrantLock、共享锁 实现原理 6.6 公平锁和非公平锁 6.7 读写锁 ReentrantReadWriteLock 的实现原理 6.8 LockSupport 工具 6.9 Condition 接口及其实现原理 6.10 HashMap、HashSet、ArrayList、LinkedList、HashTable、ConcurrentHashMap、TreeMap 的实现原理 6.11 HashMap 的并发问题 6.12 ConcurrentLinkedQueue 的实现原理 6.13 Fork/Join 框架 6.14 CountDownLatch 和 CyclicBarrier 1.7 线程池源码 7.1 内部执行原理 7.2 各种线程池的区别 2 web 方面: 2.1 SpringMVC 的架构设计 1.1 servlet 开发存在的问题:映射问题、参数获取问题、格式化转换问题、返回值处理问题、视图渲染问题 1.2 SpringMVC 为解决上述问题开发的几大组件及接口:HandlerMapping、HandlerAdapter、HandlerMethodArgumentResolver、HttpMessageConverter、Converter、GenericConverter、HandlerMethodReturnValueHandler、ViewResolver、MultipartResolver 1.3 DispatcherServlet、容器、组件三者之间的关系 1.4 叙述 SpringMVC 对请求的整体处理流程 1.5 SpringBoot 2.2 SpringAOP 源码 2.1 AOP 的实现分类:编译期、字节码加载前、字节码加载后三种时机来实现 AOP

2.2 深刻理解其中的角色:AOP 联盟、aspectj、jboss AOP、Spring 自身实现的 AOP、Spring 嵌入 aspectj。特别是能用代码区分后两者

2.3 接口设计:

AOP 联盟定义的概念或接口:Pointcut(概念,没有定义对应的接口)、Joinpoint、Advice、MethodInterceptor、MethodInvocation

SpringAOP 针对上述 Advice 接口定义的接口及其实现类:BeforeAdvice、AfterAdvice、MethodBeforeAdvice、AfterReturningAdvice;针对 aspectj 对上述接口的实现 AspectJMethodBeforeAdvice、AspectJAfterReturningAdvice、AspectJAfterThrowingAdvice、AspectJAfterAdvice。

SpringAOP 定义的定义的 AdvisorAdapter 接口:将上述 Advise 转化为 MethodInterceptor

SpringAOP 定义的 Pointcut 接口:含有两个属性 ClassFilter(过滤类)、MethodMatcher(过滤方法)

SpringAOP 定义的 ExpressionPointcut 接口:实现中会引入 aspectj 的 pointcut 表达式

SpringAOP 定义的 PointcutAdvisor 接口(将上述 Advice 接口和 Pointcut 接口结合起来)

2.4 SpringAOP 的调用流程

2.5 SpringAOP 自己的实现方式(代表人物 ProxyFactoryBean)和借助 aspectj 实现方式区分

2.3 Spring 事务体系源码以及分布式事务 Jotm Atomikos 源码实现 3.1 jdbc 事务存在的问题 3.2 Hibernate 对事务的改进 3.3 针对各种各样的事务,Spring 如何定义事务体系的接口,以及如何融合 jdbc 事务和 Hibernate 事务的 3.4 三种事务模型包含的角色以及各自的职责 3.5 事务代码也业务代码分离的实现(AOP+ThreadLocal 来实现) 3.6 Spring 事务拦截器 TransactionInterceptor 全景 3.7 X/Open DTP 模型,两阶段提交,JTA 接口定义 3.8 Jotm、Atomikos 的实现原理 3.9 事务的传播属性 3.10 PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED 的实现原理以及区别 3.11 事物的挂起和恢复的原理 2.4 数据库隔离级别 4.1 Read uncommitted:读未提交 4.2 Read committed : 读已提交 4.3 Repeatable read:可重复读 4.4 Serializable :串行化 2.5 数据库 5.1 数据库性能的优化

5.2 深入理解 mysql 的 Record Locks、Gap Locks、Next-Key Locks

例如下面的在什么情况下会出现死锁:

start transaction; DELETE FROM t WHERE id =6; INSERT INTO t VALUES(6); commit;

5.3 insert into select 语句的加锁情况

5.4 事务的 ACID 特性概念

5.5 innodb 的 MVCC 理解

5.6 undo redo binlog

1 undo redo 都可以实现持久化,他们的流程是什么?为什么选用 redo 来做持久化? 2 undo、redo 结合起来实现原子性和持久化,为什么 undo log 要先于 redo log 持久化? 3 undo 为什么要依赖 redo? 4 日志内容可以是物理日志,也可以是逻辑日志?他们各自的优点和缺点是? 5 redo log 最终采用的是物理日志加逻辑日志,物理到 page,page 内逻辑。还存在什么问题?怎么解决?Double Write 6 undo log 为什么不采用物理日志而采用逻辑日志? 7 为什么要引入 Checkpoint? 8 引入 Checkpoint 后为了保证一致性需要阻塞用户操作一段时间,怎么解决这个问题?(这个问题还是很有普遍性的,redis、ZooKeeper 都有类似的情况以及不同的应对策略)又有了同步 Checkpoint 和异步 Checkpoint 9 开启 binlog 的情况下,事务内部 2PC 的一般过程(含有 2 次持久化,redo log 和 binlog 的持久化) 10 解释上述过程,为什么 binlog 的持久化要在 redo log 之后,在存储引擎 commit 之前? 11 为什么要保持事务之间写入 binlog 和执行存储引擎 commit 操作的顺序性?(即先写入 binlog 日志的事务一定先 commit) 12 为了保证上述顺序性,之前的办法是加锁 prepare_commit_mutex,但是这极大的降低了事务的效率,怎么来实现 binlog 的 group commit? 13 怎么将 redo log 的持久化也实现 group commit?至此事务内部 2PC 的过程,2 次持久化的操作都可以 group commit 了,极大提高了效率 2.6 ORM 框架: mybatis、Hibernate 6.1 最原始的 jdbc->Spring 的 JdbcTemplate->hibernate->JPA->SpringDataJPA 的演进之路 2.7 SpringSecurity、shiro、SSO(单点登录) 7.1 Session 和 Cookie 的区别和联系以及 Session 的实现原理 7.2 SpringSecurity 的认证过程以及与 Session 的关系 7.3 CAS 实现 SSO(详见 Cas(01)——简介) 输入图片说明

2.8 日志 8.1 jdk 自带的 logging、log4j、log4j2、logback 8.2 门面 commons-logging、slf4j 8.3 上述 6 种混战时的日志转换 2.9 datasource 9.1 c3p0 9.2 druid 9.3 JdbcTemplate 执行 sql 语句的过程中对 Connection 的使用和管理 2.10 HTTPS 的实现原理 3 分布式、java 中间件、web 服务器等方面: 3.1 ZooKeeper 源码 1.1 客户端架构 1.2 服务器端单机版和集群版,对应的请求处理器 1.3 集群版 session 的建立和激活过程 1.4 Leader 选举过程 1.5 事务日志和快照文件的详细解析 1.6 实现分布式锁、分布式 ID 分发器 1.7 实现 Leader 选举 1.8 ZAB 协议实现一致性原理 3.2 序列化和反序列化框架 2.1 Avro 研究 2.2 Thrift 研究 2.3 Protobuf 研究 2.4 Protostuff 研究 2.5 Hessian 3.3 RPC 框架 dubbo 源码 3.1 dubbo 扩展机制的实现,对比 SPI 机制 3.2 服务的发布过程 3.3 服务的订阅过程 3.4 RPC 通信的设计 3.4 NIO 模块以及对应的 Netty 和 Mina、thrift 源码 4.1 TCP 握手和断开及有限状态机 4.2 backlog 4.3 BIO NIO 4.4 阻塞/非阻塞的区别、同步/异步的区别 4.5 阻塞 IO、非阻塞 IO、多路复用 IO、异步 IO 4.6 Reactor 线程模型 4.7 jdk 的 poll、epoll 与底层 poll、epoll 的对接实现 4.8 Netty 自己的 epoll 实现 4.9 内核层 poll、epoll 的大致实现 4.10 epoll 的边缘触发和水平触发 4.11 Netty 的 EventLoopGroup 设计 4.12 Netty 的 ByteBuf 设计 4.13 Netty 的 ChannelHandler 4.13 Netty 的零拷贝 4.14 Netty 的线程模型,特别是与业务线程以及资源释放方面的理解 3.5 消息队列 kafka、RocketMQ、Notify、Hermes 5.1 kafka 的文件存储设计 5.2 kafka 的副本复制过程 5.3 kafka 副本的 leader 选举过程 5.4 kafka 的消息丢失问题 5.5 kafka 的消息顺序性问题 5.6 kafka 的 isr 设计和过半对比 5.7 kafka 本身做的很轻量级来保持高效,很多高级特性没有:事务、优先级的消息、消息的过滤,更重要的是服务治理不健全,一旦出问题,不能直观反应出来,不太适合对数据要求十分严苛的企业级系统,而适合日志之类并发量大但是允许少量的丢失或重复等场景 5.8 Notify、RocketMQ 的事务设计 5.9 基于文件的 kafka、RocketMQ 和基于数据库的 Notify 和 Hermes 5.10 设计一个消息系统要考虑哪些方面 5.11 丢失消息、消息重复、高可用等话题 3.6 数据库的分库分表 mycat 3.7 NoSql 数据库 mongodb 3.8 KV 键值系统 memcached redis 8.1 redis 对客户端的维护和管理,读写缓冲区 8.2 redis 事务的实现 8.3 Jedis 客户端的实现 8.4 JedisPool 以及 ShardedJedisPool 的实现 8.5 redis epoll 实现,循环中的文件事件和时间事件 8.6 redis 的 RDB 持久化,save 和 bgsave 8.7 redis AOF 命令追加、文件写入、文件同步到磁盘 8.8 redis AOF 重写,为了减少阻塞时间采取的措施 8.9 redis 的 LRU 内存回收算法 8.10 redis 的 master slave 复制 8.11 redis 的 sentinel 高可用方案 8.12 redis 的 cluster 分片方案 3.9 web 服务器 tomcat、ngnix 的设计原理 9.1 tomcat 的整体架构设计 9.2 tomcat 对通信的并发控制 9.3 http 请求到达 tomcat 的整个处理流程 3.10 ELK 日志实时处理查询系统 10.1 Elasticsearch、Logstash、Kibana 3.11 服务方面 11.1 SOA 与微服务 11.2 服务的合并部署、多版本自动快速切换和回滚 详见基于 Java 容器的多应用部署技术实践

11.3 服务的治理:限流、降级 具体见 张开涛大神的架构系列

服务限流:令牌桶、漏桶

服务降级、服务的熔断、服务的隔离:netflix 的 hystrix 组件

11.4 服务的线性扩展

无状态的服务如何做线性扩展:

如一般的 web 应用,直接使用硬件或者软件做负载均衡,简单的轮训机制

有状态服务如何做线性扩展:

如 Redis 的扩展:一致性 hash,迁移工具

11.5 服务链路监控和报警:CAT、Dapper、Pinpoint

3.12 Spring Cloud 12.1 Spring Cloud Zookeeper:用于服务注册和发现 12.2 Spring Cloud Config:分布式配置 12.2 Spring Cloud Netflix Eureka:用于 rest 服务的注册和发现 12.3 Spring Cloud Netflix Hystrix:服务的隔离、熔断和降级 12.4 Spring Cloud Netflix Zuul:动态路由,API Gateway 3.13 分布式事务 13.1 JTA 分布式事务接口定义,对此与 Spring 事务体系的整合 13.2 TCC 分布式事务概念 13.3 TCC 分布式事务实现框架案例 1:tcc-transaction 13.3.1 TccCompensableAspect 切面拦截创建 ROOT 事务 13.3.2 TccTransactionContextAspect 切面使远程 RPC 调用资源加入到上述事务中,作为一个参与者 13.3.3 TccCompensableAspect 切面根据远程 RPC 传递的 TransactionContext 的标记创建出分支事务 13.3.4 全部 RPC 调用完毕,ROOT 事务开始提交或者回滚,执行所有参与者的提交或回滚 13.3.5 所有参与者的提交或者回滚,还是通过远程 RPC 调用,provider 端开始执行对应分支事务的 confirm 或者 cancel 方法 13.3.6 事务的存储,集群共享问题 13.3.7 事务的恢复,避免集群重复恢复 13.4 TCC 分布式事务实现框架案例 2:ByteTCC 13.4.1 JTA 事务管理实现,类比 Jotm、Atomikos 等 JTA 实现 13.4.2 事务的存储和恢复,集群是否共享问题调用方创建 CompensableTransaction 事务,并加入资源 13.4.3 CompensableMethodInterceptor 拦截器向 spring 事务注入 CompensableInvocation 资源 13.4.4 Spring 的分布式事务管理器创建作为协调者 CompensableTransaction 类型事务,和当前线程进行绑定,同时创建一个 jta 事务 13.4.5 在执行 sql 等操作的时候,所使用的 jdbc 等 XAResource 资源加入上述 jta 事务 13.4.6 dubbo RPC 远程调用前,CompensableDubboServiceFilter 创建出一个代理 XAResource,加入上述 CompensableTransaction 类型事务,并在 RPC 调用过程传递 TransactionContext 参与方创建分支的 CompensableTransaction 事务,并加入资源,然后提交 jta 事务 13.4.7 RPC 远程调用来到 provider 端,CompensableDubboServiceFilter 根据传递过来的 TransactionContext 创建出对应的 CompensableTransaction 类型事务 13.4.8 provider 端,执行时遇见@Transactional@Compensable,作为一个参与者开启 try 阶段的事务,即创建了一个 jta 事务 13.4.9 provider 端 try 执行完毕开始准备 try 的提交,仅仅是提交上述 jta 事务,返回结果到 RPC 调用端调用方决定回滚还是提交 13.4.10 全部执行完毕后开始事务的提交或者回滚,如果是提交则先对 jta 事务进行提交(包含 jdbc 等 XAResource 资源的提交),提交成功后再对 CompensableTransaction 类型事务进行提交,如果 jta 事务提交失败,则需要回滚 CompensableTransaction 类型事务。 13.4.11 CompensableTransaction 类型事务的提交就是对 CompensableInvocation 资源和 RPC 资源的提交,分别调用每一个 CompensableInvocation 资源的 confirm,以及每一个 RPC 资源的提交 CompensableInvocation 资源的提交 13.4.12 此时每一个 CompensableInvocation 资源的 confirm 又会准备开启一个新的事务,当前线程的 CompensableTransaction 类型事务已存在,所以这里开启事务仅仅是创建了一个新的 jta 事务而已 13.4.13 针对此,每一个 CompensableInvocation 资源的 confirm 开启的事务,又开始重复上述过程,对于 jdbc 等资源都加入新创建的 jta 事务中,而 RPC 资源和 CompensableInvocation 资源仍然加入到当前线程绑定的 CompensableTransaction 类型事务 13.4.14 当前 CompensableInvocation 资源的 confirm 开启的事务执行完毕后,开始执行 commit,此时仍然是执行 jta 事务的提交,提交完毕,一个 CompensableInvocation 资源的 confirm 完成,继续执行下一个 CompensableInvocation 资源的 confirm,即又要重新开启一个新的 jta 事务 RPC 资源的提交(参与方 CompensableTransaction 事务的提交) 13.4.15 当所有 CompensableInvocation 资源的 confirm 执行完毕,开始执行 RPC 资源的 commit,会进行远程调用,执行远程 provider 分支事务的提交,远程调用过程会传递事务 id 13.4.16 provider 端,根据传递过来的事务 id 找到对应的 CompensableTransaction 事务,开始执行提交操作,提交操作完成后返回响应结束 13.4.17 协调者收到响应后继续执行下一个 RPC 资源的提交,当所有 RPC 资源也完成相应的提交,则协调者算是彻底完成该事务 3.14 一致性算法 14.1 raft(详见 Raft 算法赏析)

14.1.1 leader 选举过程,leader 选举约束,要包含所有 commited entries,实现上 log 比过半的 log 都最新即可 14.1.2 log 复制过程,leader 给所有的 follower 发送 AppendEntries RPC 请求,过半 follower 回复 ok,则可提交该 entry,然后向客户端响应 OK 14.1.3 在上述 leader 收到过半复制之后,挂了,则后续 leader 不能直接对这些之前 term 的过半 entry 进行提交(这一部分有详细的案例来证明,并能说出根本原因),目前做法是在当前 term 中创建空的 entry,然后如果这些新创建的 entry 被大部分复制了,则此时就可以对之前 term 的过半 entry 进行提交了 14.1.4 leader 一旦认为某个 term 可以提交了,则更新自己的 commitIndex,同时应用 entry 到状态机中,然后在下一次与 follower 的 heartbeat 通信中,将 leader 的 commitIndex 带给 follower,让他们进行更新,同时应用 entry 到他们的状态机中 14.1.5 从上述流程可以看到,作为 client 来说,可能会出现这样的情况:leader 认为某次 client 的请求可以提交了(对应的 entry 已经被过半复制了),此时 leader 挂了,还没来得及给 client 回复,也就是说对 client 来说,请求虽然失败了,但是请求对应的 entry 却被持久化保存了,但是有的时候却是请求失败了(过半都没复制成功)没有持久化成功,也就是说请求失败了,服务器端可能成功了也可能失败了。所以这时候需要在 client 端下功夫,即 cleint 端重试的时候仍然使用之前的请求数据进行重试,而不是采用新的数据进行重试,服务器端也必须要实现幂等。 14.1.6 Cluster membership changes 14.2 ZooKeeper 使用的 ZAB 协议(详见 ZooKeeper 的一致性算法赏析)

14.2.1 leader 选举过程。要点:对于不同状态下的 server 的投票的收集,投票是需要选举出一个包含所有日志的 server 来作为 leader 14.2.2 leader 和 follower 数据同步过程,全量同步、差异同步、日志之间的纠正和截断,来保证和 leader 之间的一致性。以及 follower 加入已经完成选举的系统,此时的同步的要点:阻塞 leader 处理写请求,完成日志之间的差异同步,还要处理现有进行中的请求的同步,完成同步后,解除阻塞。 14.2.3 广播阶段,即正常处理客户端的请求,过半响应即可回复客户端。 14.2.4 日志的恢复和持久化。持久化:每隔一定数量的事务日志持久化一次,leader 选举前持久化一次。恢复:简单的认为已写入日志的的事务请求都算作已提交的请求(不管之前是否已过半复制),全部执行 commit 提交。具体的恢复是:先恢复快照日志,然后再应用相应的事务日志 14.3 paxos(详见 paxos 算法证明过程)

14.3.1 paxos 的运作过程:

Phase 1: (a) 一个 proposer 选择一个编号为 n 的议案,向所有的 acceptor 发送 prepare 请求

Phase 1: (b) 如果 acceptor 已经响应的 prepare 请求中议案编号都比 n 小,则它承诺不再响应 prepare 请求或者 accept 请求中议案编号小于 n 的, 并且找出已经 accept 的最大议案的 value 返回给该 proposer。如果已响应的编号比 n 大,则直接忽略该 prepare 请求。

Phase 2:(a) 如果 proposer 收到了过半的 acceptors 响应,那么将提出一个议案(n,v),v 就是上述所有 acceptor 响应中最大 accept 议案的 value,或者是 proposer 自己的 value。然后将该议案发送给所有的 acceptor。这个请求叫做 accept 请求,这一步才是所谓发送议案请求,而前面的 prepare 请求更多的是一个构建出最终议案 (n,v) 的过程。

Phase 2:(b) acceptor 接收到编号为 n 的议案,如果 acceptor 还没有对大于 n 的议案的 prepare 请求响应过,则 acceptor 就 accept 该议案,否则拒绝

14.3.2 paxos 的证明过程:

1 足够多的问题

2 acceptor 的初始 accept

3 P2-对结果要求

4 P2a-对 acceptor 的 accept 要求

5 P2b-对 proposer 提出议案的要求(结果上要求)

6 P2c-对 proposer 提出议案的要求(做法上要求)

7 引出 prepare 过程和 P1a

8 8 优化 prepare

14.3.3 base paxos 和 multi-paxos

4 大数据方向 4.1 Hadoop 1.1 UserGroupInformation 源码解读:JAAS 认证、user 和 group 关系的维护 1.2 RPC 通信的实现 1.3 代理用户的过程 1.4 kerberos 认证 4.2 MapReduce 2.1 MapReduce 理论及其对应的接口定义 4.3 HDFS 3.1 MapFile、SequenceFile 3.2 ACL 4.4 YARN、Mesos 资源调度 4.5 oozie 5.1 oozie XCommand 设计 5.2 DagEngine 的实现原理 4.6 Hive 6.1 HiveServer2、metatore 的 thrift RPC 通信设计 6.2 Hive 的优化过程 6.3 HiveServer2 的认证和授权 6.4 metastore 的认证和授权 6.5 HiveServer2 向 metatore 的用户传递过程 4.7 Hbase 7.1 Hbase 的整体架构图 7.2 Hbase 的 WAL 和 MVCC 设计 7.3 client 端的异步批量 flush 寻找 RegionServer 的过程 7.4 Zookeeper 上 HBase 节点解释 7.5 Hbase 中的 mini、major 合并 7.6 Region 的高可用问题对比 kafka 分区的高可用实现 7.7 RegionServer RPC 调用的隔离问题 7.8 数据从内存刷写到 HDFS 的粒度问题 7.9 rowKey 的设计 7.10 MemStore 与 LSM

暂无回复。
需要 登录 后方可回复。