91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

JDK時區TimeZone與操作系統不一致怎么辦

發布時間:2021-12-17 14:07:43 來源:億速云 閱讀:378 作者:小新 欄目:編程語言

這篇文章主要介紹JDK時區TimeZone與操作系統不一致怎么辦,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!

【背景】一臺Windows服務器的遷移工作,涉及操作系統、應用以及數據庫,其中:
  1.操作系統由Windows Server 2003--->Windows Server 2008
  2.數據庫:Oracle 10.2.0.4--->Oracle 11.2.0.3
  3.應用遷移本在本篇博文的討論范圍
 之前方案經過幾輪評審,該改進地方修改了多次。測試環境也進行了多次測試。自認為在生產環境變更會一切順利,萬無一失,自信滿滿,但很快被現實狠狠的抽了一巴掌。經梳理,碰到的問題主要有兩個,以下計劃分兩篇進行總結歸納,若有錯誤,歡迎各位大神指正。
  服務器遷移完成后,啟動定時作業出現了一個異常現象,該作業理應生成T-1日文件不知為何文件變成了T-2日。出現問題的時候,開發人員并不在現場,本著先不麻煩別人的原則。第一反應就是有可能是數據庫遷移造成的。
 為排除數據庫方面的問題,我們查詢了常用時間變量sysdate,systimestamp,localtimestamp以及current_timestamp,發現輸出都和自然時間相同。

  1. SELECT sysdate FROM dual;

  2. SYSDATE

  3. -----------------

  4. 20170409 07:56:19


  5. SELECT systimestamp FROM dual;

  6. SYSTIMESTAMP

  7. ---------------------------------------------------------------------------

  8. 09-APR-17 07.56.52.311941 AM +08:00


  9. SELECT localtimestamp FROM dual;

  10. LOCALTIMESTAMP

  11. ---------------------------------------------------------------------------

  12. 09-APR-17 07.59.04.507493 AM


  13. SELECT current_timestamp FROM dual;

  14. CURRENT_TIMESTAMP

  15. ---------------------------------------------------------------------------

  16. 09-APR-17 07.59.17.414758 AM +08:00

  那看來和數據庫無關?正在猶豫的時候,再次啟動定時作業的時候發現執行結果正確了,生成了T-1日的文件,且文件內容也無異常。奇怪,不過定時作業總算執行正常了,由于有其他事情要忙,這個事情就沒有再深入分析。
  悲催的是,第二天問題又重現了,且情況和前一天幾乎一樣:剛開始作業異常,分析了一段時間,再次重啟作業又正常了。什么情況?看來這個不是偶發現象,要仔細深入的研究個明白了。在分析過程我們發現了一個非常有趣的現象:作業若在8點之前執行就會異常,一過8點作業執行正常。難道是時區造成的?不對啊,前面已經查詢已經確認了,數據庫時區和時間都沒問題。為了進一步確認數據庫時區正常,還是查看一下dbtimezone變量吧。

點擊(此處)折疊或打開

  1. SELECT dbtimezone FROM dual;

  2. DBTIME

  3. ------

  4. +08:00

   基本排查了數據庫的原因造成的,作為DBA的我不禁松了一口氣。下面的分析可以放松些了,不用提心吊膽啦,哈哈。既然懷疑時區造成的,那看看是不是操作系統的時區問題。但非常遺憾經確認操作系統時區設置也是正確的 :東8區。經過一番確認和排查,始終未發現服務器、數據庫參數設置的問題,找開發要代碼吧。代碼非常簡單,截取部分有用內容如下:

點擊(此處)折疊或打開

  1. String strCreDate = new java.sql.Date(new java.util.Date().getTime()-86400000).toString();

   具體生成T-1日還是T-2日的文件,由strCreDate變量決定的。那看來變量strCreDate的值有問題。我們分別做了一組實驗:8點前strCreDate的值為T-2,但8點后該值就變成了T-1.為清楚的看到JDK時區情況,寫了一個非常簡單HelloWorld代碼,如下: 

點擊(此處)折疊或打開

  1. import java.util.TimeZone;

  2. import java.sql.Date;

  3. public class HelloWorld {

  4.     public static void main(String[] args) {

  5.     System.out.print("當前的默認時區為");

  6.     System.out.println(TimeZone.getDefault());                            //輸出當前默認時區 

  7.     final TimeZone zone = TimeZone.getTimeZone("GMT+8");                  //獲取中國時區

  8.     TimeZone.setDefault(zone);                                            //設置時區

  9.     System.out.println(TimeZone.getDefault());                            //輸出驗證 

  10.     }

  11. }

   第一個輸出結果為:
JDK時區TimeZone與操作系統不一致怎么辦
 第二個輸出結果為:
JDK時區TimeZone與操作系統不一致怎么辦
    發現了什么了嗎?雖然操作系統的時區為東8區,但是jdk獲取的時區不是東8區,缺是UTC,因此造成了差8個小時的現象,即8點前作業異常,8點后作業又正常了。問題已經找出來了,就是jdk的問題,解決方案就迎刃而解了。具體辦法如下:
 在下面四個目錄(Java\jre6\lib\zi\Etc、Java\jre6\lib\zi、Java\jdk1.6.0_18\jre\lib\zi\Etc、Java\jdk1.6.0_18\jre\lib\zi)下找到GMT文件備份一下,然后復制一份GMT-8并重命名為GMT,復制完畢,重新運行一下java程序問題即可解決!
    按照上述方法處理后,再次運行HelloWorld命令,輸出正常了。次日觀察作業也正常了。至此問題處理完畢。

以上是“JDK時區TimeZone與操作系統不一致怎么辦”這篇文章的所有內容,感謝各位的閱讀!希望分享的內容對大家有幫助,更多相關知識,歡迎關注億速云行業資訊頻道!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

jdk
AI

铜梁县| 黎川县| 黄平县| 封开县| 广河县| 河间市| 若羌县| 江油市| 砀山县| 海宁市| 苗栗县| 惠安县| 米林县| 云霄县| 江津市| 太原市| 云龙县| 额尔古纳市| 昭平县| 城市| 寻乌县| 夏河县| 沁源县| 永丰县| 湖南省| 衡阳市| 星子县| 太康县| 荥阳市| 阳春市| 渑池县| 武夷山市| 镇宁| 华蓥市| 仁怀市| 沂水县| 无锡市| 普定县| 台东县| 蕲春县| 莫力|