巷尾的酒吧

oracle 截取字符(substr)，檢索字符位置(instr) case when then else end語句使用 收藏
常用函數：substr和instr
1.SUBSTR（string,start_position,[length]）    求子字符串，返回字符串
解釋：string 元字符串
       start_position   開始位置（從0開始）
       length 可選項，子字符串的個數
For example:
substr("ABCDEFG", 0); //返回：ABCDEFG，截取所有字符
substr("ABCDEFG", 2); //返回：CDEFG，截取從C開始之后所有字符
substr("ABCDEFG", 0, 3); //返回：ABC，截取從A開始3個字符
substr("ABCDEFG", 0, 100); //返回：ABCDEFG，100雖然超出預處理的字符串最長度，但不會影響返回結果，系統按預處理字符串最大數量返回。
substr("ABCDEFG", 0, -3); //返回：EFG，注意參數-3，為負值時表示從尾部開始算起，字符串排列位置不變。

2.INSTR（string,subString,position,ocurrence）查找字符串位置
解釋：string：源字符串
      subString：要查找的子字符串
      position：查找的開始位置
      ocurrence：源字符串中第幾次出現的子字符串
For example:
INSTR('CORPORATE FLOOR','OR', 3, 2)中，源字符串為'CORPORATE FLOOR', 目標字符串為'OR'，起始位置為3，取第2個匹配項的位置；返回結果為 14 '

這個可能是最好的對比volatile 和synchronized 作用的文章了。volatile 是一個變量修飾符，而synchronized 是一個方法或塊的修飾符。所以我們使用這兩種關鍵字來指定三種簡單的存取變量的方式。

         int i1;                       int geti1() {return i1;}

volatile int i2;                        int geti2() {return i2;}

     int i3;          synchronized int geti3() {return i3;}

geti1() 在當前線程 中立即獲取在i1 變量中的值。線程可以獲得變量的本地拷貝，而所獲得的變量的值并不一定與其他線程所獲得的值相同。特別是，如果其他的線程修改了i1 的值，那么當前線程獲得的i1 的值可能與修改后的值有所差別。實際上，Java 有一種主內存的機制，使用一個主內存來保存變量當前的正確的值。線程將變量的值拷貝到自己獨立的內存中，而這些線程的內存拷貝可能與主內存中的值不同。所以實際當中可能發生這樣的情況，在主內存中i1 的值為1 ，線程1 和線程2 都更改了i1 ，但是卻沒把更新的值傳回給主內存或其他線程中，那么可能在線程1 中i1 的值為2，線程2 中i1 的值卻為 3 。

另一方面，geti2() 可以有效的從主內存中獲取i2 的值。一個volatile 類型的變量不允許線程從主內存中將變量的值拷貝到自己的存儲空間。因此，一個聲明為volatile 類型的變量將在所有的線程中同步的獲得數據，不論你在任何線程中更改了變量，其他的線程將立即得到同樣的結果。由于線程存取或更改自己的數據拷貝有更高的效率，所以volatile 類型變量在性能上有所消耗。

那么如果volatile 變量已經可以使數據在線程間同步，那么synchronizes 用來干什么呢？兩者有兩方面的不同。首先，synchronized 獲取和釋放由監聽器控制的鎖，如果兩個線程都使用一個監聽器( 即相同對象鎖) ，那么監聽器可以強制在一個時刻只有一個線程能處理代碼塊，這是最一般的同步。另外，synchronized 還能使內存同步。在實際當中，synchronized 使得所有的線程內存與主內存相同步。所以geti3() 的執行過程如下：

1.    線程從監聽器獲取對象的鎖。( 這里假設監聽器非鎖，否則線程只有等到監聽器解鎖才能獲取對象鎖)

2.    線程內存更新所有 的變量，也就是說他將讀取主內存中的變量使自己的變量保證有效。(JVM 會使用一個“臟”標志來最優化過程，使得僅僅具有“臟”標志變量被更新。詳細的情況查詢JAVA規范的17.9)

3.    代碼塊被執行( 在這個例子中，設置返回值為剛剛從主內存重置的i3 當前的值。)

4.    任何變量的變更將被寫回到主內存中。但是這個例子中geti3() 沒有什么變化。

5.    線程釋放對象的鎖給監聽器。

所以volatile 只能在線程內存和主內存之間同步一個變量的值，而synchronized 則同步在線程內存和主內存之間的所有變量的值，并且通過鎖住和釋放監聽器來實現。顯然，synchronized 在性能上將比volatile 更加有所消耗。

=============關于兩者的區別===================

1.volatile本質是在告訴jvm當前變量在寄存器（工作內存）中的值是不確定的，需要從主存中讀取；synchronized則是鎖定當前變量，只有當前線程可以訪問該變量，其他線程被阻塞住。 
2.volatile僅能使用在變量級別；synchronized則可以使用在變量、方法、和類級別的 
3.volatile僅能實現變量的修改可見性，不能保證原子性 ；而synchronized則可以保證變量的修改可見性和原子性 
4.volatile不會造成線程的阻塞；synchronized可能會造成線程的阻塞。 
5.volatile標記的變量不會被編譯器優化；synchronized標記的變量可以被編譯器優化

紅字體部分的原因如下：
線程A修改了變量還沒結束時,另外的線程B可以看到已修改的值,而且可以修改這個變量,而不用等待A釋放鎖,因為Volatile 變量沒上鎖

死鎖     死鎖是這樣一種情形：多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由于線程被無限期地阻塞，因此程序不可能正常終止。     導致死鎖的根源在于不適當地運用“synchronized”關鍵詞來管理線程對特定對象的訪問。“synchronized”關鍵詞的作用是，確保在某個時刻只有一個線程被允許執行特定的代碼塊，因此，被允許執行的線程首先必須擁有對變量或對象的排他性的訪問權。當線程訪問對象時，線程會給對象加鎖，而這個鎖導致其它也想訪問同一對象的線程被阻塞，直至第一個線程釋放它加在對象上的鎖。     由于這個原因，在使用“synchronized”關鍵詞時，很容易出現兩個線程互相等待對方做出某個動作的情形。代碼一是一個導致死鎖的簡單例子。   //代碼一 class Deadlocker {  int field_1;  private Object lock_1 = new int[1];  int field_2;  private Object lock_2 = new int[1];   public void method1(int value) {   “synchronized” (lock_1) {    “synchronized” (lock_2) {     field_1 = 0; field_2 = 0;    }   }  }   public void method2(int value) {   “synchronized” (lock_2) {    “synchronized” (lock_1) {     field_1 = 0; field_2 = 0;    }   }  } }       參考代碼一，考慮下面的過程：     ◆ 一個線程（ThreadA）調用method1()。     ◆ ThreadA在lock_1上同步，但允許被搶先執行。     ◆ 另一個線程（ThreadB）開始執行。     ◆ ThreadB調用method2()。     ◆ ThreadB獲得lock_2，繼續執行，企圖獲得lock_1。但ThreadB不能獲得lock_1，因為ThreadA占有lock_1。     ◆ 現在，ThreadB阻塞，因為它在等待ThreadA釋放lock_1。     ◆ 現在輪到ThreadA繼續執行。ThreadA試圖獲得lock_2，但不能成功，因為lock_2已經被ThreadB占有了。     ◆ ThreadA和ThreadB都被阻塞，程序死鎖。     當然，大多數的死鎖不會這么顯而易見，需要仔細分析代碼才能看出，對于規模較大的多線程程序來說尤其如此。好的線程分析工具，例如JProbe Threadalyzer能夠分析死鎖并指出產生問題的代碼位置。     隱性死鎖     隱性死鎖由于不規范的編程方式引起，但不一定每次測試運行時都會出現程序死鎖的情形。由于這個原因，一些隱性死鎖可能要到應用正式發布之后才會被發現，因此它的危害性比普通死鎖更大。下面介紹兩種導致隱性死鎖的情況：加鎖次序和占有并等待。     加鎖次序     當多個并發的線程分別試圖同時占有兩個鎖時，會出現加鎖次序沖突的情形。如果一個線程占有了另一個線程必需的鎖，就有可能出現死鎖。考慮下面的情形，ThreadA和ThreadB兩個線程分別需要同時擁有lock_1、lock_2兩個鎖，加鎖過程可能如下：     ◆ ThreadA獲得lock_1；     ◆ ThreadA被搶占，VM調度程序轉到ThreadB；     ◆ ThreadB獲得lock_2；     ◆ ThreadB被搶占，VM調度程序轉到ThreadA；     ◆ ThreadA試圖獲得lock_2，但lock_2被ThreadB占有，所以ThreadA阻塞；     ◆ 調度程序轉到ThreadB；     ◆ ThreadB試圖獲得lock_1，但lock_1被ThreadA占有，所以ThreadB阻塞；     ◆ ThreadA和ThreadB死鎖。     必須指出的是，在代碼絲毫不做變動的情況下，有些時候上述死鎖過程不會出現，VM調度程序可能讓其中一個線程同時獲得lock_1和lock_2兩個鎖，即線程獲取兩個鎖的過程沒有被中斷。在這種情形下，常規的死鎖檢測很難確定錯誤所在。     占有并等待     如果一個線程獲得了一個鎖之后還要等待來自另一個線程的通知，可能出現另一種隱性死鎖，考慮代碼二。   //代碼二 public class queue {  static java.lang.Object queueLock_;  Producer producer_;  Consumer consumer_;   public class Producer {   void produce() {    while (!done) {     “synchronized” (queueLock_) {      produceItemAndAddItToQueue();      “synchronized” (consumer_) {       consumer_.notify();      }     }    }   }    public class Consumer {    consume() {     while (!done) {      “synchronized” (queueLock_) {       “synchronized” (consumer_) {        consumer_.wait();       }       removeItemFromQueueAndProcessIt();      }     }    }   }  } }       在代碼二中，Producer向隊列加入一項新的內容后通知Consumer，以便它處理新的內容。問題在于，Consumer可能保持加在隊列上的鎖，阻止Producer訪問隊列，甚至在Consumer等待Producer的通知時也會繼續保持鎖。這樣，由于Producer不能向隊列添加新的內容，而Consumer卻在等待Producer加入新內容的通知，結果就導致了死鎖。     在等待時占有的鎖是一種隱性的死鎖，這是因為事情可能按照比較理想的情況發展—Producer線程不需要被Consumer占據的鎖。盡管如此，除非有絕對可靠的理由肯定Producer線程永遠不需要該鎖，否則這種編程方式仍是不安全的。有時“占有并等待”還可能引發一連串的線程等待，例如，線程A占有線程B需要的鎖并等待，而線程B又占有線程C需要的鎖并等待等。     要改正代碼二的錯誤，只需修改Consumer類，把wait()移出“synchronized”()即可。