2010年10月26日
#
适配器模式：将一个现有类实现的功能接口转变为客户希望的接口
场景：你想使用一个已经存在的类，但是这个类的接口不符合需求，所以需要适配
有2中实现：一种是继承，一种是委托，先来看看继承
第一步：系统现有功能
package com.google.desginpattern.adapter;
/**
* 现有系统提供的功能
*
* @author Administrator
*
*/
public class BMWCar {
public void quickDriver() {
System.out.println("宝马太快");
}
}
第二步：客户需要的接口
package com.google.desginpattern.adapter;
/**
* 客户需要的接口
* @author Administrator
*
*/
public interface Car {
public void driver();
public void brake();
}
第三步：实现客户需要的功能
package com.google.desginpattern.adapter;
/**
* 匹配客户需求的实现
* @author Administrator
*
*/
public class CarAdapter extends BMWCar implements Car {
@Override
public void brake() {
System.out.println("刹车");
}
@Override
public void driver() {
quickDriver();
}
}
测试类：
package com.google.desginpattern.adapter;
public class Test 
{
public static void main(String[] args) {
Car car = new CarAdapter();
car.brake();
car.driver();
}
}
输出：
刹车
宝马太快
如果是委托的方式，改写adapter
package com.google.desginpattern.adapter;
/**
* 匹配客户需求的实现
*
* @author Administrator
*
*/
public class CarAdapter implements Car {
private BMWCar car;
@Override
public void brake() {
System.out.println("刹车");
}
@Override
public void driver() {
car.quickDriver();
}
public BMWCar getCar() {
return car;
}
public void setCar(BMWCar car) {
this.car = car;
}
}
装饰器：装饰器模式主要用于系统扩张功能用，在系统原有的功能上，扩展出其他的功能，JDK中IO包用到很多，比如datainputstream之类，需要用其他流进行构造的上层类，符合面向对象设计的开闭原则
下面我来写个例子：
首先，写一个Car模版，定义基本属性及行为功能driver
package com.google.desginpattern.decoration;
//其实这是个模版
public abstract class Car {
private int spreed;
public int getSpreed() {
return spreed;
}
public void setSpreed(int spreed) {
this.spreed = spreed;
}
public abstract void driver();
}
第二步：具体车比如宝马，这是目前系统中这个类能提供的功能
package com.google.desginpattern.decoration;
//目前系统中此类的功能
public class BMWCar extends Car {
@Override
public void driver() {
System.out.println("我开着宝马车");
}
}
现在我想在这个类上扩展出其他功能，比如：泡妞
第三步：定义一个装饰模板，为什么给他定义个模板呢~因为可以给这个BMWCar类装饰很不同的功能，不只泡妞一个~
继承Car父类，覆盖driver功能，调用Car引用完成driver功能
package com.google.desginpattern.decoration;
//装饰器父类
public abstract class DecorationCar extends Car {
// 引入car
private Car car;
@Override
public void driver() {
car.driver();// 调用此car来完成装饰器的功能
}
public Car getCar() {
return car;
}
public void setCar(Car car) {
this.car = car;
}
}
第四步：具体的装饰功能，添加一个构造函数，参数为Car,为装饰父类Car引用赋值，其实就是原来具体的功能类，回想下IO包里经常new的代码段就明白~~
package com.google.desginpattern.decoration;
//具体的装饰类,添加额外的泡妞功能
public class DecorationBMWCar extends DecorationCar {
public DecorationBMWCar(Car car) {
super.setCar(car);
}
@Override
public void driver() {
// TODO Auto-generated method stub
super.driver();// 调用原来的功能
System.out.println("泡妞");// 添加额外的功能
}
}
测试类：构造的方法很像IO包里的流
package com.google.desginpattern.decoration;
public class Test {
public static void main(String[] args) {
Car car = new DecorationBMWCar(new BMWCar());
car.driver();
}
}
输出：
我开着宝马车
泡妞
摘要: 观察IOC中容器初始化某个Bean顺序，现先一个JAVABean类，看看控制台输出：package com.google.aop.exception.ioc;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory...
阅读全文
此类采用模板模式设计，此类为一个抽象类，但是没抽象方法，每个sync子类需要实现5个受保护的方法
这个5个方法在AbstractQueuedSynchronizer 都抛出throw new UnsupportedOperationException();
AbstractQueuedSynchronizer 中有3个属性：主要声明一个状态和一个wait queue,通过
wait queue中Node 为一个双向链表，需要去理解Node中几个静态字段值的意义，下面为他的源码：
static final class Node {
/** waitStatus value to indicate thread has cancelled */
static final int CANCELLED = 1;
/** waitStatus value to indicate successor's thread needs unparking */
static final int SIGNAL = -1;
/** waitStatus value to indicate thread is waiting on condition */
static final int CONDITION = -2;
/** Marker to indicate a node is waiting in shared mode */
static final Node SHARED = new Node();
/** Marker to indicate a node is waiting in exclusive mode */
static final Node EXCLUSIVE = null;
/**
* Status field, taking on only the values:
* SIGNAL: The successor of this node is (or will soon be)
* blocked (via park), so the current node must
* unpark its successor when it releases or
* cancels. To avoid races, acquire methods must
* first indicate they need a signal,
* then retry the atomic acquire, and then,
* on failure, block.
* CANCELLED: This node is cancelled due to timeout or interrupt.
* Nodes never leave this state. In particular,
* a thread with cancelled node never again blocks.
* CONDITION: This node is currently on a condition queue.
* It will not be used as a sync queue node until
* transferred. (Use of this value here
* has nothing to do with the other uses
* of the field, but simplifies mechanics.)
* 0: None of the above
*
* The values are arranged numerically to simplify use.
* Non-negative values mean that a node doesn't need to
* signal. So, most code doesn't need to check for particular
* values, just for sign.
*
* The field is initialized to 0 for normal sync nodes, and
* CONDITION for condition nodes. It is modified only using
* CAS.
*/
volatile int waitStatus;
/**
* Link to predecessor node that current node/thread relies on
* for checking waitStatus. Assigned during enqueing, and nulled
* out (for sake of GC) only upon dequeuing. Also, upon
* cancellation of a predecessor, we short-circuit while
* finding a non-cancelled one, which will always exist
* because the head node is never cancelled: A node becomes
* head only as a result of successful acquire. A
* cancelled thread never succeeds in acquiring, and a thread only
* cancels itself, not any other node.
*/
volatile Node prev;
/**
* Link to the successor node that the current node/thread
* unparks upon release. Assigned once during enqueuing, and
* nulled out (for sake of GC) when no longer needed. Upon
* cancellation, we cannot adjust this field, but can notice
* status and bypass the node if cancelled. The enq operation
* does not assign next field of a predecessor until after
* attachment, so seeing a null next field does not
* necessarily mean that node is at end of queue. However, if
* a next field appears to be null, we can scan prev's from
* the tail to double-check.
*/
volatile Node next;
/**
* The thread that enqueued this node. Initialized on
* construction and nulled out after use.
*/
volatile Thread thread;
/**
* Link to next node waiting on condition, or the special
* value SHARED. Because condition queues are accessed only
* when holding in exclusive mode, we just need a simple
* linked queue to hold nodes while they are waiting on
* conditions. They are then transferred to the queue to
* re-acquire. And because conditions can only be exclusive,
* we save a field by using special value to indicate shared
* mode.
*/
Node nextWaiter;
/**
* Returns true if node is waiting in shared mode
*/
final boolean isShared() {
return nextWaiter == SHARED;
}
/**
* Returns previous node, or throws NullPointerException if
* null. Use when predecessor cannot be null.
* @return the predecessor of this node
*/
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() { // Used to establish initial head or SHARED marker
}
Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
获取锁定调用的方法，其实这个方法是阻塞的：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
如果获取不成功则调用如下方法：
final boolean acquireQueued(final Node node, int arg) {
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {//当节点是头节点且独占时才返回
setHead(node);
p.next = null; // help GC
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())//阻塞并判断是否打断，其实这个判断才是自旋锁真正的猥琐点，
意思是如果你的前继节点不是head,而且当你的前继节点状态是Node.SIGNAL时，你这个线程将被park()，直到另外的线程release时,发现head.next是你这个node时，才unpark，你才能继续循环并获取锁
interrupted = true;
}
shouldParkAfterFailedAcquire这个方法删除所有waitStatus>0也就是CANCELLED状态的Node,并设置前继节点为signal
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int s = pred.waitStatus;
if (s < 0)
/*
* This node has already set status asking a release
* to signal it, so it can safely park
*/
return true;
if (s > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
}
else
/*
* Indicate that we need a signal, but don't park yet. Caller
* will need to retry to make sure it cannot acquire before
* parking.
*/
compareAndSetWaitStatus(pred, 0, Node.SIGNAL);
return false;
}
使用LockSupport.park(this)，禁用当前线程
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);//block
return Thread.interrupted();
}
释放锁：
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);//unblock
return true;
}
return false;
}
private void unparkSuccessor(Node node) {
/*
* Try to clear status in anticipation of signalling. It is
* OK if this fails or if status is changed by waiting thread.
*/
compareAndSetWaitStatus(node, Node.SIGNAL, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
} catch (RuntimeException ex) {
cancelAcquire(node);
throw ex;
}
}
看下ReentrantLock锁中sync的实现：
static abstract class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
/**
* Performs {@link Lock#lock}. The main reason for subclassing
* is to allow fast path for nonfair version.
*/
abstract void lock();
/**
* Performs non-fair tryLock. tryAcquire is
* implemented in subclasses, but both need nonfair
* try for trylock method.
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
protected final boolean isHeldExclusively() {
// While we must in general read state before owner,
// we don't need to do so to check if current thread is owner
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
// Methods relayed from outer class
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {
return getState() != 0;
}
/**
* Reconstitutes this lock instance from a stream.
* @param s the stream
*/
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // reset to unlocked state
}
}
非公平规则下nonfairTryAcquire，获取当前锁的state,通过CAS原子操作设置为1，并将当前线程设置为独占线程，如果当前线程已经拿了锁，则state增加1
公平锁中 有如下判断：
if (isFirst(current) &&//判断头元素
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
在获取锁步骤：
1.调用tryAcquire来获取，如果失败，则进入2
2.调用addWaiter，以独占模式将node放到tail位置
3.调用acquireQueued方法，此方法阻塞，直到node的pre为head,并成功获取锁定，也可能存在阻塞并打断情况
释放锁的步骤：
1.放弃排他锁持有权
2.unpark 节点的下一个blocked节点
公平锁与非公平锁：从代码上看，非公平锁是让当前线程优先独占，而公平锁则是让等待时间最长的线程优先，非公平的可能让其他线程没机会执行，而公平的则可以让等待时间最长的先执行，但是性能上会差点
linkedhashmap继承自hashmap,他的底层维护的一个链表， private transient Entry<K,V> header 来记录元素的插入顺序和访问顺序;
hashmap的构造函数中调用init()方法，而linkedhashmap中重写了init(),将head元素初始化
void init() {
header = new Entry<K,V>(-1, null, null, null);
header.before = header.after = header;
}
private final boolean accessOrder这个属性表示是否要根据访问顺序改变线性结构
在linkedhashmap中改写了hashmap的get()方法，增加了 e.recordAccess(this)，这个方法主要是根据accessOrder的值判断是否需要实现LRU，
void recordAccess(HashMap<K,V> m) {
LinkedHashMap<K,V> lm = (LinkedHashMap<K,V>)m;
if (lm.accessOrder) {
lm.modCount++;
remove();
addBefore(lm.header);
}
}
addBefore这个方法是把刚访问的元素放到head的前面
private void addBefore(Entry<K,V> existingEntry) {
after = existingEntry;
before = existingEntry.before;
before.after = this;
after.before = this;
}
put方法继承自hashmap,hashmap预留了 e.recordAccess(this)这个方法：
public V put(K key, V value) {
if (key == null)
return putForNullKey(value);
int hash = hash(key.hashCode());
int i = indexFor(hash, table.length);
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);
return null;
}
并通过重写 addEntry(hash, key, value, i)这个方法，实现LRU中的删除动作：
void addEntry(int hash, K key, V value, int bucketIndex) {
createEntry(hash, key, value, bucketIndex);
// Remove eldest entry if instructed, else grow capacity if appropriate
Entry<K,V> eldest = header.after;//找到最老的元素，这个在addBefore里确定，初次赋值是当只有一个head时候，你插入一个元素
if (removeEldestEntry(eldest)) {//这个是受保护的方法，需要自己制定删除策略，比如size() > 最大容量,可自己实现，默认为false,也就是不开启
removeEntryForKey(eldest.key);
} else {
if (size >= threshold)
resize(2 * table.length);
}
}
自己重写这个方法，指定删除策略：
protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
return false;
}
因此，可用linkedhashmap 构建一个基于LRU算法的缓存。
package com.google.study.cache;
import java.util.LinkedHashMap;
import java.util.concurrent.locks.ReentrantLock;
public class SimpleCache<K, V> extends LinkedHashMap<K, V> {
private int maxCapacity;
private ReentrantLock lock = new ReentrantLock();
public SimpleCache(int maxCapacity, float load_factory) {
super(maxCapacity, load_factory, true);
this.maxCapacity = maxCapacity;
}
public int getMaxCapacity() {
return maxCapacity;
}
public void setMaxCapacity(int maxCapacity) {
this.maxCapacity = maxCapacity;
}
@Override
protected boolean removeEldestEntry(java.util.Map.Entry<K, V> eldest) {
// TODO Auto-generated method stub
return super.removeEldestEntry(eldest);
}
public V get(Object key) {
lock.lock();
try {
return super.get(key);
} finally {
lock.unlock();
}
}
public V put(K k, V v) {
lock.lock();
try {
return super.put(k, v);
} finally {
lock.unlock();
}
}
@Override
public void clear() {
lock.lock();
try {
super.clear();
} finally {
lock.unlock();
}
}
@Override
public int size() {
lock.lock();
try {
return super.size();
} finally {
lock.unlock();
}
}
}
1.InitializingBean接口，在初始化Bean时容器会调用前者的afterPropertiesSet()方法
2.DisposableBean接口，在析构Bean时容器会调用destroy()方法
3.BeanFactoryAware接口，当它被BeanFactory创建后，它会拥有一个指向创建它的BeanFactory的引用
4.BeanPostProcessor接口，这个接口两个方法，postProcessBeforeInitialization(Object bean, String beanName)和postProcessAfterInitialization(Object bean, String beanName) 在其他Bean构造前后执行
5.BeanFactoryPostProcessor接口，Spring IoC容器允许BeanFactoryPostProcessor在容器实际实例化任何其它的bean之前读取配置元数据，并有可能修改它
package com.google.springioctest;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
public class A implements BeanPostProcessor, InitializingBean,
BeanFactoryAware, BeanFactoryPostProcessor,DisposableBean {
public A() {
System.out.println("Class A");
}
private void init(){
System.out.println("Class A init");
}
@Override
public void afterPropertiesSet() throws Exception {
// TODO Auto-generated method stub
System.out.println("Class A afterPropertiesSet()");
}
@Override
public void destroy() throws Exception {
System.out.println("Class A destroy()");
}
@Override
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
// TODO Auto-generated method stub
System.out.println("Class A setBeanFactory()");
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName)
throws BeansException {
System.out.println("Class A postProcessAfterInitialization");
return null;
}
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
// TODO Auto-generated method stub
System.out.println("Class A postProcessBeforeInitialization");
return null;
}
@Override
public void postProcessBeanFactory(
ConfigurableListableBeanFactory beanFactory) throws BeansException {
// TODO Auto-generated method stub
System.out.println("Class A postProcessBeanFactory");
}
}
执行结果：
Class A
Class A setBeanFactory()
Class A afterPropertiesSet()
Class A init
Class A postProcessBeanFactory
创建一个B类，由A来监管B类，B实现 InitializingBean,BeanFactoryAware,BeanFactoryPostProcessor
package com.google.springioctest;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
public class B implements InitializingBean, BeanFactoryAware,
BeanFactoryPostProcessor {
public B() {
System.out.println("Class B");
}
public void init() {
System.out.println("Class B init");
}
@Override
public void afterPropertiesSet() throws Exception {
System.out.println("Class B afterPropertiesSet");
}
@Override
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
System.out.println("Class B beanFactory");
}
@Override
public void postProcessBeanFactory(
ConfigurableListableBeanFactory beanFactory) throws BeansException {
// TODO Auto-generated method stub
System.out.println("Class B postProcessBeanFactory");
}
}
执行结果：
Class A
Class A setBeanFactory()
Class A afterPropertiesSet()
Class A init
Class B
Class B beanFactory
Class B afterPropertiesSet
Class B init
Class A postProcessBeanFactory
Class B postProcessBeanFactory
可以看出A并没有监管B类，也就是没调用BeanPostProcessor这个接口的2个方法
再来去掉B上的BeanFactoryPostProcessor接口
package com.google.springioctest;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
public class B implements InitializingBean,
BeanFactoryAware{
public B() {
System.out.println("Class B");
}
public void init() {
System.out.println("Class B init");
}
@Override
public void afterPropertiesSet() throws Exception {
System.out.println("Class B afterPropertiesSet");
}
@Override
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
System.out.println("Class B beanFactory");
}
public void postProcessBeanFactory(
ConfigurableListableBeanFactory beanFactory) throws BeansException {
// TODO Auto-generated method stub
System.out.println("Class B postProcessBeanFactory");
}
}
执行输出：Class A
Class A setBeanFactory()
Class A afterPropertiesSet()
Class A init
Class A postProcessBeanFactory
2010-11-3 21:33:31 org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
信息: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@8916a2: defining beans [A,B]; root of factory hierarchy
Class B
Class B beanFactory
Class A postProcessBeforeInitialization
2010-11-3 21:33:31 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry destroySingletons
信息: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@8916a2: defining beans [A,B]; root of factory hierarchy
Class A destroy()
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'B' defined in class path resource [icoContext.xml]: Invocation of init method failed; nested exception is java.lang.NullPointerException
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)
at com.google.springioctest.Test.main(Test.java:8)
Caused by: java.lang.NullPointerException
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1393)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335)
... 15 more
抛异常了。。。。。
原因是A类里的postProcessBeforeInitialization，postProcessAfterInitialization2个方法没有返回bean,修改下
执行输出：
Class A
Class A setBeanFactory()
Class A afterPropertiesSet()
Class A init
Class A postProcessBeanFactory
2010-11-3 21:37:10 org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
信息: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1193779: defining beans [A,B]; root of factory hierarchy
Class B
Class B beanFactory
Class A postProcessBeforeInitialization
Class B afterPropertiesSet
Class B init
Class A postProcessAfterInitialization
在B类被初始化之后，也就是调用afterPropertiesSet之前那段时间，属性初始化完成后，进行了回调，控制B类
注意:在写被监控的Bean的时候，不能实现BeanFactoryPostProcessor这个接口,没看源码，其实也不知道是什么原因，哈哈，只能硬记了
在所有使用 spring 的应用中, 声明式事务管理可能是使用率最高的功能了, 但是, 从我观察到的情况看, 绝大多数人并不能深刻理解事务声明中不同事务传播属性配置的的含义, 让我们来看一下TransactionDefinition 接口中的定义 ，在 spring 中一共定义了六种事务传播属性, 如果你觉得看起来不够直观, 那么我来转贴一个满大街都有的翻译
PROPAGATION_REQUIRED -- 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS -- 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY -- 支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW -- 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED -- 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER -- 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED -- 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。
前六个策略类似于EJB CMT，第七个（PROPAGATION_NESTED）是Spring所提供的一个特殊变量。
它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为（如Spring的DataSourceTransactionManager）
在我所见过的误解中, 最常见的是下面这种:
假如有两个业务接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一个方法实现如下
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
// 调用 ServiceB 的方法
ServiceB.methodB();
}
那么如果 ServiceB 的 methodB 如果配置了事务, 就必须配置为 PROPAGATION_NESTED
这种想法可能害了不少人, 认为 Service 之间应该避免互相调用, 其实根本不用担心这点，PROPAGATION_REQUIRED 已经说得很明白,
如果当前线程中已经存在事务, 方法调用会加入此事务, 果当前没有事务，就新建一个事务, 所以 ServiceB#methodB() 的事务只要遵循最普通的规则配置为 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB (我们称之为内部事务, 为下文打下基础) 抛了异常, 那么 ServiceA#methodA(我们称之为外部事务) 如果没有特殊配置此异常时事务提交 (即 +MyCheckedException的用法), 那么整个事务是一定要 rollback 的, 什么 Service 只能调 Dao 之类的言论纯属无稽之谈, spring 只负责配置了事务属性方法的拦截, 它怎么知道你这个方法是在 Service 还是 Dao 里 ?
最容易弄混淆的其实是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那么这两种方式又有何区别呢? 我简单的翻译一下 Juergen Hoeller 的话 :
PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.
另一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交.
由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.
那么外部事务如何利用嵌套事务的 savepoint 特性呢, 我们用代码来说话
ServiceA {
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
ServiceB.methodB(); }
}
ServiceB {
/**
* 事务属性配置为 PROPAGATION_REQUIRES_NEW
*/
void methodB() {
}
}
这种情况下, 因为 ServiceB#methodB 的事务属性为 PROPAGATION_REQUIRES_NEW, 所以两者不会发生任何关系, ServiceA#methodA 和 ServiceB#methodB 不会因为对方的执行情况而影响事务的结果, 因为它们根本就是两个事务, 在 ServiceB#methodB 执行时 ServiceA#methodA 的事务已经挂起了 (关于事务挂起的内容已经超出了本文的讨论范围, 有时间我会再写一些挂起的文章) .
ServiceA {
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
ServiceB.methodB();
}
}
ServiceB {
/**
* 事务属性配置为 PROPAGATION_NESTED
*/
void methodB() {
}
}
ServiceB#methodB 如果 rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint(注意, 这是本文中第一次提到它, 潜套事务中最核心的概念), 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式:
1. 改写 ServiceA 如下
ServiceA {
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
try {
ServiceB.methodB();
} catch (SomeException) {
// 执行其他业务, 如 ServiceC.methodC();
}
}
}
这种方式也是潜套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行 ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint, 所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都没有办法做到这一点. (题外话 : 看到这种代码, 似乎似曾相识, 想起了 prototype.js 中的 Try 函数 )
2. 代码不做任何修改, 那么如果内部事务(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此), 外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback (+MyCheckedException).
上面大致讲述了潜套事务的使用场景, 下面我们来看如何在 spring 中使用 PROPAGATION_NESTED, 首先来看 AbstractPlatformTransactionManager
JdbcTransactionObjectSupport 告诉我们必须要满足两个条件才能 createSavepoint :
2. java.sql.Savepoint 必须存在, 即 jdk 版本要 1.4+
3. Connection.getMetaData().supportsSavepoints() 必须为 true, 即 jdbc drive 必须支持 JDBC 3.0
确保以上条件都满足后, 你就可以尝试使用 PROPAGATION_NESTED 了.
缓存基本特性：
1.时间记录，进入Cache的时间
2.timeout过期时间，cache里面数据多久过期
3.eviction policy 清楚策略，最不经常访问的数据，最久没访问到的数据
4.命中率:Cache的数据被选中的比率
5.分级Cache，支持 Region分级，比如ehcache
6.分布式，分布在不同的计算机上
7.锁，事务，数据同步
各个Cluster之间的Cache同步有多种实现方法。比如JMS,RMI
Cache中一般有get,put,remove,clear
对于Cluster的Cache来说，读(get)肯定是local的，只需要从本地内存中获取，而Remove/clear，需要和其他计算机同步，put可以是local的，因为如果读不到，可以从数据库中读
remote put:一台计算机把数据放到自己的Cache中，这个数据需要传播到Cluster其他计算机上，这样其他Cluster可以同步，但是如果数据大，传播的代价就大了
local put:只放到本地计算机的Cache里，不需要同步到其他Cluster，从Cache得不到的数据可以在数据库里读取
过期数据：在hibernate等orm工具中，有一个原则，就是不要把没有commit的数据放到缓存中，防止脏读，而且remove之后必须通知其他Cluster,保证大部分时间内，给用户的数据不是过期的数据
ORM Cache中，一般分2种Cache,一种是类缓存，一种是查询缓存，类缓存是以ID对应Entity对象，而查询缓存是用来存放一条查询语句对应的结果集，然后再到类缓存里找响应的实体。
类缓存：一类Entity一个Region
查询缓存:hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面org.hibernate.cache. UpdateTimestampsCache所指定的缓存配置里面，当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。 可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。
7
PriorityBlockingQueue：一个无界的
阻塞队列，它使用与类
PriorityQueue
相同的顺序规则，并且提供了阻塞检索的操作。虽然此队列逻辑上是无界的，但是由于资源被耗尽，所以试图执行添加操作可能会失败（导致
OutOfMemoryError）。此类不允许使用
null
元素。依赖自然顺序的优先级队列也不允许插入不可比较的对象（因为这样做会抛出
ClassCastException）。
PriorityBlockingQueue()
用默认的初始容量 (11) 创建一个
PriorityBlockingQueue，并根据元素的自然顺序排序其元素（使用
Comparable）。
PriorityBlockingQueue(Collection<? extends E> c)
创建一个包含指定集合中元素的
PriorityBlockingQueue。
PriorityBlockingQueue(int initialCapacity)
使用指定的初始容量创建一个
PriorityBlockingQueue，并根据元素的自然顺序排序其元素（使用
Comparable）。
PriorityBlockingQueue(int initialCapacity,
Comparator<? super E> comparator)
使用指定的初始容量创建一个
PriorityBlockingQueue，并根据指定的比较器排序其元素。
此类每次offer元素，都会有一个fixup操作，也就是排序，如果没有构造的时候传入自己实现的比较器，就采用自然排序，否则采用比较器规则，进行二分查找，比较，保持列头是比较器希望的那个最大或则最小元素。
private void fixUp(int k) {
if (comparator == null) {
while (k > 1) {
int j = k >> 1;
if (((Comparable<E>)queue[j]).compareTo((E)queue[k]) <= 0)
break;
Object tmp = queue[j]; queue[j] = queue[k]; queue[k] = tmp;
k = j;
}
} else {
while (k > 1) {
int j = k >>> 1;
if (comparator.compare((E)queue[j], (E)queue[k]) <= 0)
break;
Object tmp = queue[j]; queue[j] = queue[k]; queue[k] = tmp;
k = j;
}
}
}
public interface Callable<V>
返回结果并且可能抛出异常的任务。实现者定义了一个不带任何参数的叫做 call 的方法。 此方法返回计算结果，并抛出经过检查的异常
与Runnable相似，但是Runnable不返回计算结果，且不抛异常
void
run()
使用实现接口 Runnable 的对象创建一个线程时，启动该线程将导致在独立执行的线程中调用对象的
run 方法。
V
call()
计算结果，如果无法计算结果，则抛出一个异常。
通过callable 和Runnable构建FutureTask任务，调用run()方法获得计算结果，并输出
package com.google.minatest.concurrent;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
import com.google.minatest.entity.Message;
public class FutureTaskStudy {
FutureTask<Message> future = null;
public static void main(String[] args) {
try {
new FutureTaskStudy().test();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
}
public void test() throws InterruptedException, ExecutionException {
future = new FutureTask<Message>(new CallableImpl());
future.run();
System.out.println(future.get());
future = new FutureTask<Message>(new RunnableImpl(), null);
future.run();
System.out.println(future.get());
}
private class CallableImpl implements Callable<Message> {
public Message call() throws Exception {
return new Message();
}
}
private class RunnableImpl implements Runnable {
public void run() {
new Message();
}
}
}
ScheduledExecutorService 利用线程池进行调度任务，内部使用一个DelayedWorkQueue实现，返回ScheduledFuture，而DelayQueue是用优先级队列PriorityQueue实现的一个阻塞队列，优先队列的比较基准值是时间
private static class DelayedWorkQueue
extends AbstractCollection<Runnable>
implements BlockingQueue<Runnable> {
private final DelayQueue<ScheduledFutureTask> dq = new DelayQueue<ScheduledFutureTask>();
}
public class DelayQueue<E extends Delayed> extends AbstractQueue<E>
implements BlockingQueue<E> {
private transient final ReentrantLock lock = new ReentrantLock();
private transient final Condition available = lock.newCondition();
private final PriorityQueue<E> q = new PriorityQueue<E>();
下面为一个小例:
public class ConcurrentTimer {
public static void main(String[] args) {
new ConcurrentTimer().getScheduledExecutorService();
}
public void getScheduledExecutorService() {
ScheduledExecutorService service = Executors.newScheduledThreadPool(10);
service.scheduleAtFixedRate(new Command(), 1, 1, TimeUnit.SECONDS);
}
public class Command implements Runnable {
public void run() {
System.out.println("Command");
}
}
}
volatile语义：告诉处理器，不要到工作内存中找我，而是直接到主存中操作我，多线程或者多核环境下，变量共享
使用volatile要注意，他只能保证可见性，但不能保证原子性；
如i++之类的操作，他分为read i的值，之后执行i+1
当出现并发情况时，1线程read i的值，而2线程修改了i的值，这个时候1线程如果再将值刷到主存的话就会造成覆盖。
可以通过synchronized在同步代码段，保证原子性
或者使用jdk1.5的原子包
package com.google.study.MQ;
import java.util.LinkedList;
import java.util.List;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
public class MessageQueue {
private List<Message> messageList = new LinkedList<Message>();
private final ReentrantLock lock = new ReentrantLock();
private Condition notFull = lock.newCondition();
private Condition notEmpty = lock.newCondition();
private Integer maxNum = 5;
private Integer minNum = 0;
public int size() {
return messageList.size();
}
public void produce(Message e) throws InterruptedException {
try {
lock.lock();
while (messageList.size() == maxNum) {
notFull.await();
}
messageList.add(e);
notEmpty.signal();
} finally {
lock.unlock();
}
}
public void consume() {
try {
lock.lock();
while (messageList.size() == minNum) {
notEmpty.await();
}
messageList.get(0);
messageList.remove(0);
notFull.signal();
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
package com.google.study.MQ;
public class Consume implements Runnable {
private MessageQueue queue;
public Consume(MessageQueue queue) {
this.queue = queue;
}
@Override
public void run() {
while (true) {
queue.consume();
System.out.println(queue.size());
try {
Thread.sleep(50);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
package com.google.study.MQ;
public class Produce implements Runnable {
private MessageQueue queue;
public Produce(MessageQueue queue) {
this.queue = queue;
}
@Override
public void run() {
while (true) {
try {
queue.produce(getMessage());
Thread.sleep(100);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
private Message getMessage() {
Message m = new Message();
m.setName("1");
m.setValue(1);
return m;
}
}
package com.google.study.MQ;
import java.io.Serializable;
public class Message implements Serializable {
private int value;
private String name;
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
public String getName() {
return name;
}
package com.google.study.MQ;
public class Test {
public static void main(String[] args) {
MessageQueue queue = new MessageQueue();
Thread p1 = new Thread(new Produce(queue));
Thread p2 = new Thread(new Produce(queue));
Thread p3 = new Thread(new Produce(queue));
Thread p4 = new Thread(new Produce(queue));
Thread c1 = new Thread(new Consume(queue));
Thread c2 = new Thread(new Consume(queue));
p1.start();
p2.start();
p3.start();
p4.start();
c1.start();
c2.start();
}
}
public void setName(String name) {
this.name = name;
}
}
public class
ReentrantReadWriteLock extends
Object implements
Object implements
ReadWriteLock,
Serializable
1.可重入，可重入的意思当前线程已获该锁，还可以再获取，但是读写锁里，WriteLock可以获取ReadLock,但是ReadLock不能获取WriteLock
2.WriteLock可以降级为ReadLock,意思是：先获取WriteLock,在获取ReadLock,释放WriteLock,这时候线程就将keep ReadLock,但是如果ReadLock想要升级为WriteLock，则不可能，因为根据读写锁的可重入特性，ReadLock排斥所有WriteLock,也就是(1)特性
3.ReadLock可以被多个线程持有并在作用时排斥任何WriteLock,而WriteLock隔离性比ReadLock高，它是完全的排斥，根据这一特性，读写锁适合高频率读，但不适合高频率写
4.不管是ReadLock,WriteLock都支持Interrupt
5.WriteLock支持Condition,但是ReadLock不支持Condition,将抛出UnsupportedOperationException。
下面是个小例子：
package com.google.study;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.ReadLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
public class ReentrantLockStudy {
private Map<Integer, Result> map = new ConcurrentHashMap<Integer, Result>();
private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
private final WriteLock writeLock = lock.writeLock();
private final ReadLock readLock = lock.readLock();
public Result get(Integer key) {
Result value = null;
readLock.lock();// 获取读锁
try {
value = map.get(key);
if (value == null) {// 如果没有该结果
readLock.unlock();// 必须释放读锁
writeLock.lock();// 获取写锁
value = map.get(key);
if (value == null) {
value = getResult();
map.put(key, value);
}
readLock.lock();// 重新降级为读锁
writeLock.unlock();
}
} catch (Exception e) {
writeLock.unlock();
e.printStackTrace();
} finally {
readLock.unlock();
}
return value;
}
public void put(Integer key, Result value) {
writeLock.lock();
try {
map.put(key, value);
} finally {
writeLock.unlock();
}
}
private Result getResult() {
return new Result();
}
private static class Result {
}
}
cp:文件复制
MV：移动或者重命名
rm:删除，rm -rf则是递归删除
mkdir:创建目录
rmdir:删除空目录
cd：改变目录
PWD:显示当前的绝对路径
ls: 列出子目录和文件
chmod：修改权限 chmod ugo+r file1.txt u表示用户，G表示拥有者同组的其他用户，g表示拥有着不同组的其他用户，a表示所有
tar打包
打包：tar -cvf filename.tar /home/tt.txt
tar -cvf filename.tar /home/t1.txt /home/t2.txt
抽取：tar -xvf filename.tar
打包并压缩
使用gzip:
压缩tar -czvf filename.tar.gz /home/t1.txt /home/t2.txt
解压tar -xzvf filename.tar.g
netstat:
netstat -pan|grep 2809查看2809端口
lsof -i 显示所有打开的端口
bundle的生命周期分为installed,resovled,starting,active,stopping,unstalled
install:解析bundle的MANIFEST.MF信息，校验格式，同时查看是否存在相同的bundle, 分配bundleid,生成bundle对象，并放入已安装的bundles集合中，状态为installed,可以通过命令bundle id来查看这个ID的bundle的关系图
resolve:寻找bundle中所需依赖的包和bundle是否存在以及被resolve，包括import-package,require-bundle，如寻找到则进入检查，检查完冲突后形成绑定关系，有个关系图直接定位，以便加载类时直接加载。
start:检查bundle状态，如未resolve,则先resolve，寻找MANIFEST.MF中配置的bundle-activator,找到后调用他的start方法，将bundle状态改为 active
stop:卸载当前bundle对外提供的service,并释放bundle引用的其他服务，之后调用activator类里的stop方法，改bundle状态为resovled
uninstall:
检查bundle状态，如果为active,则先stop,释放bundle对其他bundle的类依赖，如其他bundle依赖此bundle的类，则记录，如没有，则释放该bundle的classloader，最终修改bundle的状态为unstalled
update:
首先是停止当前bundle,
重新安装并resovle bundle,恢复到bundle更新之前的状态
如果希望更新bundle所引用到的类，则必须refresh动作，但refresh也值对unreslve状态以及uninstall时还有其他类依赖classloader还存活的bundle进行unresolve动作，并重新resolve对他们有依赖的bundle，建立新的绑定关系图，因此refresh可能会让某些bundle的classloader重建.
前几个人因为项目中考虑使用OSGI来开发，因此和同事调研了大概1个多月，当时没做记录，现在来弥补下
OSIG，一个构件模块化，动态化系统的标准，众多应用服务器实现微核采用的技术，如weblogic,glassfish,最出名的是equinox,eclipse核心。
在OSGI环境中，体现模块化，动态化，
模块化：模块之间独立，部首其他模块影响。
其他模块只能访问该模块对外提供的服务
模块具备独立的生命周期，如启动，停止，更新
动态化：
对于模块的增加，修改，删除，不需要做 额外的处理。
OSGI中，每个模块就是在物理上就是一个bundle,一个JAR包，是OSGI部署的最小单位，需要在每个JAR包的MANIFEST.MF中给这个bundle标识，象bundle-name,Bundle-SymbolicName,Bundle-ClassPath,Bundle-Activator;
OSGI中bundle的隔离是通过java ClassLoader隔离性来完成的，JAVA中每个classloader空间都是隔离的，默认的classloader有bootStrap ClassLoader(jre/lib,jre/classes) extension classloader(jre/lib/ext),system classloader(-classpath),一般osgi框架还实现自己的应用类加载器。
bundle隔离机制实现：每个bundle都有一个独立的classloader,通过bundle-classpath指定JAR路径
java中通过双亲委托来加载类，寻找类首先是从parent classloader中寻找，如果找不到才在当前的clasloader中寻找
bundle类加载过程：
java.*开头的类委派给parent classloader加载；
bootdelegationcan参数中配置的也委派给parent classloader加载，parent classloader找不到则继续下面的操作；
是否在import-Package中，在则委派给导出他的bundle的classloader 加载，不在则继续下面
是否在require-bundle中，在则委派给相应的bundleloader加载，不在继续下面的
是否在自己的bundle-classpath 中，不在则继续下面的
是否在fragmentsbundle的classpath中寻找，不在则继续下面的( 在 OSGi 框架中提供了一种称为 fragment 的特殊 bundle。在装载的过程中，这类 fragment 是被附加到被称为“宿主”的 bundle 上，最后作为一个整体 bundle 运行于 OSGi 环境中。最为典型的 fragment 应用场景是多语言包发布，将包含多语言包的 bundle 作为主体程序 bundle 的 fragment，这样可以将多语言包和主体 bundle 作为两个独立的部分来发布，但在运行时它们又是一个整体。)
是否在export-package中，不在继续下面的
是否在dynamicimport-package中，在则加载，不在则抛classNotfoundexception
通过MANIFEST.MF定义import-package等，当要注意，最好定义包的版本 如：Import-Package: org.eclipse.osgi.framework.console;version="1.0.0",
org.osgi.framework;version="1.3.0"
Import-Package寻找机制：
resolved的优先未resolved
版本高的优先版本低的，如果版本一样，则比较bundle id,小的优先，也就是先安装的bundle优先
代理为要控制访问的类提供了一种可行的途径，他为目标类引入一个中间层，JDK1.3后也有动态代理，不过性能不是很好，1.6有所加强。
CGLIB是一个强大的代码生成包，在ASM上建立，在一些开源工具中经常可以看到他的身影，比如hibernate,spring。
CGLIB底层通过字节码处理框架ASM来将字节码生成新的类，在spring AOP中不强制使用CGLIB，默认是JDK动态代理。
CGLIB 包情况：
net.sf.cglib.core:底层字节码处理类，大部分与ASM有关。
net.sf.cglib.transform:编译期或运行期和类文件的转换
net.sf.cglib.proxy：实现创建代理和方法拦截器的类
net.sf.cglib.reflect:实现快速放射
net.sf.cglib.util:工具包
net.sf.cglib.beans:javabean相关工具类
通过CGLIB创建动态代理，本质上，他是动态的生成目标类的子类，覆盖目标类所有不是final的方法，并给他们设置好callback,因此，原有类的每个方法调用就会变成自定义的拦截方法。
创建动态代理时通常要用到如下api:net.sf.cglib.proxy.Callback这个接口，他是很关键的一个接口，所有被net.sf.cglib.proxy.Enhancer类调用的回调借口都要继承这个接口
如：public interface MethodInterceptor
extends Callback
{
/**
* All generated proxied methods call this method instead of the original method.
* The original method may either be invoked by normal reflection using the Method object,
* or by using the MethodProxy (faster).
* @param obj "this", the enhanced object
* @param method intercepted Method
* @param args argument array; primitive types are wrapped
* @param proxy used to invoke super (non-intercepted method); may be called
* as many times as needed
* @throws Throwable any exception may be thrown; if so, super method will not be invoked
* @return any value compatible with the signature of the proxied method. Method returning void will ignore this value.
* @see MethodProxy
*/
public Object intercept(Object obj, java.lang.reflect.Method method, Object[] args,
MethodProxy proxy) throws Throwable;
}
这个是基与方法的回调，第一个参数是代理对象，第二个是被拦截的方法对象，第三个是方法参数，第四个是方法的代理对象。
public class MyClass {
public void method1() {
System.out.println("method1");
}
public void method2() {
System.out.println("method2");
}
}
拦截器：
public class MethodInterceptImpl implements MethodInterceptor {
public Object intercept(Object arg0, Method arg1, Object[] arg2,
MethodProxy arg3) throws Throwable {
System.out.println(arg1.getName()+"--intercept");
arg3.invokeSuper(arg0, arg2);// 这里其实也可以用原来的方法对象来执行，但是性能上不如cglib的方法代理类
return null;
}
public class MainTest {
public static void main(String[] args) {
simpleTest();
}
private static void simpleTest() {
Enhancer en = new Enhancer();
en.setCallback(new MethodInterceptImpl());
en.setSuperclass(MyClass.class);
MyClass m = (MyClass) en.create();
m.method1();
m.method2();
}
结果：method1--intercept
method1
method2--intercept
method2
现实项目中可能存在某些需求，比如method1需要拦截，而method2不需要拦截。那我们可以对callback做下选择,使用net.sf.cglib.proxy.CallbackFilter做一些过滤。
public class MethodFilterImpl implements CallbackFilter {
private final static int execute = 0;
private final static int unexecute = 1;
public int accept(Method method) {
String methodName = method.getName();
if("method1".equals(methodName)){
return execute;
}
return unexecute;
}
}
调用的时候需要给callback设置好索引位置，因为accept的返回值就是callbacks数组的索引位置。
private static void filterTest() {
Enhancer en = new Enhancer();
Callback[] callbacks = new Callback[] { new MethodInterceptImpl(),
NoOp.INSTANCE };//这里拦截器的索引位置要与filter里的设置一致
en.setCallbacks(callbacks);
en.setSuperclass(MyClass.class);
en.setCallbackFilter(new MethodFilterImpl());
MyClass m = (MyClass) en.create();
m.method1();
m.method2();
}
这里callbacks[1]这个位置使用了NoOp这个回调接口
public interface NoOp extends Callback
{
/**
* A thread-safe singleton instance of the <code>NoOp</code> callback.
*/
public static final NoOp INSTANCE = new NoOp() { };
}
这个callback其实就是直接把任务委派给这个方法在父类中的实现，其实也等同于没做什么额外的事情
执行结果：method1--intercept
method1
method2
method2 并未被MethodInterceptImpl拦截
}
JAVA GC有很多种算法，比如引用记数，复制标记-清楚，标记-整理，每种算法都有优缺点，看特定场景选择。
比如当很多临时对象时，复制算法比较好，因为周期短，复制的可以少点，如果许多长寿对象，反复复制就不乐观了，这个时候标记-整理比较好。
目前SUN JAVA的GC用的是分代垃圾回收。
分为年轻代，老年代，持久代
年轻代存放生命周期很短的对象，这部分对象在GC的时候，很多已经是非活动对象，因此采用复制算法，只需要将少量的存货对象copy到to space，存货越少，效率越高。
年轻代的GC叫minor gc，经过多次复制，依旧存活的对象将移出年轻代，移到年老代。
年轻代分为：
eden:每当对象创建的时候，总是被分配到这个区域
survivor1:复制算法中的from space
survivor2:复制算法中的to space
年老代：
生命周期长，经过多次minor gc,依旧存活的对象
老年代的GC 叫major gc,通常也叫full gc
采用标记-整理算法。老年区域比较大，需要时间长
minor gc可能引发full gc。当eden+from space空间大于老年代剩余空间时，就会fucc gc,悲观算法
持久代：存放class信息和方法信息的地方，可通过-XX:MaxPermSize来调整最大值
-XX:NewRatio来设置年轻代与年老代比值
-XX:SurvivorRatio设置eden与survivor区的比值
-XX:MaxTenuringThreshold设置垃圾的年龄，如果=0，则表示不经过survivor区，直接进入年老代
-XX：ParallelGCThreads配置并行收集的线程数，最好与CPU数相同
-XX:+UseParallelGC 选择使用并行收集器