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 ...

阅读全文 »

日前, 我提到 Python 程序员要比使用 Java 工作的程序员更聪明。大家也许会有点疑惑吧。 我并没有 "Java 程序员何其盲目" 的意思, 我只想说 Python 程序员是很聪明的。学习一种新的编程语言都是需要花点工夫的 ──── 而 Python 并不能用来找工作。人们学习 Python 只是因为他们率真地喜欢编程, 而目前所有已知的编程语言都不能使他们满足。 这使得这种程序员成为软件公司心目中最为理想的雇员。介于此, 目前还没有一个更好的词, 我姑且叫它 Python 悖论吧: 如果公司选用一种颇为曼妙的编程语言, 他能雇到好的程序员, 因为好的编程语言总是能够吸引到优秀的程序员。然后悖论就来了: 这种语言会很快流行, 会有许多工作机会, 然后这种语言 (比如 Java) 就堕落成程序员的敲门砖了。 只有少数公司能够清醒地认识到这一点。但是还有另一种可能, 就是公司里的程序员都非常热爱他们的编程工作于是一拍即合, 从而逃离这个悖论的影响。Google, 比如说。当他们刊登招聘 Java 程序员的广告时, 同时也要求有 Python 的编程经历。 我有一个几乎懂得所有编程语言的朋友, 几乎所有的项目他都在使用 Python。据他自己说主要是因为, "他喜欢 Python 源代码在视觉感官上的体验"。对于语言的选择, 这是一个看似非常轻佻的理由。但它实际上并没有听上去那么卤莽: 当你编程时, 比起书写代码你得花更多的时间去阅读它们。如同雕塑家将泥一块一块地涂到艺术品上, 你的代码被一行一行地添加上去。因此, 如果一种语言写出的代码不那么漂亮, 它会让严谨的程序员抓狂, 恰如一位雕塑家看到一个充满瑕疵的作品一样。 既然提到了丑陋的代码, 许多人理所当然地会想到 Perl。但是 Perl 代码的丑陋只是表象, 并不是我所说的那种丑陋的类型。真正的丑陋不是肤浅地从字面代码上来评判, 而是你被迫基于一种错误的观念来架构你的程序。也许看上去 Perl 像是 "$%^ $#@! ...", 但是有许多案例证明他其实拥有比 Python 更先进的理念。 迄今为止, 不管怎么说。这两种语言尽管设计的目标不同, 但是它们, 包括 Ruby (以及 Icon, Joy, J, Lisp, 和 Smalltalk) 都是为那些真正关心程序的人创建, 并给他们使用的。这是事实。这些程序员总会试图去做得更好。 The Python Paradox August 2004 (原文地址: http://www.paulgraham.com/pypar.html) In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project. I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know. Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job. Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience. A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor. At the mention of ugly source code, people will of course th ...

阅读全文 »