《程序员读》

《程序员读》

——精心为程序员打造的编程开发阅读软件。
挖掘细致的阅读习惯,
热门开发分类,
每日内容更新,
在线视频观看,
下载离线阅读,
片段选择分享,
网络收藏摘抄,
开发文章发表,
附近猿媛查看,
兴趣好友联系,
二维码快速扫描,
日夜间模式摇一摇轻松切换。


iPhone版 v1.82

扫一扫 http://t.cn/8k1VM8d
《程序员读》精心为程序员打造,隆重登陆AppStore


Android版 v1.4

扫一扫 http://t.cn/R74JjLj
《程序员读》精心为程序员打造


1136a1136d1136e1136c1136b

..

JVM

JVM

JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

Java语言的一个非常重要的特点就是与平台的无关性,使用Java虚拟机是实现这一特点的关键。一般的高级语言如果要在不同的平台上运行,至少需要编译成不同的目标代码,Java语言使用Java虚拟机屏蔽了与具体平台相关的信息,使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码(字节码),就可以在多种平台上不加修改地运行。Java虚拟机在执行字节码时,把字节码解释成具体平台上的机器指令执行。这就是Java的能够“一次编译,到处运行”的原因。

http://www.mamicode.com/info-detail-1028149.html

HotSpot VM

HotSpot VM是绝对的主流的JVM。大家用它的时候很可能就没想过还有别的选择,或者是为了迁就依赖了Oracle/Sun JDK某些具体实现的烂代码而选择用HotSpot VM省点心。Oracle / Sun JDK、OpenJDK的各种变种(例如IcedTea、Zulu),用的都是相同核心的HotSpot VM。从Java SE 7开始,HotSpot VM就是Java规范的“参考实现”(RI,Reference Implementation)。把它叫做“标准JVM”完全不为过。当大家说起“Java性能如何如何”、“Java有多少种GC”、“JVM如何调优”云云,经常默认说的就是特指HotSpot VM。可见其“主流性”。JDK8的HotSpot VM已经是以前的HotSpot VM与JRockit VM的合并版,也就是传说中的“HotRockit”,只是产品里名字还是叫HotSpot VM。不过要留意的是,这里我说的HotSpot VM特指“正常配置”版,而不包括“Zero / Shark”版。Wikipedia那个页面上把后者称为“Zero Port”。用这个版本的人应该相当少,很多时候它的release版都build不成功…

JVM调优-分代垃圾回收

分代垃圾回收采用分而治之的思想,进行代的划分,把不同生命周期的对象放在不同代上,不同代上采用最适合它的垃圾回收方式进行回收。

虚拟机中的共划分为三个代:年轻代(Young Generation)、年老代(Old Generation)和持久代
(Permanent Generation)。

年轻代
所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

老年代
在年轻代中经历了N次垃圾回收后仍然存活的对象,就会被放到年老代中。因此,可以认为年老代中存放的都是一些生命周期较长的对象。

持久代
持久代主要存放的是Java类的类信息,与垃圾收集要收集的Java对象关系不大。

什么情况下触发垃圾回收?

由于对象进行了分代处理,因此垃圾回收区域、时间也不一样。GC有两种类型:Scavenge GC和Full GC。

Scavenge GC(搜寻)
一般情况下,当新对象生成,并且在Eden申请空间失败时,就会触发Scavenge GC,对Eden区域进行GC,清除非存活对象,并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行,不会影响到年老代。因为大部分对象都是从Eden区开始的,同时Eden区不会分配的很大,所以Eden区的GC会频繁进行。因而,一般在这里需要使用速度快、效率高的算法,使Eden去能尽快空闲出来。

Full GC
对整个堆进行整理,包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收,所以比ScavengeGC要慢,因此应该尽可能减少Full GC的次数。在对JVM调优的过程中,很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC:
· 年老代(Tenured)被写满
· 持久代(Perm)被写满
· System.gc()被显示调用

从JDK1.2版本开始,把对象的引用分为四种级别,从而使程序能更加灵活的控制对象的生命周期。这四种级别由高到低依次为:强引用、软引用、弱引用和虚引用。

特别注意,在程序设计中一般很少使用弱引用与虚引用,使用软引用的情况较多,这是因为软引用可以加速JVM对垃圾内存的回收速度,可以维护系统的运行安全,防止内存溢出(OutOfMemory)等问题的产生。

https://my.oschina.net/ydsakyclguozi/blog/404389

操作系统

线程原理

多线程是宏观上的并行,微观上依旧是串行
多线程之所以能够实现,第一是硬件的功劳,也就是CPU。现代的CPU有一个很重要的特性,就是时间片。每一段获得CPU的代码只能运行一个时间片规定的时间,例如10ms。到时间之后CPU就会把正在运行的代码暂停,然后发生一个中断。这个中断是系统级的事件,只有操作系统能够接手,这样控制权就落到了操作系统手里。
接下来就是操作系统的事情了。线程对操作系统来说就是一段代码+运行时数据(主要是寄存器数据,还有线程中与资源相关的数据,比如打开的文件等)。操作系统会为每个线程保存相关的这些数据,当接收到来自CPU的时间片中断事件时,就会按一定规则从这些线程中选择一个,恢复它的运行时数据,这样CPU就可以继续执行这个线程了。

选择一个合适的线程的过程称为线程调度,最简单的规则是FCFS,也就是按排队的时间先后顺序调度,谁先来排队,下一个就让谁运行。另外还有按优先级、按任务大小等调度策略,以及多种策略的组合等方式。详细的可以去了解一下操作系统的原理。

Java中线程实现主要依赖于操作系统,其本身不进行线程管理。它只是把线程相关的操作进行了封装和抽象,以方便我们使用。例如,Java中的线程可以设置优先级,但如果操作系统本身不支持优先级调度策略,那么为线程设置优先级是没有任何作用的。

操作系统维护了一个任务队列,Java调用.start()之后会把任务放进队列之中等待执行,CPU不会一直执行同一个任务,而是每执行一段时间,就保存当前任务的状态,然后从队列中取到下一个任务继续执行。

总之,操作系统基于cpu时间片通过线程调度,来达到轮换执行线程对应的代码。

数据库性能优化

为什么要分库、分表、分读写?

单表的数据量限制,当单表数据量到一定条数之后数据库性能会显著下降。数据多了之后,对数据库的读、写就会很多。分库减少单台数据库的压力。 一些分库分表的系统,都是通过主键进行散列分裤分表的。这类数据比较特殊,主键就是唯一的获取该条信息的主要途径。比如:京东的订单、财付通的交易记录等。。。该类数据的用法,就是通过订单号、交易号来查询该笔订单、交易。

还有一类数据,比如用户信息,每个用户都有系统内部的一个userid,与userid对应的还有用户看到的登录名。那么如果分库分表的时候单纯通过userid进行散列分库,那么根据登录名来获取用户的信息,就无法知道该用户处于哪个数据库中。或许可以维护一个email—-userid的映射关系,根据email先查询到userid,在根据userid的分库分表规则到对应库的对应表来获取用户的记录信息。这么做是可以的,但是这个映射关系的条数本身也是个瓶颈,原则上是没有减少单表内数据的条数,算是一个单点。并且要维护这个映射关系和用户信息的一致性(修改登录名、多登录名等其他特殊需求),最大一个原因,其实用户信息是一个读大于写的库,web2.0都是以用户为中心,所有信息都和用户信息相关联,所以对用户信息拆分还是有一定局限性的。
对于这类读大于写并且数据量增加不是很明显的数据库,推荐采用读写分离+缓存的模式,试想一下一个用户注册、修改用户信息、记录用户登录时间、记录用户登录IP、修改登录密码,这些是写操作。但是以上这些操作次数都是很小的,所以整个数据库的写压力是很小的。唯一一个比较大的就是记录用户登录时间、记录用户登录IP这类信息,只要把这些经常变动的信息排除在外,那么写操作可以忽略不计。所以读写分离首要解决的就是经常变化的数据的拆分,比如:用户登录时间、记录用户登录IP。这类信息可以单独独立出来,记录在持久化类的缓存中(可靠性要求并不高,登陆时间、IP丢了就丢了,下次来了就又来了)
读写分离,基本的原理是让主数据库处理事务性增、改、删操作(INSERT、UPDATE、DELETE),而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

以Oracle为例,主库负责写数据、读数据,读库仅负责读数据。每次有写库操作,同步更新cache,每次读取先读cache在读DB。写库就一个,读库可以有多个,采用dataguard来负责主库和多个读库的数据同步。

http://blog.csdn.net/kobejayandy/article/details/8775255

Spring-AOP

定义装备

定义切点

Spring中表示方式切点常用的有两种方式:1.使用正则表达式 2.使用AspectJ表达式
使用org.springframework.aop.support.JdkRegexpMethodPointcut来定义正则表达式切点

<bean id="sleepPointcut" class="org.springframework.aop.support.JdkRegexpMethodPointcut">
 <property name="pattern" value=".*sleep"/>
</bean>

上面示例中pattern属性指定了正则表达式,它匹配所有的sleep方法

定义顾问

把通知和切点结合起来:
org.springframework.aop.support.DefaultPointcutAdvisor

<bean id="sleepHelperAdvisor" class="org.springframework.aop.support.DefaultPointcutAdvisor">
 <property name="advice" ref="sleepHelper"/>
 <property name="pointcut" ref="sleepPointcut"/>
</bean>

定义代理对象

<bean id="humanProxy" class="org.springframework.aop.framework.ProxyFactoryBean">
     <property name="target" ref="human"/>
     <property name="interceptorNames" value="sleepHelperAdvisor" />
     <property name="proxyInterfaces" value="test.spring.aop.bean.Sleepable" />
</bean>

Spring还提供了一种自动代理的功能,不用显示定义代理对象,能让通知者和业务对象自动匹配,如下:

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>

http://blog.csdn.net/udbnny/article/details/5870076
http://www.jb51.net/article/83173.htm

AOP概念

AOP是Aspect Oriented Programming的缩写,意思是面向切面(方面)编程。主要的功能有日志记录,性能统计,安全控制,事务处理,异常处理等,主要意图是将功能代码从业务逻辑代码中划分出来,通过对这些行为的分离,我们希望可以将它们独立到非指导业务逻辑的方法中,进而改变这些行为的时候不影响业务逻辑的代码。AOP是其实是通过动态代理模式来实现业务逻辑的插入,使开发者在开发时不用关注其他与业务无关的点,通过代理的方式做到了插拔式操作。

AOP,OOP区别概念

  • AOP是OOP的补充
  • OOP编程将程序分解成各个层次的对象,AOP将程序运行过程分解成各个切面。
  • AOP从程序运行角度考虑程序的结构,提取业务处理过程的切面,
  • OOP是静态的抽象,AOP是动态的抽象,
  • AOP是对应用执行过程中的步骤进行抽象,从而获得步骤之间的逻辑划分。

AOP框架具有的两个特征:
1.各个步骤之间的良好隔离性
2.源代码无关性

IOC概念

IoC,(Inverse of Control)控制反转,其包含两个内容:其一是控制,其二是反转。在程序中,被调用类的选择控制权从调用它的类中移除,转交给第三方裁决。这个第三方比如Spring容器。IoC另解,依赖注入(Dependency Injection),调用类对被调用类的依赖关系由第三方注入。
IoC其实是遵循了软件设计理念的依赖倒转原则,面向对象的设计就是为了实现软件的更好的复用行和扩展性,我们就必须降低我们每个pojo的依赖关系,也就是解耦,耦合度低了,才能更好的重用和扩展。
IoC中用到了工厂模式

WebService

JAX-WS全称是JavaTM API forXML-Based WebServices
JAX-RS全称是JavaTM APIforRESTful Web Services
JAX-WS是针对WebService,JAX-RS是针对RESTful HTTP Service
这是两种风格的SOA架构风格:
JAX-WS以动词为中心,指定的是每次执行函数,大力支持的厂商如BEA,IBM,MS基本都是开发工具厂商
JAX-RS以名词为中心,每次执行的时候指的是资源,大力支持的厂商如Google,Yahoo,亚马孙等都是服务运营厂商

soap rest 区别
http://www.cnblogs.com/zhangchenglzhao/p/3728455.html

以前旧的基于方法的Web Service都是属于JAX-WS,现在较新的RESTful的Web Service则是属于JAX-RS。其中Jersey是SUN的JAX-RS的参考实现,RESTeasy则是Jboss的JAX-RS的实现。RESTful的Web Service简单来说就是将所有东西看作资源,每个资源都有一个URI,对资源的CRUD操作借助于HTTP协议的POST、GET、PUT、DELETE来实现。效率比旧的基于方法的Web Service要高。

开源WebService框架
CXF、Axis,SpringRMI

Hibernate

load与get

load(Object, Serializable):根据id查询 。查询返回的是代理对象,不会立刻访问数据库,是懒加载的。当真正去使用对象的时候才会访问数据库。
load()的时候会发现不会打印出查询语句,而使用get()的时候会打印出查询语句。
使用load()时如果在session关闭之后再查询此对象,会报异常:could not initialize proxy – no Session。处理办法:在session关闭之前初始化一下查询出来的对象:Hibernate.initialize(entity);

load()默认支持延迟加载,在用到对象中的其他属性数 据时才查询数据库,但是万一数据库中不存在该记录,只能抛异常ObjectNotFoundException;所说的load方法抛异常是指在使用该对象的数据时,数据库中不存在该数据时抛异常,而不是在创建这个对象时。由于session中的缓存对于hibernate来说是个相当廉价的资源,所以在load时会先查一下session缓存看看该id对应的对象是否存在,不存在则创建代理。
get()先在一级缓存找,没有就去二级缓存找,再没有就去数据库找,最后若没有就返回null ;而对于get方法,hibernate一定要获取到真实的数据,否则返回null。

TCP服务器

可选的TCP服务器有Mina、Netty、Twisted等,它们都是异步、事件驱动(asynchronous、event-driven)的网络编程框架。
其中MINA和Netty是基于Java语言的,Twisted是Python语言的。语言不是重点,重点的是理念。

  • 传统的BIO(Blocking IO/阻塞IO)进行网络编程时,进行网络IO读写时都会阻塞当前线程,使用BIO实现一个TCP服务器,需要对每个客户端连接开启一个线程,很多线程可能会阻塞住等待读写数据,系统资源消耗大。
  • NIO(Non-Blocking IO/非阻塞IO)或AIO(Asynchronous IO/异步IO)通过IO多路复用技术实现,不需要为每个连接创建一个线程,其底层实现是通过操作系统的一些特性如select、pool、epoll、iocp等。

Mina、Netty、Twisted一起学(一):实现简单的TCP服务器
Netty 4.x 用户指南
Netty in Action 学习
一起学Netty

Reactor 反应器模式

NIO 有一个主要的类Selector,类似一个观察者,只要我们把需要探知的socketchannel告诉Selector,我们接着做别的事情,当有事件发生时,他会通知我们,传回一组SelectionKey,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后,我们从这个Channel中读取数据,接着我们可以处理这些数据。

Reactor模式主要是提高系统的吞吐量,在有限的资源下处理更多的事情。

Base 128 Varints

Java多线程

Runnable

Runnable不是线程,它只是一个接口定义了一个方法,Thread启动才是一个线程。

Thread

thread.join()方法
在主线程中调用子线程的join方法,目的是使主线程阻塞,直到子线程执行完毕才返回到主线程中。
简单理解,在主线程中调用t.join(),也就是在主线程中加入了t线程的代码,必须让t线程执行完毕之后,主线程(调用方)才能正常执行。

线程同步

线程同步一般是要解决在“单对象多线程”的情况下,控制共享变量的访问,或是控制执行步骤顺序。
控制共享变量的策略:

  • 将“单对象多线程”修改成“多对象多线程”;
  • 将“全局变量”降级为“局部变量”;
  • 使用ThreadLocal机制,它用于解决线程间共享变量,使用ThreadLocal声明的变量,即使在线程中属于全局变量,针对每个线程来讲,这个变量也是独立的。
  • 用final域,有锁保护的域和volatile域可以避免非同步的问题。

使用特殊域变量(volatile)实现线程同步
a.volatile关键字为域变量的访问提供了一种免锁机制,
b.使用volatile修饰域相当于告诉虚拟机该域可能会被其他线程更新,
c.因此每次使用该域就要重新计算,而不是使用寄存器中的值
d.volatile不会提供任何原子操作,它也不能用来修饰final类型的变量

控制执行步骤
执行步骤可以使用synchronized关键字来解决
java的每个对象都有一个内置锁,当用synchronized关键字修饰方法时,内置锁会保护整个方法。在调用该方法前,需要获得内置锁,否则调用者就停在阻塞状态。
synchronized的原理和数据库中事务锁的原理类似。在使用过程中应该尽量缩减synchronized覆盖的范围,原因是被它覆盖的范围是串行的,效率低,并且容易产生死锁。
通常没有必要同步整个方法,使用synchronized代码块同步关键代码即可。

JDK中的concurrent工具包

JavaSE5.0中新增了一个java.util.concurrent包来支持同步。
concurrent工具包中也提供了线程池,分为3类:ScheduledThreadPool、FixedThreadPool和CachedThreadPool。
有些情况下需要使用线程的返回值,可以使用JDK中的Callable和CompletionService,前者返回单个线程的结果,后者返回一组线程的结果。
在concurrent工具包中,我们可以使用BlockingQueue来实现生产者-消费者模型
使用信号量来控制线程
JDK提供了Semaphore来实现“信号量”的功能,它提供了两个方法分别用于获取和释放信号量:acquire和release.
可以用synchronized关键字来控制单个线程中的执行步骤,要对线程池中的所有线程的执行步骤进行控制的,有两种方式,一种是使用CyclicBarrier,一种是使用CountDownLatch。
CyclicBarrier使用了类似于Object.wait的机制,它的构造函数中需要接收一个整型数字,用来说明它需要控制的线程数目,当在线程的run方法中调用它的await方法时,它会保证所有的线程都执行到这一步,才会继续执行后面的步骤。
CountDownLatch则是采取类似”倒计时计数器”的机制来控制线程池中的线程,它有CountDown和Await两个方法。
使用重入锁实现线程同步
ReentrantLock类是可重入、互斥、实现了Lock接口的锁,它与使用synchronized方法和快具有相同的基本行为和语义,并且扩展了其能力。
关于Lock对象和synchronized关键字的选择:
如果synchronized关键字能满足用户的需求,就用synchronized,因为它能简化代码
如果需要更高级的功能,就用ReentrantLock类,此时要注意及时释放锁,否则会出现死锁,通常在finally代码释放锁

局部变量实现线程同步
如果使用ThreadLocal管理变量,则每一个使用该变量的线程都获得该变量的副本,副本之间相互独立,这样每一个线程都可以随意修改自己的变量副本,而不会对其他线程产生影响。
ThreadLocal与同步机制
ThreadLocal与同步机制都是为了解决多线程中相同变量的访问冲突问题。
ThreadLocal采用以”空间换时间”的方法,同步机制采用以”时间换空间”的方式

消息传递

BroadcastReceiver

BroadcastReceiver,广播接收者本质上是一种全局的监听器,它可以接收来自系统和应用的的广播,实现系统不同组件之间的通信。比如Activity与通过startService()方法启动的Service之间通信,就可以借助于BroadcastReceiver来实现。

BroadcastReceiver的onReceive方法中不要有执行超过5秒的代码,否则系统会弹出一个超时对话框。对于耗时的操作,请start service来完成。因为当得到其他异步操作所返回的结果时,BroadcastReceiver 可能已经无效了。如果确实需要做的话,可以用goAsync方法,然后在新开一个线程去执行。

注册BroadcastReceive
(1)在代码中注册 context.registerReceiver(BroadcastReceiver receiver, IntentFilter filter)
(2)在配置中注册
注销BroadcastReceive:context.unregisterReceiver(BroadcastReceiver receiver)

http://www.2cto.com/kf/201408/324155.html