2010年10月25日
#
適配器模式：將一個現有類實現的功能接口轉變為客戶希望的接口
場景：你想使用一個已經存在的類，但是這個類的接口不符合需求，所以需要適配
有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 選擇使用并行收集器
JVM內存結構主要包括兩個子系統和兩個組件。
兩個子系統分別是Classloader子系統和Executionengine(執行引擎)子系統；兩個組件分別是Runtimedataarea(運行時數據區域)組件和Nativeinterface(本地接口)組件。
Classloader子系統:裝載class信息到運行時數據區
Executionengine(執行引擎)子系統：執行Class的地方
Runtimedataarea(運行時數據區域)組件:經常說的JVM內存，分為5個區域
（1）heap(堆)：存放new 出來的對象和數組，由GC管理內存，每個JVM實例一個堆
（2）javastack(棧):每個線程一個javastack，只有壓棧和出棧2個動作，以楨為單位
(3)methodarea(方法區)：每個JVM實例一個，存儲類信息，靜態的變量
(4)ProgramCounter：每個線程都有一個PC寄存器，記錄線程執行的下個地址
(5)nativemethodstack：保存本地方法進去區域的地址
這里heap和methodarea是所有線程共享，而其他3個則是以線程為粒度隔離的。
Nativeinterface(本地接口)組件：與本地lib交互，是與其他語言交互的接口，當調用native方法時，不受JVM限制，可能會拋nativeheapOutOfMemory
棧是JVM的內存指令區，JAVA基本類型，JAVA指令代碼，常量都保存在stack中，存取速度快，數據可以共享，缺點是棧中的數據大小和生命周期是確定的，不靈活
堆是JVM的內存數據區，對象實例包括他的屬性都作為數據存儲在heap中，對象實例在heap中分配好后，需要在stack中保存4個字節的heap內存地址，用來定位該對象在heap的位置，找到該實例，可以動態的分配內存大小，生存期不需要告訴編譯器，但是存取慢。
例子：對象的方法和屬性保存在哪里？
方法信息在方法區中，屬性在heap中
另外，對象的靜態屬性在方法區中。
非靜態方法和靜態方法：
實例方法有一個隱含的傳入參數，該參數就是this,也就是當前對象實例在stack中的地址指針，因為調用非靜態方法時，都要先new出來。
靜態方法無此隱含參數，不需要new 對象，只要class文件被ClassLoader加載到JVM的stack中，靜態方法就能被調用，當然，靜態方法取不到heap中的對象屬性，因為還沒對象呢。。。
spring AOP中，可以通過annotation來簡化XML上的配置，可以很靈活的使切面切入到自己想要的方法上，而不需要象aop:config里一定要切入到特定命名方法上
使用annotation來表示pointcut，需要在xml里配置org.springframework.aop.support.annotation.AnnotationMatchingPointcut，
如：<bean name="timeoutPointcut"
class="org.springframework.aop.support.annotation.AnnotationMatchingPointcut">
<constructor-arg index="0"
value="com.hengtian.fxfundsystem.aop.annotation.UseAOPAnnotation">
</constructor-arg>
<constructor-arg index="1"
value="com.hengtian.fxfundsystem.aop.annotation.TimeoutAnnotation" />
</bean>
第一個參數是標在目標類上的annotation,第二天參數是標注在方法上的Annotation
因此，首先要在自己的工程里定義2個annotation，一個為TimeoutAnnotation，一個為UseAOPAnnotation
@Target({ElementType.TYPE })//表示類標注
@Retention(RetentionPolicy.RUNTIME)
@Inherited
public @interface UseAOPAnnotation {
}
@Target({ElementType.METHOD})//表示方法標注
@Retention(RetentionPolicy.RUNTIME)
public @interface TimeoutAnnotation {
/**
* 默認值(-1)：表示不啟用超時
*/
public static final long DefaultValue = -1;
/**
* 超時時間，單位是ms
*
* @return
*/
long value() default DefaultValue;
}
在需要AOP的類上使用
@UseAOPAnnotation
@Component("StrongDuck")
public class StrongDuck {
@TimeoutAnnotation(70000)
public void say(){
System.out.println("I am a strong duck");
}
}
timeout通知：
public class TimeoutAdvice implements MethodInterceptor {
/*
* (non-Javadoc)
*
* @see
* org.aopalliance.intercept.MethodInterceptor#invoke(org.aopalliance.intercept
* .MethodInvocation)
*/
public Object invoke(final MethodInvocation methodInvocation)
throws Throwable {
Method targetMethod = methodInvocation.getMethod();
TimeoutAnnotation timeoutAnnotation = targetMethod
.getAnnotation(TimeoutAnnotation.class);
if (timeoutAnnotation != null) {
long waitTime = timeoutAnnotation.value();
if (waitTime != TimeoutAnnotation.DefaultValue) {
Future<?> task = ThreadManager.ExecutorService
.submit(encapsulateSyncToAsync(methodInvocation));
return getAsyncResult(waitTime, task);
}
}
return methodInvocation.proceed();
}
XML中配置攔截器：
<bean id="timeoutInterceptor" class="org.springframework.aop.support.DefaultPointcutAdvisor">
<property name="advice" ref="timeoutAdvice" />
<property name="pointcut" ref="timeoutPointcut" />
</bean>
<bean
class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
<property name="proxyTargetClass"><!-- 基于類的代理 -->
<value>true</value>
</property>
</bean>
這樣，spring就會為你生成aop代理類實現AOP
start with .... connect by prior.....，如果prior缺省，則只能查詢符合條件的起始行，并不能遞歸
從root到末梢：select * from permissiontable t start with parentid=1 connect by prior id=parentid
從末梢到root:select * from permissiontable t start with id=32 connect by prior parentid=id
oracle中有rownum偽列，select rownum from t where rownum<3;表示取整個結果集的前2條記錄
當時如果要取分組后每個組里的前幾條記錄，則rownum無法實現，必須使用oracle里的分析函數，比如row_number()over(partition by 分組字段 order by 排序字段),實現分組后編號
select s.*
from (select row_number() over(partition by p.trader order by p.branch) rn,p.*
from spotdeal p) s
where s.rn < 3
JMM，顧名思義，java memory model。他有3個特征：原子性，可見性，有序性。
JVM系統中都有個一主存，JAVA中所有變量都是存儲在主存中，對所有線程都是共享的。
而每條線程都有自己的工作內存，工作內存中保存的是主存中某些變量的值，線程對所有變量的修改都是在工作內存中進行，線程之間無法直接互相訪問，變量的傳遞都是通過主存完成。
可見性：JMM中并發線程修改變量，必須將工作內存中的變量同步到主存后，其他線程才能訪問到
有續性：通過JAVA提供的同步機制或者volatile關鍵字 來保證內存的有序性
JAVA中保證多核系統JMM緩存一致性原則：happens-before ordering(先行發生排序）
JAVA提供了
1.synchronized關鍵字
2.volatile關鍵字
3.final關鍵字
4.同步包中的locks
5.同步包中的原子類
Session接口幾個基本操作
- 1.get()方法:先確認該ID對應的數據是否存在,先經過session緩存,再二級緩存,之后是數據庫,如果不存在,返回null
- 2.load()方法:hibernate會默認你是存在的,他會放心的使用代理類在延遲加載數據,當用到他的其他屬性時,就會跑去數據庫中查詢,如果不在,拋異常
- 3.list()方法:去數據庫讀取數據,填充緩存,
- 4.iterator()方法:先去數據庫select id from table,之后到緩存中查找,如果不存在,出現N+1問題.
緩存
- 1.一級緩存:session級緩存,如果session關閉,,清空,釋放內存
- 2.二級緩存:SessionFactory級別的全局緩存，它底下可以使用不同的緩存類庫，比如ehcache、oscache等，需要設置hibernate.cache.provider_class
- 緩存可以看成是個hastable,典型的空間換時間,一般在讀寫比高的情況下使用
Hibernate中使用二級緩存
- Class的緩存
對于一條記錄，也就是一個PO來說，是根據ID來找的，緩存的key就是ID，value是POJO。無論list，load還是iterate，只要讀出一個對象，都會填充緩存。但是list不會使用緩存，而iterate會先取數據庫select id出來，然后一個id一個id的load，如果在緩存里面有，就從緩存取，沒有的話就去數據庫load。假設是讀寫緩存，需要設置：
<cache usage=“read-write”/><緩存并發策略>
- 使用二級緩存第三方插件ehcache.jar來實現,在hibernate.cfg.xml中配置
- 如下圖:是我測試TestDAO工程的hiberante.cfg.xml配置
Hiberante.cfg.xml
ehcache.xml配置
- <defaultCache
maxElementsInMemory=“10000” //在緩存區最大元素 默認為10000；
eternal=“false” //是否永久不超時
timeToIdleSeconds=“120” // ：緩存數據的鈍化時間，也就是在一個元素消亡之前，兩次訪問時間的最大時間間隔值
timeToLiveSeconds=“120” //從創建后存活的最長時間
overflowToDisk="true" //溢出到硬盤；
/>
- 每個存儲的CLASS都要有這樣的配置,如果你沒配置,Hibernate會警告你,然后使用缺省的defaultCache
查詢緩存
- 需要配置<property name="hibernate.cache.use_query_cache">true</property>
- query.setCacheable(true);//激活查詢緩存
query.setCacheRegion(“myCacheRegion”);//指定要使用的cacheRegion,如果不做,會使用標準的查詢緩存的配置
- 查詢緩存來說，緩存的key是根據hql生成的sql，再加上參數，分頁等信息
- 重點:如果是list()方式的話，value在這里并不是整個結果集，而是查詢出來的一串ID.
- 不管是list方法還是iterate方法，第一次查詢的時候，它們的查詢方式和它們平時的方式是一樣的，list執行一條sql，iterate執行1+N條，多出來的行為是它們填充了緩存。但是到同樣條件第二次查詢的時候，就都和iterate的行為一樣了，根據緩存的key去緩存里面查到了value，value是一串id，然后在到class的緩存里面去一個一個的load出來。
- 所以說,查詢緩存需要打開相關類的class緩存。list和iterate方法第一次執行的時候，都是既填充查詢緩存又填充class緩存的,還有一點,Class緩存的時間一定要比查詢緩存長,不然還是會出現N+1問題
緩存與數據庫同步
- hibernate在一個地方維護每個表的最后更新時間，其實也就是放在上面org.hibernate.cache. UpdateTimestampsCache所指定的緩存配置里面。
-
當通過hibernate更新的時候，hibernate會知道這次更新影響了哪些表。然后它更新這些表的最后更新時間。每個緩存都有一個生成時間和這個緩存所查詢的表，當hibernate查詢一個緩存是否存在的時候，如果緩存存在，它還要取出緩存的生成時間和這個緩存所查詢的表，然后去查找這些表的最后更新時間，如果有一個表在生成時間后更新過了，那么這個緩存是無效的。
可以看出，只要更新過一個表，那么凡是涉及到這個表的查詢緩存就失效了，因此查詢緩存的命中率可能會比較低。
使用二級緩存的前置條件
- 使用hiberante的應用對數據庫具有獨占訪問權,既不能被第三方修改數據,因為那樣緩存不知道你修改了數據,無法與數據庫同步.
- 如果自己程序里使用了JDBC來更新，不通過hiberante更新,也會出現跟數據庫不同步的情況
JDK代理以前性能不怎么樣，但1.6版本卻有很大提升
/**
* 行為接口
*
* @author Administrator
*
*/
public interface Study {
public void doStudy();
}
/**
* 目標對象
*
* @author Administrator
*
*/
public class StudyImpl implements Study {
@Override
public void doStudy() {
System.out.println("study jdk proxy");
}
}
/**
* 代理類
* @author Administrator
*
*/
public class JDKProxy implements InvocationHandler {
private Study s;
public JDKProxy(Study s) {
this.s = s;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
System.out.println("before jdkproxy");
method.invoke(s, args);
System.out.println("after jdkproxy");
return null;
}
}
應用中進行調用：
public class Test {
public static void main(String[] args) throws SecurityException,
NoSuchMethodException, IllegalArgumentException,
InstantiationException, IllegalAccessException,
InvocationTargetException {
Class clazz = StudyImpl.class;//獲取目標類的Class對象
Study st = new StudyImpl();//實例化一個目標類
Class proxClass = Proxy.getProxyClass(clazz.getClassLoader(), clazz
.getInterfaces());//通過Proxy靜態方法，獲取一個于目標類實現同樣接口的Class對象，也可以說是兄弟類
Constructor c = proxClass
.getConstructor(new Class[] { InvocationHandler.class });//給這個類一個指定的公開的構造方法
Study ds = (Study) c.newInstance(new Object[] { new JDKProxy(st) });//實例化一個代理類
}
}