JVM系列:(4)JVM參數(shù)優(yōu)化

不管是YGC還是FGC,GC過程中都會對導(dǎo)致程序運行中斷,正確選擇不同的GC策略,調(diào)整GC的參數(shù)可以極大減少由于GC導(dǎo)致的程序運行中斷玉凯，從而提高Java程序的效率。然而調(diào)整GC參數(shù)是一個極為復(fù)雜的過程，由于各類程序具有不同的特點，如：web和GUI程序就有很大區(qū)別（Web可以適當(dāng)?shù)耐ｎD，但GUI停頓是客戶無法接受的）焚鲜，另外機器配置不同（主要cup個數(shù)，內(nèi)存不同）放前，使用的GC配置也會不同本文將注重介紹JVM忿磅、GC的一些重要參數(shù)的設(shè)置來提高系統(tǒng)的性能。

本文對應(yīng)GitHub: https://github.com/hbulpf/JavaPrinciple

JVM的基本參數(shù)

參數(shù)名稱 含義 默認(rèn)值
-Xms 初始堆大小 物理內(nèi)存的1/64(<1GB) 默認(rèn)(MinHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存小于40%時凭语，JVM就會增大堆直到-Xmx的最大限制.
-Xmx 最大堆大小 物理內(nèi)存的1/4(<1GB) 默認(rèn)(MaxHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存大于70%時葱她，JVM會減少堆直到 -Xms的最小限制
-Xmn 年輕代大小 注意：此處的大小是（eden+2*survivor space).與jmap -heap中顯示的New gen是不同的。 整個堆大小=年輕代大小 + 年老代大小 + 持久代大小. 持久代一般固定大小為 64m,增大年輕代后,將會減小年老代大小.此值對系統(tǒng)性能影響較大,Sun官方推薦配置為整個堆的3/8
-XX:NewSize 設(shè)置年輕代大小
-XX:MaxNewSize 年輕代最大值
-XX:PermSize 設(shè)置持久代(perm gen)初始值 物理內(nèi)存的1/64
-XX:MaxPermSize 設(shè)置持久代最大值 物理內(nèi)存的1/4 持久代一般固定大小為 64m
-Xss 每個線程的堆棧大小 JDK5.0以后每個線程堆棧大小為1M,以前每個線程堆棧大小為256K.更具應(yīng)用的線程所需內(nèi)存大小進(jìn)行 調(diào)整.在相同物理內(nèi)存下,減小這個值能生成更多的線程.但是操作系統(tǒng)對一個進(jìn)程內(nèi)的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗值在3000~5000左右 一般小的應(yīng)用似扔， 如果棧不是很深吨些， 應(yīng)該是128k夠用的 大的應(yīng)用建議使用256k。這個選項對性能影響比較大炒辉，需要嚴(yán)格的測試豪墅。（校長） 和threadstacksize選項解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"” -Xss is translated in a VM flag named ThreadStackSize” 一般設(shè)置這個值就可以了。
-XX:ThreadStackSize Thread Stack Size (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio 年輕代(包括Eden和兩個Survivor區(qū))與年老代的比值(除去持久代) -XX:NewRatio=4表示年輕代與年老代所占比值為1:4,年輕代占整個堆棧的1/5 Xms=Xmx并且設(shè)置了Xmn的情況下黔寇，該參數(shù)不需要進(jìn)行設(shè)置偶器。
-XX:SurvivorRatio Eden區(qū)與Survivor區(qū)的大小比值 設(shè)置為8,則兩個Survivor區(qū)與一個Eden區(qū)的比值為2:8,一個Survivor區(qū)占整個年輕代的1/10
-XX:LargePageSizeInBytes 內(nèi)存頁的大小不可設(shè)置過大， 會影響Perm的大小 =128m
-XX:+UseFastAccessorMethods 原始類型的快速優(yōu)化
-XX:+DisableExplicitGC 關(guān)閉System.gc() 這個參數(shù)需要嚴(yán)格的測試
-XX:MaxTenuringThreshold 垃圾最大年齡 如果設(shè)置為0的話,則年輕代對象不經(jīng)過Survivor區(qū),直接進(jìn)入年老代. 對于年老代比較多的應(yīng)用,可以提高效率.如果將此值設(shè)置為一個較大值,則年輕代對象會在Survivor區(qū)進(jìn)行多次復(fù)制,這樣可以增加對象再年輕代的存活 時間,增加在年輕代即被回收的概率 該參數(shù)只有在串行GC時才有效.
-XX:+AggressiveOpts 加快編譯
-XX:+UseBiasedLocking 鎖機制的性能改善
-Xnoclassgc 禁用垃圾回收
-XX:SoftRefLRUPolicyMSPerMB 每兆堆空閑空間中SoftReference的存活時間 1s softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold 對象超過多大是直接在舊生代分配 0 單位字節(jié) 新生代采用Parallel Scavenge GC時無效 另一種直接在舊生代分配的情況是大的數(shù)組對象,且數(shù)組中無外部引用對象.
-XX:TLABWasteTargetPercent TLAB占eden區(qū)的百分比 1%
-XX:+CollectGen0First FullGC時是否先YGC false

并行收集器相關(guān)參數(shù)

參數(shù)名稱 含義 默認(rèn)值
-XX:+UseParallelGC Full GC采用parallel MSC (此項待驗證) 選擇垃圾收集器為并行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用并發(fā)收集,而年老代仍舊使用串行收集.(此項待驗證)
-XX:+UseParNewGC 設(shè)置年輕代為并行收集 可與CMS收集同時使用 JDK5.0以上,JVM會根據(jù)系統(tǒng)配置自行設(shè)置,所以無需再設(shè)置此值
-XX:ParallelGCThreads 并行收集器的線程數(shù) 此值最好配置與處理器數(shù)目相等 同樣適用于CMS
-XX:+UseParallelOldGC 年老代垃圾收集方式為并行收集(Parallel Compacting) 這個是JAVA 6出現(xiàn)的參數(shù)選項
-XX:MaxGCPauseMillis 每次年輕代垃圾回收的最長時間(最大暫停時間) 如果無法滿足此時間,JVM會自動調(diào)整年輕代大小,以滿足此值.
-XX:+UseAdaptiveSizePolicy 自動選擇年輕代區(qū)大小和相應(yīng)的Survivor區(qū)比例 設(shè)置此選項后,并行收集器會自動選擇年輕代區(qū)大小和相應(yīng)的Survivor區(qū)比例,以達(dá)到目標(biāo)系統(tǒng)規(guī)定的最低相應(yīng)時間或者收集頻率等,此值建議使用并行收集器時,一直打開.
-XX:GCTimeRatio 設(shè)置垃圾回收時間占程序運行時間的百分比 公式為1/(1+n)
-XX:+ScavengeBeforeFullGC Full GC前調(diào)用YGC true Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS相關(guān)參數(shù)

參數(shù)名稱 含義 默認(rèn)值
-XX:+UseConcMarkSweepGC 使用CMS內(nèi)存收集 測試中配置這個以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此時年輕代大小最好用-Xmn設(shè)置.???
-XX:+AggressiveHeap 試圖是使用大量的物理內(nèi)存 長時間大內(nèi)存使用的優(yōu)化缝裤，能檢查計算資源（內(nèi)存屏轰， 處理器數(shù)量） 至少需要256MB內(nèi)存 大量的CPU／內(nèi)存， （在1.4.1在4CPU的機器上已經(jīng)顯示有提升）
-XX:CMSFullGCsBeforeCompaction 多少次后進(jìn)行內(nèi)存壓縮 由于并發(fā)收集器不對內(nèi)存空間進(jìn)行壓縮,整理,所以運行一段時間以后會產(chǎn)生"碎片",使得運行效率降低.此值設(shè)置運行多少次GC以后對內(nèi)存空間進(jìn)行壓縮,整理.
-XX:+CMSParallelRemarkEnabled 降低標(biāo)記停頓
-XX+UseCMSCompactAtFullCollection 在FULL GC的時候憋飞， 對年老代的壓縮 CMS是不會移動內(nèi)存的霎苗， 因此， 這個非常容易產(chǎn)生碎片榛做， 導(dǎo)致內(nèi)存不夠用唁盏， 因此内狸， 內(nèi)存的壓縮這個時候就會被啟用。 增加這個參數(shù)是個好習(xí)慣厘擂。 可能會影響性能,但是可以消除碎片
-XX:+UseCMSInitiatingOccupancyOnly 使用手動定義初始化定義開始CMS收集 禁止hostspot自行觸發(fā)CMS GC
-XX:CMSInitiatingOccupancyFraction=70 使用cms作為垃圾回收 使用70％后開始CMS收集 92 為了保證不出現(xiàn)promotion failed(見下面介紹)錯誤,該值的設(shè)置需要滿足以下公式CMSInitiatingOccupancyFraction計算公式
-XX:CMSInitiatingPermOccupancyFraction 設(shè)置Perm Gen使用到達(dá)多少比率時觸發(fā) 92
-XX:+CMSIncrementalMode 設(shè)置為增量模式 用于單CPU情況
-XX:+CMSClassUnloadingEnabled

輔助信息

參數(shù)名稱 含義 默認(rèn)值
-XX:+PrintGC 輸出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails 輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps
-XX:+PrintGC:PrintGCTimeStamps 可與-XX:+PrintGC -XX:+PrintGCDetails混合使用 輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime 打印垃圾回收期間程序暫停的時間.可與上面混合使用 輸出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime 打印每次垃圾回收前,程序未中斷的執(zhí)行時間.可與上面混合使用 輸出形式:Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC 打印GC前后的詳細(xì)堆棧信息
-Xloggc:filename 把相關(guān)日志信息記錄到文件以便分析. 與上面幾個配合使用
-XX:+PrintClassHistogram garbage collects before printing the histogram.
-XX:+PrintTLAB 查看TLAB空間的使用情況
XX:+PrintTenuringDistribution 查看每次minor GC后新的存活周期的閾值 Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7答倡，新的存活周期的閾值為7。

GC性能的考慮

對于GC的性能主要有2個方面的指標(biāo)：吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發(fā)生時app對外顯示無法響應(yīng)）驴党。

1. Total Heap

默認(rèn)情況下，vm會增加/減少堆大小以維持free space在整個vm中占的比例获茬，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定港庄。

一般而言，server端的app會有以下規(guī)則：

  1. 對vm分配盡可能多的內(nèi)存恕曲；
  2. 將Xms和Xmx設(shè)為一樣的值鹏氧。如果虛擬機啟動時設(shè)置使用的內(nèi)存比較小，這個時候又需要初始化很多對象佩谣，虛擬機就必須重復(fù)地增加內(nèi)存把还。
  3. 處理器核數(shù)增加，內(nèi)存也跟著增大茸俭。

2. Young Generation

  • 另一個影響app流暢性的因素是young generation的大小吊履。young generation越大，YGC越少调鬓；但是在固定堆大小情況下艇炎，更大的young generation就意味著小的tenured generation，就意味著更多的FGC(FGC會引發(fā)YGC)腾窝。
  • NewRatio反映的是young generation和tenured generation的大小比例缀踪。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設(shè)為一樣就固定了young generation的大小
  • SurvivorRatio是eden和survior大小比例虹脯，調(diào)整SurvivorRatio也可以優(yōu)化survivor的大小驴娃，但這對于性能的影響不是很大。

一般而言循集，server端的app會有以下規(guī)則：

  1. 首先決定能分配給vm的最大的堆內(nèi)存唇敞，然后設(shè)定最佳的young generation的大小暇榴；
  2. 堆內(nèi)存固定后厚棵，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時候足夠大蔼紧，能夠容納所有存活的對象（可以留10%-20%的空余）婆硬。

經(jīng)驗設(shè)置規(guī)則

  1. 年輕代大小選擇

    • 響應(yīng)時間優(yōu)先的應(yīng)用: 盡可能設(shè)大,直到接近系統(tǒng)的最低響應(yīng)時間限制(根據(jù)實際情況選擇).在此種情況下,年輕代收集發(fā)生的頻率也是最小的.同時,減少到達(dá)老年代的對象.
    • 吞吐量優(yōu)先的應(yīng)用: 盡可能的設(shè)置大,可能到達(dá)Gbit的程度.因為對響應(yīng)時間沒有要求,垃圾收集可以并行進(jìn)行,一般適合8CPU以上的應(yīng)用.
      避免設(shè)置過小.當(dāng)新生代設(shè)置過小時會導(dǎo)致:1.YGC次數(shù)更加頻繁 2.可能導(dǎo)致YGC對象直接進(jìn)入tenured generation,如果此時tenured generation滿了,會觸發(fā)FGC.

  2. 老年代大小選擇

    • 響應(yīng)時間優(yōu)先的應(yīng)用:老年代使用并發(fā)收集器,所以其大小需要小心設(shè)置。一般要考慮并發(fā)會話率和會話持續(xù)時間等一些參數(shù).如果堆設(shè)置小了,會造成內(nèi)存碎片,高回收頻率以及應(yīng)用暫停;如果堆大了,則需要較長的收集時間.最優(yōu)化的方案,一般需要參考這些數(shù)據(jù)獲得:并發(fā)垃圾收集信息奸例、持久代并發(fā)收集次數(shù)彬犯、傳統(tǒng)GC信息向楼、花在年輕代和老年代回收上的時間比例。

    • 吞吐量優(yōu)先的應(yīng)用:一般吞吐量優(yōu)先的應(yīng)用都有一個很大的年輕代和一個較小的老年代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而老年代盡存放長期存活對象.

  3. 較小堆引起的碎片問題
    因為老年代的并發(fā)收集器使用標(biāo)記-清除算法,所以不會對堆進(jìn)行壓縮.當(dāng)收集器回收時,會把相鄰的空間進(jìn)行合并,這樣可以分配給較大的對象.但是,當(dāng)堆空間較小時,運行一段時間以后,就會出現(xiàn)"碎片",如果并發(fā)收集器找不到足夠的空間,那么并發(fā)收集器將會停止,然后使用傳統(tǒng)的標(biāo)記-清除方式進(jìn)行回收.如果出現(xiàn)"碎片",可能需要進(jìn)行如下配置:

    • -XX:+UseCMSCompactAtFullCollection:使用并發(fā)收集器時,開啟對老年代的壓縮.
    • -XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設(shè)置多少次FGC后,對老年代進(jìn)行壓縮

  4. 用64位操作系統(tǒng)谐区，Linux下64位的jdk比32位jdk要慢一些湖蜕，但是吃得內(nèi)存更多，吞吐量更大

  5. Xmx和Xms設(shè)置一樣大宋列，MaxPermSize和MinPermSize設(shè)置一樣大昭抒，這樣可以減輕伸縮堆大小帶來的壓力

  6. 使用CMS的好處是用盡量少的新生代，經(jīng)驗值是128M－256M炼杖， 老生代利用CMS并行收集灭返， 這樣能保證系統(tǒng)低延遲的吞吐效率。 實際上CMS的收集停頓時間非常的短坤邪，2G的內(nèi)存熙含， 大約20－80ms的應(yīng)用程序停頓時間

  7. 系統(tǒng)停頓的時候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看艇纺，或者killall -3 java怎静，然后查看java控制臺日志，能看出很多問題黔衡。

  8. 仔細(xì)了解自己的應(yīng)用蚓聘，如果用了緩存，那么老年代應(yīng)該大一些盟劫，緩存的HashMap不應(yīng)該無限制長或粮，建議采用LRU算法的Map做緩存，LRUMap的最大長度也要根據(jù)實際情況設(shè)定捞高。

  9. 采用并發(fā)回收時氯材，年輕代小一點，老年代要大硝岗，因為年老大用的是并發(fā)回收氢哮，即使時間長點也不會影響其他程序繼續(xù)運行，網(wǎng)站不會停頓

  10. JVM參數(shù)的設(shè)置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數(shù)的設(shè)置沒有一個固定的公式型檀，需要根據(jù)實際數(shù)據(jù)冗尤、YGC次數(shù)等多方面來衡量。

為了避免promotion faild可能會導(dǎo)致-Xmn設(shè)置偏小胀溺，也意味著YGC的次數(shù)增多裂七，處理并發(fā)訪問的能力下降等問題。每個參數(shù)的調(diào)整都需要經(jīng)過詳細(xì)的性能測試仓坞，才能找到特定應(yīng)用的最佳配置背零。

promotion failed

垃圾回收時promotion failed是個很頭痛的問題，一般可能是兩種原因產(chǎn)生无埃，第一個原因是Survivor空間不夠徙瓶，Survivor空間里的對象還不應(yīng)該被移動到老年代毛雇，但年輕代又有很多對象需要放入Survivor空間；第二個原因是老年代沒有足夠的空間接納來自年輕代的對象侦镇；這兩種情況都會轉(zhuǎn)向Full GC灵疮，網(wǎng)站停頓時間較長。

解決方方案一：

  • 第一個原因的最終解決辦法是去掉Survivor空間壳繁，設(shè)置 -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0
    即可震捣，第二個原因的解決辦法是設(shè)置 CMSInitiatingOccupancyFraction 為某個值（假設(shè)70），這樣老年代空間到70%時就開始執(zhí)行CMS闹炉，老年代有足夠的空間接納來自年輕代的對象伍派。

解決方案一的改進(jìn)方案：

  • 上面方法不太好，因為沒有用到Survivor空間剩胁，所以老年代容易滿，CMS執(zhí)行會比較頻繁祥国。改善一下昵观，還是用Survivor空間，但是把Survivor空間加大舌稀，這樣也不會有promotion failed啊犬。

    具體操作上，32位Linux和64位Linux不一樣壁查，64位系統(tǒng)只要配置MaxTenuringThreshold參數(shù)觉至，CMS還是有暫停。為了解決暫停問題和promotion failed問題睡腿，最后設(shè)置 -XX:SurvivorRatio=1 语御，并把MaxTenuringThreshold 去掉，這樣既沒有暫停又不會有promotoin failed席怪，而且更重要的是应闯，老年代和永久代上升非常慢（因為好多對象到不了老年代就被回收了），所以CMS執(zhí)行頻率非常低挂捻，好幾個小時才執(zhí)行一次碉纺，這樣，服務(wù)器都不用重啟了刻撒。配置如下：

    -Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K 
-XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled 
-XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods 
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 
-XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值與Xmn的關(guān)系公式

上面介紹了promontion faild產(chǎn)生的原因是Eden空間不足的情況下將Eden與From survivor中的存活對象存入To survivor區(qū)時,To survivor區(qū)的空間不足骨田，再次晉升到old gen區(qū)，而old gen區(qū)內(nèi)存也不夠的情況下產(chǎn)生了promontion faild從而導(dǎo)致full gc声怔。那可以推斷出：Eden+from survivor < old gen區(qū)剩余內(nèi)存時态贤，不會出現(xiàn)promontion faild的情況，即：

(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatio+2))

進(jìn)而推斷出：

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatio+2)))/(Xmx-Xmn)*100

例如：

當(dāng)Xmx=128 Xmn=36 SurvivorRatio=1時 
CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913

當(dāng)Xmx=128 Xmn=24 SurvivorRatio=1時 
CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

當(dāng)Xmx=3000 Xmn=600 SurvivorRatio=1時 
CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要調(diào)整Xmn或SurvivorRatio值醋火。

參考

  1. JVM系列三:JVM參數(shù)設(shè)置抵卫、分析
  2. JVM -JVM優(yōu)化參數(shù)設(shè)置
  3. JAVA HOTSPOT VM
  4. JVM 幾個重要的參數(shù)
  5. java jvm 參數(shù) -Xms -Xmx -Xmn -Xss 調(diào)優(yōu)總結(jié)
  6. Java HotSpot VM Options
  7. Frequently Asked Questions About the Java HotSpot VM
  8. Java SE HotSpot at a Glance
  9. Java性能調(diào)優(yōu)筆記
  10. 說說MaxTenuringThreshold這個參數(shù)
  11. GC調(diào)優(yōu)方法總結(jié)
  12. Java 6 JVM參數(shù)選項大全（中文版）
如果覺得還不錯狮荔，關(guān)注公眾號獲取更多優(yōu)質(zhì)文章 ~
微信搜一搜 四方云和
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市介粘，隨后出現(xiàn)的幾起案子殖氏，更是在濱河造成了極大的恐慌，老刑警劉巖姻采，帶你破解...
    沈念sama閱讀 211,817評論 6贊 492
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件雅采，死亡現(xiàn)場離奇詭異，居然都是意外死亡慨亲，警方通過查閱死者的電腦和手機婚瓜，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,329評論 3贊 385
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來刑棵，“玉大人巴刻，你說我怎么就攤上這事◎惹” “怎么了胡陪？”我有些...
    開封第一講書人閱讀 157,354評論 0贊 348
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長碍舍。 經(jīng)常有香客問我柠座，道長，這世上最難降的妖魔是什么片橡？ 我笑而不...
    開封第一講書人閱讀 56,498評論 1贊 284
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任妈经，我火速辦了婚禮，結(jié)果婚禮上捧书，老公的妹妹穿的比我還像新娘吹泡。我一直安慰自己，他們只是感情好经瓷，可當(dāng)我...
    茶點故事閱讀 65,600評論 6贊 386
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布荞胡。 她就那樣靜靜地躺著，像睡著了一般了嚎。 火紅的嫁衣襯著肌膚如雪泪漂。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,829評論 1贊 290
  • 城市分裂傳說
    那天歪泳，我揣著相機與錄音萝勤，去河邊找鬼。 笑死呐伞，一個胖子當(dāng)著我的面吹牛敌卓，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播伶氢，決...
    沈念sama閱讀 38,979評論 3贊 408
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼趟径，長吁一口氣：“原來是場噩夢啊……” “哼瘪吏！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起蜗巧，我...
    開封第一講書人閱讀 37,722評論 0贊 266
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤掌眠，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后幕屹，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體蓝丙，經(jīng)...
    沈念sama閱讀 44,189評論 1贊 303
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,519評論 2贊 327
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年望拖，在試婚紗的時候發(fā)現(xiàn)自己被綠了渺尘。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,654評論 1贊 340
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡说敏，死狀恐怖鸥跟，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情盔沫，我是刑警寧澤医咨，帶...
    沈念sama閱讀 34,329評論 4贊 330
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站迅诬，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏婿牍。R本人自食惡果不足惜侈贷，卻給世界環(huán)境...
    茶點故事閱讀 39,940評論 3贊 313
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望等脂。 院中可真熱鬧俏蛮，春花似錦、人聲如沸上遥。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,762評論 0贊 21
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽痹栖。三九已至惫撰，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間模软，已是汗流浹背伟骨。 一陣腳步聲響...
    開封第一講書人閱讀 31,993評論 1贊 266
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留燃异，地道東北人携狭。 一個月前我還...
    沈念sama閱讀 46,382評論 2贊 360
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像回俐，于是被迫代替她去往敵國和親逛腿。 傳聞我的和親對象是個殘疾皇子稀并，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,543評論 2贊 349