【庫學(xué)科技資訊】Java 正青春:現(xiàn)狀與技術(shù)趨勢報告

本文來源于阿里技術(shù),侵刪戈次。

阿里妹導(dǎo)讀:在《Java 開發(fā)手冊》泰山版發(fā)布之際堂鲜,我們來總結(jié)思考一下 Java 的最新技術(shù)動向和未來伞芹。本文將從 JavaSE 開源現(xiàn)狀忘苛、OpenJDK 版本生態(tài)到 OpenJDK 技術(shù)趨勢三個方面講述當(dāng)前基礎(chǔ) Java 技術(shù)的現(xiàn)狀,進一步討論在云原生唱较、AI扎唾、多語言生態(tài)領(lǐng)域支撐 Java 應(yīng)用的基石——Java Virtual Machine (JVM) 技術(shù),面向未來的演進趨勢南缓。 文末福利:Java 七天學(xué)習(xí)計劃上線胸遇,學(xué) Java,領(lǐng)獎品汉形。

背景

1991 年纸镊,James Gosling 帶領(lǐng)團隊開始了一個叫"Oak"的項目,這個就是 Java 的前身概疆。1995 年逗威,Java1.0 發(fā)布〔砑剑“Write once, run anywhere"這句 Java 口號想必大家耳熟能詳凯旭。Java 剛開始出現(xiàn)的時候主要面向 Interactive Television 領(lǐng)域,直至后來幾年的發(fā)展使套,當(dāng)時的 SUN(后來在 2010 年被 Oracle 收購)一度想用 Java 來打造桌面的網(wǎng)絡(luò)操作系統(tǒng)罐呼,取代當(dāng)時如日中天的 Windows。不過 Java 后來的發(fā)展侦高,不曾想雖未在桌面領(lǐng)域內(nèi)取得多大的建樹嫉柴,出乎意料地,卻在企業(yè)級應(yīng)用領(lǐng)域開花結(jié)果奉呛,占據(jù)了如今幾乎統(tǒng)治的地位计螺。失之東隅期奔,卻收之桑榆。

JavaSE 開源現(xiàn)狀

Sun 在 2006 年的 Java One 大會上危尿,宣布 Java 技術(shù)開源呐萌,隨后 2006 年底在 GPL 協(xié)議下發(fā)布 HotSpot 以及 javac,這是 Java 發(fā)展中的里程碑事件谊娇。阿里巴巴最早在 2012 簽署 OCA肺孤,并參與到了 OpenJDK 的開發(fā)。

OpenJDK 是 JavaSE 開源的 Reference Implementation济欢。在 JavaOne 2017 的 Keynote 上 (2018 年 JavaOne 被 Oracle 重命名為 CodeOne)赠堵,Oracle 承諾將開源所有的 OracleJDK 里包含的商業(yè)實現(xiàn)功能[1]。

在 2018 年發(fā)布的 Java11法褥, Oracle 已經(jīng)讓 OpenJDK 和 Oracle JDK 兩者的二進制文件在功能上盡可能相互接近茫叭,盡管 OpenJDK 與 OracleJDK 兩者在一些選項之間仍然存在一些差異[2]。

另外半等,除了 OpenJDK 這條主線揍愁,在最近的幾年里,Java 基礎(chǔ)技術(shù)的開源有愈演愈烈趨勢:2017 年杀饵,IBM 將內(nèi)部使用 20 多年之久的 J9 虛擬機開源莽囤,并貢獻到 Eclipse Foundation, 而隨后 2018 年切距,Oracle 開源 GraalVM 1.0朽缎,其核心包含用 Java 寫的Just-in-Time compiler/Graal, SubstrateVM 以及支持多語言解釋器的 Truffle 框架。各個企業(yè)開源的主要動機谜悟,想通過開源構(gòu)建并受益于一個更為強大的語言生態(tài)系統(tǒng)话肖。

云 + 開源結(jié)合在一起,使得普通開發(fā)者以較低的門檻獲得一流工具(鏈)的使用和體驗葡幸,任何一家企業(yè)都可以像任何大型組織一樣最筒,使用的相同技術(shù)(democratizing),這是開發(fā)者的黃金時代礼患。

Java is Still Free: 你該選擇什么樣的 JDK是钥?

Java 仍然免費,但隨著 OracleJDK License 變化開始轉(zhuǎn)向收費缅叠,OpenJDK 會逐漸取代 OracleJDK 成為市場主流悄泥,這點也可以從 JVM 2020 生態(tài)報告中看出趨勢:OracleJDK 從前一年的 70% 的開發(fā)者選擇使用率降到 2020 年的 34%。

OracleJDK 收費肤粱,在客觀上也加劇了 OpenJDK 生態(tài)的碎片化趨勢弹囚,出現(xiàn)了包括 Alibaba Dragonwell 在內(nèi)的多個基于 OpenJDK 的可選實現(xiàn)。

企業(yè)在選擇使用那個 Java Vendor 的 JDK 版本時领曼,幾個方面的考慮因素可以參考:

  • 安全與穩(wěn)定:是否會及時同步上游的最新更新鸥鹉,包括安全補丁蛮穿,關(guān)鍵的問題修復(fù)等。

  • JavaSE 標(biāo)準(zhǔn)兼容 :是否與標(biāo)準(zhǔn) Java 兼容毁渗。

  • 性能與效率:是否可以在問題診斷践磅,性能調(diào)優(yōu)方面提供有效的工具支持,幫助一線的開發(fā)同學(xué)高效地解決 Java 問題灸异。在 JVM府适,到 JDK (Class library) 層面,是否有面向企業(yè)業(yè)務(wù)場景的優(yōu)化特性肺樟,可以幫助提升資源的利用率檐春,生產(chǎn)系統(tǒng)的穩(wěn)定性等等。

  • 快速的新技術(shù)采納:伴隨收費么伯,Oracle 管理 Java 版本生命周期采用了 Long Term Support(LTS) 的概念疟暖,Oracle 每三年會指定一個 LTS 的 Java 版本, Java 8/11 都是 LTS 版本田柔。大部分企業(yè)俐巴,尤其是大中型企業(yè)很難跟上 Java 每六個月一發(fā)布的節(jié)奏,像 Java 12凯楔,13 這樣的 Feature Release(FR) 版本窜骄。那么問題來了,如果你選擇 Stay 在 LTS 版本上摆屯,比如 Java 11,在新版本 (Java11+) 發(fā)布的 JVM/JDK 技術(shù)糠亩,是否可以在不升級的情況下虐骑,提前享受這些技術(shù)紅利?

這里分享下 Alibaba Dragonwell 在這些方面的計劃與思考赎线。

Alibaba Dragonwell 是阿里巴巴內(nèi)部廣泛使用的 AJDK (AlibabaJDK) 的開源版本廷没,Alibaba Dragonwell 作為基石,支撐了阿里經(jīng)濟體內(nèi)幾乎所有的 Java 業(yè)務(wù)垂寥,經(jīng)過了雙 11 等大促的考驗颠黎。Alibaba Dragonwell 主要針對的場景是數(shù)據(jù)中心大規(guī)模 Java 應(yīng)用部署情況下,Java 應(yīng)用穩(wěn)定性滞项、效率以及性能的優(yōu)化與提高狭归。

2019 年 3 月阿里開源 Alibaba Dragonwll 8.0.0,我們也一直正在踐行開源時候的承諾文判,AJDK 內(nèi)部使用的特性在逐步開源过椎。到剛剛發(fā)布 Alibaba Dragonwell 8.3.3,我們已經(jīng)開源了 JWarmup戏仓,ElasticHeap疚宇,多租戶亡鼠,JFR 等眾多功能,協(xié)程 Wisp 2.0敷待,GCIH 等也在開源的規(guī)劃上间涵。

同時,Alibaba Dragonwell 作為 OpenJDK 的下游榜揖,每個發(fā)行版都會同步上游最新更新浑厚,包括安全更新,問題修復(fù)等根盒,并經(jīng)過阿里內(nèi)部大規(guī)模的應(yīng)用集群測試钳幅。

在新技術(shù) Adoption 方面,Alibaba Dragonwell 目前發(fā)布和維護了 Java 8,11 兩個 LTS 版本炎滞,阿里 JVM 團隊會根據(jù)實際業(yè)務(wù)狀況敢艰,移植 Java11+ 的相關(guān)功能到 Java 8 和 11 兩個版本,這樣 Alibaba Dragonwell 用戶可以在不跟進 Java 12,13 等這些 FR 版本的情況下册赛,提前享受這些功能帶來的技術(shù)紅利钠导。

OpenJDK技術(shù)趨勢

縱觀 Java 技術(shù) 20 多年的發(fā)展,始終圍繞著兩大主題:Productivity 以及 Performance森瘪。在很多情況下牡属,Java 在設(shè)計上 Productivity 是優(yōu)于 Performance 考慮的。Java 引入的 Garbage Collector 把程序員從復(fù)雜的內(nèi)存管理中解脫出來扼睬,但在另一方面 Java 應(yīng)用始終困擾于 GC 暫停時間的影響逮栅。Java 基于棧式虛擬機的中間字節(jié)碼設(shè)計,很好地抽象了不同平臺 (Intel, ARM 等) 的差異性窗宇,同時通過 Just-in-Time (JIT) 編譯技術(shù)措伐,解決的 Java 應(yīng)用 peak 性能, 但在另一方面 JIT 不可避免引入了 Warmup 的代價,正常情況下 Java 程序永遠(yuǎn)需要先 load class军俊,解釋執(zhí)行侥加,然后再到高度優(yōu)化的代碼執(zhí)行。

如果從 JVM 視角來總結(jié)梳理下目前 OpenJDK 社區(qū)正在發(fā)生粪躬,孵化的相關(guān)技術(shù)担败,主要從工具,GC镰官,編譯器提前,以及 Runtime 四個方面進行一個主要概括:

JFR/JMC

Oracle 從 Java 11 開源了其之前一直作為商業(yè)功能的 JFR,JFR 是功能強大的 Java 應(yīng)用問題診斷與性能剖析工具朋魔。阿里巴巴也是作為主要的貢獻者岖研,與社區(qū)包括 RedHat 等,一起將 JFR 移植到了 OpenJDK 8, 預(yù)計 2020 年 7 月即將發(fā)布的 OpenJDK 8u262 (Java8) 將會默認(rèn)帶有 JFR 功能孙援,這樣 Java 8 的用戶可以基于這個版本免費使用 JFR 功能害淤。

ZGC/Shandoath

無論是 Oracle 在 Java 11 發(fā)布的 ZGC,還是 RedHat 已經(jīng)做了好幾年的 Shandoath拓售,都實現(xiàn)了 concurrent copy GC窥摄,解決 Large Heap 情況下的 GC 停機性能。ZGC 最新狀態(tài)础淤,在 9 月份即將發(fā)布的 JDK 15崭放,ZGC 將從 Experimental 功能變?yōu)樯a(chǎn)可用 [3] 。實際上鸽凶,在 AJDK 11 上币砂,阿里巴巴團隊 JVM 團隊已經(jīng)做了大量 Java 11+ 到 Java 11 的 ZGC 移植工作,以及相關(guān)問題修復(fù)玻侥,2019 年雙 11 和阿里數(shù)據(jù)庫團隊一起决摧,讓數(shù)據(jù)庫應(yīng)用運行在 ZGC 上,100+ GB Heap 情況下 GC 暫停時間可以保持在 <10ms 以內(nèi)凑兰, 詳細(xì)討論參考[4]掌桩。

Graal

用 Java 開發(fā)的新一代 Just-in-Time 編譯技術(shù),用來替代目前 HostSot JVM 的 C1/C2 編譯器姑食,OpenJDK 上的 Ahead-of-Time (AOT) 技術(shù)也是基于 Graal 編譯器開發(fā)波岛。

Loom

OpenJDK 社區(qū)協(xié)程項目,對應(yīng)于 AJDK 的 Wisp 2.0 實現(xiàn)音半,詳細(xì)討論可以參考[5]则拷。

進擊的 Java:面向未來演進

2020,站在一個全新的節(jié)點上祟剔,本文也從三個大的方面 Cloud Native隔躲, AI,以及多語言生態(tài)三個方面展望下未來的發(fā)展物延,有些討論本身是超越 Java 本身的。

面向 Cloud Native 的語言進化

云原生時代仅父,軟件的交付方式發(fā)生的根本性變化叛薯。以 Java 為例,在之前 Java 開發(fā)者交付的是應(yīng)用本身腿倚,具體體現(xiàn)在以 "jar", "war" 的形式交付, 而云原生則是以 Container 為交付單位的:

image

在運行方面星瘾,面向 Cloud Native 的應(yīng)用要求:

  • Reactive

  • Always Watching

  • Extreme low memory footprint

  • Quick boot time

Java 語言作為企業(yè)計算昆著,互聯(lián)網(wǎng)領(lǐng)域的王者,擁有一致性抖拴,豐富的構(gòu)建在 Java 語言之上的生態(tài)系統(tǒng), 豐富的三方庫,多樣的 Serviceability 支持等阿宅,隨著云時代應(yīng)用微服務(wù)化候衍,Serverless,這些新的架構(gòu)逐漸觸及到了 Java 程序速度提升的天花板 —— Java 自身的啟動運行開銷洒放。

在 Cloud Native 這個新的上下文里蛉鹿, 我們談?wù)撜Z言的進化,絕不僅僅限于運行時往湿,編譯器層面妖异, 新的計算形態(tài)一定伴隨著編程模型的變革,這涉及圍繞程序語言的 Library领追,F(xiàn)ramework他膳,Tools 等一系列配套的改革。從目前業(yè)界來看绒窑,也有不少的項目正在發(fā)生:配合 GraalVM/SVM (Java 靜態(tài)編譯技術(shù)) 的下一代編程框架 Quarkus, Micronaut, 以及 Helidon棕孙,Quarkus 更是提出了“container first” ,他們提倡的分層的 lightweight uber-jar 的概念正是符合了 container 交付這一趨勢回论。而 Red Hat 的 Java 團隊與 OS 團隊合作的"Checkpoint Restore Fast Start-up"技術(shù) (AZul 在 JVM 技術(shù)峰會 '2019 上也提出過類似的想法) 則是在更加底層的技術(shù)棧上解決 Java 快速拉起問題散罕。

在 Java for Cloud Native 方向,我們也開展了相關(guān)研發(fā)工作傀蓉。Java 是靜態(tài)語言欧漱,但是包含了大量的動態(tài)特性,包括反射葬燎,Class Loading误甚,Bytecode Instrument (BCI) 等等,這些動態(tài)特性本質(zhì)上都是違反 GraalVM/SVM 所要求的 Closed-World Assumption (CWA) 原則谱净,這也是導(dǎo)致傳統(tǒng)跑在 JVM 的 Java 應(yīng)用不容易在 SVM 編譯運行的主要原因窑邦。阿里巴巴 JVM 團隊對 AJDK 做了靜態(tài)化裁剪,務(wù)求在 Java 靜/動態(tài)特性之間找到一個確定的邊界壕探,從 JDK 的層面為 Java 靜態(tài)編譯提供可能性冈钦。同時向上,與螞蟻中間團隊合作李请,定義面向靜態(tài)編譯的 Java 編程模型瞧筛,通過編程框架來約束 - Java 應(yīng)用的開發(fā)是面向靜態(tài)編譯友好的。我們靜態(tài)編譯了基于螞蟻開源中間件 SOFAStack 構(gòu)建的服務(wù)注冊中心 Meta 節(jié)點應(yīng)用导盅,相較于傳統(tǒng) 的運行在 JVM上较幌,性能有量級的提升:服務(wù)啟動時間降低了 17 倍,可執(zhí)行文件大小降低了 3.4 倍白翻,運行時內(nèi)存降低了一半乍炉。詳見[6]。

AI 的興起,編程語言異構(gòu)計算的新挑戰(zhàn)

2005 年岛琼,時任 Intel CTO 的 Justin Rattner底循,說過 “We are at the cusp of a transition to multicore, multithreaded architectures”, 在前后的十幾年中衷恭, 編程語言與編譯器領(lǐng)域一直在努力面向 parallel architectural paradigm 做優(yōu)化探索此叠。隨著 AI這些年的興起, 不同的時間節(jié)點随珠,相似的場景灭袁,面向 FPGA/GPU 異構(gòu)計算場景,對編程語言與編譯器領(lǐng)域提出了新的挑戰(zhàn)窗看。

除了傳統(tǒng) Compiler 諸如 IBM XL Compilers, Intel Compilers 等做的 Automatic Parallelizing 工作茸歧,在極致性能探索方面,基于多面體模型 (polytope model) 的編譯優(yōu)化技術(shù)作為解決程序并行化显沈、數(shù)據(jù)局部性優(yōu)化的一種手段软瞎,成為編譯優(yōu)化領(lǐng)域的研究熱點。

而在 Parallel Languages 層面拉讯,對 C&C++ 開發(fā)人員涤浇,CUDA 的出現(xiàn)降低了 GPU 的編程門檻,但 GPU 和 CPU 兩種硬件模型本質(zhì)區(qū)別魔慷,導(dǎo)致過高的開發(fā)成本只锭,需要學(xué)習(xí)和了解更多底層硬件細(xì)節(jié),還更不用說更高級語言的開發(fā)語言像 Java 等所面臨的底層硬件模型與高級語言之間巨大的 GAP院尔。

在 Java 領(lǐng)域蜻展,最早在 JVM 技術(shù)峰會 '2014,AMD 曾經(jīng)分享過他們的 Sumatra 項目邀摆,嘗試實現(xiàn) JVM 與 Heterogeneous System Architecture 目標(biāo)硬件交互纵顾。而在最近,由 The University of Manchester 發(fā)起的 TornadoVM 項目栋盹,實現(xiàn)包含:一個 Just-in-Time 編譯施逾,支持從 Java bytecode 到 OpenCL 的映射,一個優(yōu)化的運行時引擎例获,以及可以保持 Java 堆和異構(gòu)設(shè)備堆內(nèi)存一致性的內(nèi)存管理器音念。TornadoVM 的目標(biāo)是開發(fā)人員不需要了解 GPU 編程語言或者相關(guān)的 GPU 體系結(jié)構(gòu)知識就可以編寫面向異構(gòu)的并行程序。TornadoVM 可以透明地運行在 AMD GPUs, NVIDIA GPUs, Intel integrated GPUs 以及 multi-core CPUs 上躏敢。

在通用 CPU 領(lǐng)域, OpenJDK 社區(qū)的 Vector API 項目 (Panama 的子項目)整葡,依賴 CPU 的 SIMD 指令件余,獲得計算性能的成倍提升,Vector API 在大數(shù)據(jù),AI 計算也有非常廣的應(yīng)用場景啼器。阿里 JVM 團隊把 Vector API 移植到了 AJDK 11旬渠,后續(xù)會開源到 Alibaba Dragonwell,分享下我們獲得的基礎(chǔ)性能數(shù)據(jù):

時間 (單位: milliseconds) 越短端壳,性能越好

Polyglot Programing告丢,鏈接多語言生態(tài)

Polyglot Programming 并不是一個新的概念。在 Managed Runtime 領(lǐng)域损谦, 2017 年 IBM 開源 Open Managed Runtime(OMR), 以及 2018 年 Oracle 開源 Truffle/Graal 技術(shù)岖免。OMR 和 Graal 技術(shù)讓開發(fā)人員實現(xiàn)一個新的語言成本大幅下降。前者 OMR 以 C照捡、C++ 組件的形式提供了 Garbage Collection (GC), Just-in-Time (JIT) 以及 Reliability, availability and serviceability (RAS颅湘,工具)等, 開發(fā)人員可以依賴這些組件,通過 'glue' 的方式基于這些組件實現(xiàn)自己的高性能語言栗精。而后者 Truffle/Graal, Truffle 是一個依賴 AST parser 實現(xiàn)新的語言的 Java 框架闯参,本質(zhì)上是將你的新的語言映射到 JVM 世界。不同于 Scala, JRuby 這些圍繞 JVM 生態(tài)本身構(gòu)建的語言悲立,他們本質(zhì)是還是 Java鹿寨, 無論是 OMR, 還是 Truffle/Graal薪夕,他們都提供了生產(chǎn)級的 GC脚草,JIT,以及 RAS 服務(wù)支持寥殖,新開發(fā)的語言完全不需要再重新實現(xiàn)這些底層技術(shù)玩讳。

從業(yè)界來看,面向特定領(lǐng)域的 Domain Specific Language (DSL) 語言已經(jīng)有向這些技術(shù)遷移的趨勢嚼贡,高盛正在與 Graal 社區(qū)合作熏纯,把他們的 DSL 遷移到 Graal 上。另外 Ruby/OMR, Python/Graal粤策, JS/Graal樟澜,WASM/Graal 等這些真正鏈接不同語言生態(tài)的項目,也正在迅速發(fā)展起來叮盘。

回到 AJDK秩贰, Graal 已經(jīng)在 AJDK 8 開始支持, JS/Graal 這樣成熟的技術(shù)柔吼,已經(jīng)在阿里內(nèi)部業(yè)務(wù)上線毒费。

最后
Java 是一項二十多年前被發(fā)明出來的技術(shù),她歷經(jīng)磨難愈魏,幾易其主觅玻,但卻歷久彌新想际。這篇報告旨在為 Java 的開發(fā)者們梳理下目前的 Java 技術(shù)現(xiàn)狀,以及討論在云溪厘,AI 等這些重要領(lǐng)域內(nèi) Java 技術(shù)的演進趨勢胡本。在介紹的相關(guān)部分,我們也穿插了阿里的一些工程實踐畸悬。作為世界上最大的 Java 用戶之一侧甫,我們也一直在探索把前沿的 Java 技術(shù),通過在阿里豐富的業(yè)務(wù)場景的試驗蹋宦,真正把這些技術(shù)應(yīng)用于真實的生產(chǎn)環(huán)境披粟。我們也非常樂于分享和貢獻 Java 領(lǐng)域的經(jīng)驗、實踐與技術(shù)洞見妆档,包括明天即將發(fā)布的《Java 開發(fā)手冊》僻爽,共同促進 Java 的發(fā)展。

參考

[1]https://www.infoq.com/news/2017/10/javaone-opening/
[2]https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#Diffs
[3]https://openjdk.java.net/jeps/377
[4]https://mp.weixin.qq.com/s/FQpvT5wIy9xwhX2jHMU7aw
[5]https://mp.weixin.qq.com/s/K1us6aH-gjHsWGhQ3SulFg
[6]https://www.infoq.cn/article/uzHpEbpMwiYd85jYslka

image

End


庫學(xué)科技成立于2009年贾惦,是一家綜合性的互聯(lián)網(wǎng)公司胸梆,公司總部在北京大興區(qū),公司的主要業(yè)務(wù)涉互聯(lián)網(wǎng)軟件開發(fā)须板,數(shù)據(jù)庫碰镜、人工智能、新媒體運營等領(lǐng)域习瑰,主要是為國內(nèi)的中大型互聯(lián)網(wǎng)公司绪颖,提供技術(shù)人員的定向入職輸送,與國內(nèi)大型企業(yè)做聯(lián)合定崗招聘甜奄,與崗位需求相結(jié)合通過短期實訓(xùn)達到企業(yè)崗位要求的合格的工程師柠横。。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末课兄,一起剝皮案震驚了整個濱河市牍氛,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌烟阐,老刑警劉巖搬俊,帶你破解...
    沈念sama閱讀 222,590評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異蜒茄,居然都是意外死亡唉擂,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,157評論 3 399
  • 文/潘曉璐 我一進店門檀葛,熙熙樓的掌柜王于貴愁眉苦臉地迎上來玩祟,“玉大人,你說我怎么就攤上這事屿聋÷汛眨” “怎么了庆聘?”我有些...
    開封第一講書人閱讀 169,301評論 0 362
  • 文/不壞的土叔 我叫張陵,是天一觀的道長勺卢。 經(jīng)常有香客問我,道長象对,這世上最難降的妖魔是什么黑忱? 我笑而不...
    開封第一講書人閱讀 60,078評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮勒魔,結(jié)果婚禮上甫煞,老公的妹妹穿的比我還像新娘。我一直安慰自己冠绢,他們只是感情好抚吠,可當(dāng)我...
    茶點故事閱讀 69,082評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著弟胀,像睡著了一般楷力。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上孵户,一...
    開封第一講書人閱讀 52,682評論 1 312
  • 那天萧朝,我揣著相機與錄音,去河邊找鬼夏哭。 笑死检柬,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的竖配。 我是一名探鬼主播何址,決...
    沈念sama閱讀 41,155評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼进胯!你這毒婦竟也來了用爪?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 40,098評論 0 277
  • 序言:老撾萬榮一對情侶失蹤龄减,失蹤者是張志新(化名)和其女友劉穎项钮,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體希停,經(jīng)...
    沈念sama閱讀 46,638評論 1 319
  • 正文 獨居荒郊野嶺守林人離奇死亡烁巫,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,701評論 3 342
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了宠能。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片亚隙。...
    茶點故事閱讀 40,852評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖违崇,靈堂內(nèi)的尸體忽然破棺而出阿弃,到底是詐尸還是另有隱情诊霹,我是刑警寧澤,帶...
    沈念sama閱讀 36,520評論 5 351
  • 正文 年R本政府宣布渣淳,位于F島的核電站脾还,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏入愧。R本人自食惡果不足惜鄙漏,卻給世界環(huán)境...
    茶點故事閱讀 42,181評論 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望棺蛛。 院中可真熱鬧怔蚌,春花似錦、人聲如沸旁赊。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,674評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽终畅。三九已至籍胯,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間声离,已是汗流浹背芒炼。 一陣腳步聲響...
    開封第一講書人閱讀 33,788評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留术徊,地道東北人本刽。 一個月前我還...
    沈念sama閱讀 49,279評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像赠涮,于是被迫代替她去往敵國和親子寓。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,851評論 2 361