主頁 > 後端開發 > JDK11現存性能bug(JDK-8221393)深度決議

JDK11現存性能bug(JDK-8221393)深度決議

2020-10-01 12:11:08 後端開發

這是一篇鴿了很久的博客，因為博客內容和素材早就準備差不多了，但就是一直懶得整理，今天終于下定決心終于整理出來了，這也是這個bug JDK-8221393唯一一篇中文介紹博客，

先大致介紹下這個bug，準確說這個應該是jdk11新引入的zgc的一個bug，該bug在被觸發的情況下會導致行程CPU使用率會逐漸升高，如果不管的話最終CPU會到100% 影響服務可用性，而且這個性能bug在jdk11最新的代碼中仍未修復，不過不用擔心，這個bug觸發的要求比較苛刻，估計這也是jdk開發者不修復該bug的原因之一，另外，我在翻看jdk13原始碼時發現該bug已被修復，并且有些相關設計上的提升，
在這里插入圖片描述
該bug的表象如上圖，在業務和代碼邏輯無變更的情況下，CPU使用率大概每隔10天就會翻倍，重啟后恢復正常，上圖中我們分別在11月19和11月29日重啟過，CPU明顯下跌，然后又開啟一輪新的輪回…… 這個服務是我們很重要的一個服務，我們有同事很長時間都在找原因，也嘗試做過很多優化，一直都沒解決，我們的服務只好靠定期重啟續命了， 不過這事在我介入后的第二天就立馬有了眉目，嘿嘿嘿，，， (不是我能打，而是他們缺少一把趁手的“兵器”)

排查程序

作為一名工程師，面對上面的現象，你會怎么做？ 我想你的第一反應肯定是業務代碼有問題？是不是有什么地方導致記憶體泄露？ 是不是業務代碼里有什么地方加載的資料太多，越來越慢？…… 同事嘗試過dump堆里的內容，dump jstak執行緒…… 都沒看出來什么例外，也優化了業務代碼里之前一些不合理的邏輯，始終沒有解決問題， 當時的問題是他們都沒有往熱點代碼的方向排查，主要是因為他們不知道有啥好用的工具，

而我恰好當時在關注過阿里的Arthas，知道當時正好Arthas新增了性能排查命令profiler 可以生成CPU火焰圖，而我又恰好看過阮一峰老師的如何讀懂火焰圖？，然后我就給同事推薦了Arthas并建議同事用Arthas生成CPU的火焰圖，看下到底是哪個地方耗費CPU，然后就發現了例外，
在這里插入圖片描述

火焰圖該怎么讀？

不知道怎么看火焰圖不要緊，其實很簡單，具體可參考阮一峰老師的如何讀懂火焰圖？，

y 軸表示呼叫堆疊，每一層都是一個函式，呼叫堆疊越深，火焰就越高，頂部就是正在執行的函式，下方都是它的父函式，
x 軸表示抽樣數，如果一個函式在 x 軸占據的寬度越寬，就表示它被抽到的次數多，即執行的時間長，注意，x 軸不代表時間，而是所有的呼叫堆疊合并后，按字母順序排列的，
火焰圖就是看頂層的哪個函式占據的寬度最大，只要有"平頂"（plateaus），就表示該函式可能存在性能問題，

你可以簡單認為每一塊越寬，它就越耗費CPU，用火焰圖做性能分析的關鍵就是去找那些你覺得本應該很窄但實際卻很寬的函式，上圖中就是我們有問題服務長期運行后和剛啟動時的生成的火焰圖(同樣的代碼和環境)，左圖明顯有例外，它有好幾個"平頂"，也就是說該函式消耗了過多的CPU，大概率這就是問題的根源了，

這里我特意找到了該函式呼叫的堆疊資訊，然后就發現了我們代碼中不合理的地方，

[0x00007f2091c15000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(java.base@11/Native Method)
	at java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(java.base@11/StackStreamFactory.java:386)
	at java.lang.StackStreamFactory$AbstractStackWalker.getNextBatch(java.base@11/StackStreamFactory.java:322)
	at java.lang.StackStreamFactory$AbstractStackWalker.peekFrame(java.base@11/StackStreamFactory.java:263)
	at java.lang.StackStreamFactory$AbstractStackWalker.hasNext(java.base@11/StackStreamFactory.java:351)
	at java.lang.StackStreamFactory$StackFrameTraverser.tryAdvance(java.base@11/StackStreamFactory.java:593)
	at java.util.stream.ReferencePipeline.forEachWithCancel(java.base@11/ReferencePipeline.java:127)
	at java.util.stream.AbstractPipeline.copyIntoWithCancel(java.base@11/AbstractPipeline.java:502)
	at java.util.stream.AbstractPipeline.copyInto(java.base@11/AbstractPipeline.java:488)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(java.base@11/AbstractPipeline.java:474)
	at java.util.stream.FindOps$FindOp.evaluateSequential(java.base@11/FindOps.java:150)
	at java.util.stream.AbstractPipeline.evaluate(java.base@11/AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.findFirst(java.base@11/ReferencePipeline.java:543)
	at org.apache.logging.log4j.util.StackLocator.lambda$getCallerClass$6(StackLocator.java:54)
	at org.apache.logging.log4j.util.StackLocator$$Lambda$94/0x00007f238e2cacb0.apply(Unknown Source)
	at java.lang.StackStreamFactory$StackFrameTraverser.consumeFrames(java.base@11/StackStreamFactory.java:534)
	at java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(java.base@11/StackStreamFactory.java:306)
	at java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(java.base@11/Native Method)
	at java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(java.base@11/StackStreamFactory.java:370)
	at java.lang.StackStreamFactory$AbstractStackWalker.walk(java.base@11/StackStreamFactory.java:243)
	at java.lang.StackWalker.walk(java.base@11/StackWalker.java:498)
	at org.apache.logging.log4j.util.StackLocator.getCallerClass(StackLocator.java:53)
	at org.apache.logging.log4j.util.StackLocatorUtil.getCallerClass(StackLocatorUtil.java:61)
	at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
	at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
	at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
	at com.xxxxxxx.infra.cache.redis.ReadCommandTemplate.<init>(ReadCommandTemplate.java:21)
	at com.xxxxxxx.infra.cache.redis.RedisClient$4.<init>(RedisClient.java:138)
	at com.xxxxxxx.infra.cache.redis.RedisClient.hget(RedisClient.java:138)
	...
	...

ReadCommandTemplate是我們公司封裝的一個redis client，每讀寫一次redis就會實體化一個ReadCommandTemplate，我們的業務邏輯中每個請求都會讀一次redis，所以導致ReadCommandTemplate這個類生成很多個實體，本身這個類很輕量，按理來說多次實體話也沒關系，但其中用了logger，而且logger沒有宣告為static，所以沒new 一個ReadCommandTemplate，都會同時生成一個logger，從火焰圖來看，似乎是生成logger的程序中產生了性能問題，

public abstract class ReadCommandTemplate<T> {
    private Logger logger = LoggerFactory.getLogger(ReadCommandTemplate.class);
    /** 
     * 其他代碼邏輯省略
     */
}

有經驗的java開發者一眼就能看出來上面代碼的不合理之處，但應該只是稍微影響性能，不會出現文首那種詭異的現象！ 確實，這個redis client在我們部分被廣泛使用，其他的應用都沒出現問題，，， 會不會是這個應用恰巧湊齊了某個bug觸發的所有條件？？

Bug的確認

要想確認bug是否是這個非static的logger導致的，有兩個方案：1. 修復logger的問題，看CPU是否會上漲， 2. 真正搞清楚這個bug的原理，因為方案1需要至少等待一周才能實錘，所以我們選擇了二者并行，同事修復了logger，而我開啟了問題探索和jvm原始碼閱讀之旅，后來方案1確實也正式了是logger導致的，而我也找到了19年有人給jvm團隊反饋bug后jvm團隊討論的郵件串列，
在這里插入圖片描述
jdk的開發者Stefan Karlsson確認并大致給出了這個bug出現的原因，如上圖，這里我大致解釋下，JVM在查找方法的時候會呼叫"ResolvedMethodTable::lookup"，其實這里是查找一個只有1007個bucket的hash表，因為jdk11的zgc沒有定期對ResolvedMethodTable做清理，所以里面的資料會越來越多，查詢會越來越慢，

問題是用jdk11+zgc+log4j組合的人也非常多，為什么偏偏就我們的代碼觸發了bug？？

深度剖析

為了深入理解這個bug，我們首先來看下我們調LoggerFactory.getLogger()的時候發生了什么！！
在這里插入圖片描述
在jdk9及以后的版本中，log4j使用了新的StackWalker來獲取執行緒的堆疊資訊，然后遍歷每個堆疊幀，所以StackWalker就呼叫native方法fetchStackFrames從JVM里獲取這個堆疊幀，

我翻閱了JVM代碼，找到了ResolvedMethodTable::lockup()在做啥！ 不過首先我們得知道ResolvedMethodTable是啥？ ResolvedMethodTable可以簡單認為是JVM中存盤所有已經決議到的方法資訊的一個hashtable，它只有1007的bucket(為什么設計這么小？)，這么小的bucket必然很容易產生hash沖突，處理hash沖突的方式就是開鏈，而lockup()在查找程序中，需要遍歷單鏈表，所以如果單鏈表過長，lookup的查詢性能就下來了，lookup()的原始碼如下，

oop ResolvedMethodTable::lookup(Method* method) {
  unsigned int hash = compute_hash(method);
  int index = hash_to_index(hash);
  return lookup(index, hash, method);
}
oop ResolvedMethodTable::lookup(int index, unsigned int hash, Method* method) {
  for (ResolvedMethodEntry* p = bucket(index); p != NULL; p = p->next()) {
    if (p->hash() == hash) {
      oop target = p->object_no_keepalive();
      if (target != NULL && java_lang_invoke_ResolvedMethodName::vmtarget(target) == method) {
        ResourceMark rm;
        log_debug(membername, table) ("ResolvedMethod entry found for %s index %d",
                                       method->name_and_sig_as_C_string(), index);
        return p->object();
      }
    }
  }
  return NULL;
}

現在的問題是究竟是什么導致ResolvedMethodTable資料太多，從而使得其中單個bucket的鏈表過長？ 我們還是從該bug的郵件討論串列里找到答案http://mail.openjdk.java.net/pipermail/zgc-dev/2019-March/000612.html，這里我大概翻譯如下:

GC除了卸載不用的類時，也會做好多其他的清理作業，比如清理ResolvedMethodTable和StringTable中不用的資訊，ResolvedMethodTable保存著java中ResolvedMethodName類實體的弱指標，如果ResolvedMethodName不可達，正常情況下gc就會清理掉這個不可達物件，而ResolvedMethodName是MemberName中的一部分，StackWalker遍歷堆疊幀的時候，就會創建MemberName java物件并放到StackFrameInfo.memberName中，jvm中的代碼實作如下:

void java_lang_StackFrameInfo::set_method_and_bci(Handle stackFrame, 
const methodHandle& method, int bci, TRAPS) {
...
   // 創建ResolvedMethodName物件并插入到ResolvedMethodTable中
   CallInfo info(method(), ik, CHECK);
   // 把ResolveMethodName物件放到MemberName中
   MethodHandles::init_method_MemberName(mname, info);

堆疊呼叫資訊如下：

  java_lang_StackFrameInfo::set_method_and_bci(Handle, methodHandle 
const&, int, Thread*)
  JavaFrameStream::fill_frame(int, objArrayHandle, methodHandle const&, 
Thread*)
  StackWalk::fill_in_frames(long, BaseFrameStream&, int, int, 
objArrayHandle, int&, Thread*)
  StackWalk::fetchNextBatch(Handle, long, long, int, int, 
objArrayHandle, Thread*)
  JVM_MoreStackWalk
  java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames

后續，如果StackFrameInfos不用之后，這些物件會被從類的參考關系中移除，并被gc回收掉，然后gc會移除ResolvedMethodTable中相應的ResolvedMethodName，但問題是jdk11中，zgc并沒有真正移除這些ResolvedMethodName，從而導致ResolvedMethodTable中的資料量越來越大，單鏈越來越長，查找效率越來越低，
在這里插入圖片描述
在JDK11的原始碼中SymbolTable::unlink()中實作了ResolvedMethodTable中無用資訊的卸載，其他幾個老gc都呼叫了，而zgc中確實沒有呼叫，不知道這是忘記了還是特意為之……

簡單梳理下就是：每次呼叫StackWalker遍歷堆疊幀的時候，每個堆疊幀都會生成一個ResolvedMethodName物件放到jvm中的ResolvedMethodTable中，但jdk11的zgc不能有效清理其中不用的物件，因為ResolvedMethodTable是個定容的hashtable，隨著其中的資料越來越多，每個bucket的單鏈表越來越長，查詢效率會越來越慢， 所以最終導致CPU的使用率越來越高，

避坑指南

如果你看懂了上文的bug原理，相信你已經知道了如何閉坑，如果沒看懂也沒關系， 一句話 不要使用jdk11+zgc的同時頻繁使用StackWalker(比如錯誤使用log4j)，當然也不是完全不能使用log4j了，只要不是頻繁呼叫StackWalker就沒問題，像我們代碼中的logger只需要宣告成static，這樣StackWalker只會在類初始化的時候呼叫，就不會有問題了，知道了原理，也就能解釋清楚為什么我們很多其他應用用了jdk11也用了有問題的RedisClient沒有出現cpu例外的現象，就是因為其他應用沒有啟用zgc，

當然這個bug的本質就是jdk11+zgc+StackWalker的bug，三者都是bug觸發的必要條件，如果你能避免其中一條就可以完美避開這個bug了，比如升級到jdk12+，比如不用zgc……

Bugfix

對于我們應用來說，只需按照上面的避坑指南操作即可，但對于jdk團隊來說，這個bug他們肯定是要修復的，
在這里插入圖片描述
從官網bug頁面可以看到這個bug在jdk13中已經修復了，我們來看看他們是如何修復的，是不是只需要在zgc合適的地方調一下SymbolTable::unlink()就行了？是的，但jdk團隊做的遠不止于此，除了unlink之外，他們還優化了ResolvedMethodTable的實作，支持了動態擴縮容，可以避免單鏈表過長的問題，具體可以看下jdk原始碼中src/hotspot/share/prims/resolvedMethodTable.cpp的檔案，

void ResolvedMethodTable::do_concurrent_work(JavaThread* jt) {
  _has_work = false;
  double load_factor = get_load_factor();
  log_debug(membername, table)("Concurrent work, live factor: %g", load_factor);
  // 人工load_factor大于2，并且沒有達到最大限制，就執行bucket擴容，并且移除無用的entry
  if (load_factor > PREF_AVG_LIST_LEN && !_local_table->is_max_size_reached()) {
    grow(jt);
  } else {
    clean_dead_entries(jt);
  }
}

void ResolvedMethodTable::grow(JavaThread* jt) {
  ResolvedMethodTableHash::GrowTask gt(_local_table);
  if (!gt.prepare(jt)) {
    return;
  }
  log_trace(membername, table)("Started to grow");
  {
    TraceTime timer("Grow", TRACETIME_LOG(Debug, membername, table, perf));
    while (gt.do_task(jt)) {
      gt.pause(jt);
      {
        ThreadBlockInVM tbivm(jt);
      }
      gt.cont(jt);
    }
  }
  gt.done(jt);
  _current_size = table_size();
  log_info(membername, table)("Grown to size:" SIZE_FORMAT, _current_size);
}

總結

這個bug觸發的主要原因其實還是我們自己的代碼寫的不夠規范(logger未宣告為static)，而這個不規范其實也對其他沒有觸發這個bug的應用也產生了影響，畢竟生成logger也是會消耗性能的，我們代碼fix后其他應用升級，有些服務CPU占用率降低5%+，這也充分說明代碼質量的重要性，尤其是那種被廣泛采用的基礎代碼，

另外是不是有些人還有個疑問，這個bug為什么不在jdk11后續版本中修掉，而是選擇在jdk13中徹底修掉，不怕影響到使用jdk11的用戶嗎？對這個問題我有個想法，其實這個bug并不是很容易觸發的嚴重bug(jdk11+zgc+log4j的頻繁呼叫)，而且即便是觸發了，jdk的使用者也很容易通過修改自己的代碼來規避這個bug，所以對jdk的開發者而言這不是一個重要且緊急的bug，后續修復掉就行了，

參考資料

  1. 阿里巴巴開源java問題排查工具 Arthas.
  2. 阮一峰 如何讀懂火焰圖？
  3. jdk開發者關于bug討論的郵件串列

本文來自https://blog.csdn.net/xindoo

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/145081.html

標籤：Java

上一篇：Redis的發布和訂閱

下一篇：spring cloud入門

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 【C++】Microsoft C++、C 和匯編程式檔案

    ......

    uj5u.com 2020-09-10 00:57:23 more
  • 例外宣告

    相比于斷言適用于排除邏輯上不可能存在的狀態，例外通常是用于邏輯上可能發生的錯誤。 例外宣告 Item 1：當函式不可能拋出例外或不能接受拋出例外時，使用noexcept 理由 如果不打算拋出例外的話，程式就會認為無法處理這種錯誤，并且應當盡早終止，如此可以有效地阻止例外的傳播與擴散。 示例 //不可 ......

    uj5u.com 2020-09-10 00:57:27 more
  • Codeforces 1400E Clear the Multiset(貪心 + 分治)

    鏈接：https://codeforces.com/problemset/problem/1400/E 來源：Codeforces 思路：給你一個陣列，現在你可以進行兩種操作，操作1：將一段沒有 0 的區間進行減一的操作，操作2：將 i 位置上的元素歸零。最終問：將這個陣列的全部元素歸零后操作的最少 ......

    uj5u.com 2020-09-10 00:57:30 more
  • UVA11610 【Reverse Prime】

    本人看到此題沒有翻譯，就附帶了一個自己的翻譯版本 思考 這一題，它的第一個要求是找出所有 $7$ 位反向質數及其質因數的個數。 我們應該需要質數篩篩選1~$10^{7}$的所有數，這里就不慢慢介紹了。但是，重讀題，我們突然發現反向質數都是 $7$ 位，而將它反過來后的數字卻是 $6$ 位數，這就說明 ......

    uj5u.com 2020-09-10 00:57:36 more
  • 統計區間素數數量

    1 #pragma GCC optimize(2) 2 #include <bits/stdc++.h> 3 using namespace std; 4 bool isprime[1000000010]; 5 vector<int> prime; 6 inline int getlist(int ......

    uj5u.com 2020-09-10 00:57:47 more
  • C/C++編程筆記：C++中的 const 變數詳解，教你正確認識const用法

    1、C中的const 1、區域const變數存放在堆疊區中，會分配記憶體（也就是說可以通過地址間接修改變數的值）。測驗代碼如下： 運行結果： 2、全域const變數存放在只讀資料段（不能通過地址修改，會發生寫入錯誤）， 默認為外部聯編，可以給其他源檔案使用（需要用extern關鍵字修飾） 運行結果： ......

    uj5u.com 2020-09-10 00:58:04 more
  • 【C++犯錯記錄】VS2019 MFC添加資源不懂如何修改資源宏ID

    1. 首先在資源視圖中，添加資源 2. 點擊新添加的資源，復制自動生成的ID 3. 在解決方案資源管理器中找到Resource.h檔案，編輯，使用整個專案搜索和替換的方式快速替換 宏宣告 4. Ctrl+Shift+F 全域搜索，點擊查找全部，然后逐個替換 5. 為什么使用搜索替換而不使用屬性視窗直 ......

    uj5u.com 2020-09-10 00:59:11 more
  • 【C++犯錯記錄】VS2019 MFC不懂的批量添加資源

    1. 打開資源頭檔案Resource.h，在其中預先定義好宏 ID（不清楚其實ID值應該設定多少，可以先新建一個相同的資源項，再在這個資源的ID值的基礎上遞增即可） 2. 在資源視圖中選中專案資源，按F7編輯資源檔案，按 ID 型別 相對路徑的形式添加 資源。（別忘了先把檔案拷貝到專案中的res檔案 ......

    uj5u.com 2020-09-10 01:00:19 more
  • C/C++編程筆記：關于C++的參考型別，專供新手入門使用

    今天要講的是C++中我最喜歡的一個用法——參考，也叫別名。 參考就是給一個變數名取一個變數名，方便我們間接地使用這個變數。我們可以給一個變數創建N個參考，這N + 1個變數共享了同一塊記憶體區域。(參考型別的變數會占用記憶體空間，占用的記憶體空間的大小和指標型別的大小是相同的。雖然參考是一個物件的別名，但 ......

    uj5u.com 2020-09-10 01:00:22 more
  • 【C/C++編程筆記】從頭開始學習C ++：初學者完整指南

    眾所周知，C ++的學習曲線陡峭，但是花時間學習這種語言將為您的職業帶來奇跡，并使您與其他開發人員區分開。您會更輕松地學習新語言，形成真正的解決問題的技能，并在編程的基礎上打下堅實的基礎。 C ++將幫助您養成良好的編程習慣（即清晰一致的編碼風格，在撰寫代碼時注釋代碼，并限制類內部的可見性），并且由 ......

    uj5u.com 2020-09-10 01:00:41 more
最新发布
  • Rust中的智能指標:Box<T> Rc<T> Arc<T> Cell<T> RefCell<T> Weak

    Rust中的智能指標是什么 智能指標（smart pointers）是一類資料結構，是擁有資料所有權和額外功能的指標。是指標的進一步發展 指標（pointer）是一個包含記憶體地址的變數的通用概念。這個地址參考，或 ” 指向”（points at）一些其 他資料 。參考以 & 符號為標志并借用了他們所 ......

    uj5u.com 2023-04-20 07:24:10 more
  • Java的值傳遞和參考傳遞

    值傳遞不會改變本身，參考傳遞（如果傳遞的值需要實體化到堆里）如果發生修改了會改變本身。 1.基本資料型別都是值傳遞 package com.example.basic; public class Test { public static void main(String[] args) { int ......

    uj5u.com 2023-04-20 07:24:04 more
  • [2]SpinalHDL教程——Scala簡單入門

    第一個 Scala 程式 shell里面輸入 $ scala scala> 1 + 1 res0: Int = 2 scala> println("Hello World!") Hello World! 檔案形式 object HelloWorld { /* 這是我的第一個 Scala 程式 * 以 ......

    uj5u.com 2023-04-20 07:23:58 more
  • 理解函式指標和回呼函式

    理解 函式指標 指向函式的指標。比如： 理解函式指標的偽代碼 void (*p)(int type, char *data); // 定義一個函式指標p void func(int type, char *data); // 宣告一個函式func p = func; // 將指標p指向函式func ......

    uj5u.com 2023-04-20 07:23:52 more
  • Django筆記二十五之資料庫函式之日期函式

    本文首發于公眾號：Hunter后端 原文鏈接：Django筆記二十五之資料庫函式之日期函式 日期函式主要介紹兩個大類，Extract() 和 Trunc() Extract() 函式作用是提取日期，比如我們可以提取一個日期欄位的年份，月份，日等資料 Trunc() 的作用則是截取，比如 2022-0 ......

    uj5u.com 2023-04-20 07:23:45 more
  • 一天吃透JVM面試八股文

    什么是JVM？ JVM，全稱Java Virtual Machine（Java虛擬機），是通過在實際的計算機上仿真模擬各種計算機功能來實作的。由一套位元組碼指令集、一組暫存器、一個堆疊、一個垃圾回收堆和一個存盤方法域等組成。JVM屏蔽了與作業系統平臺相關的資訊，使得Java程式只需要生成在Java虛擬機 ......

    uj5u.com 2023-04-20 07:23:31 more
  • 使用Java接入小程式訂閱訊息！

    更新完微信服務號的模板訊息之后，我又趕緊把微信小程式的訂閱訊息給實作了！之前我一直以為微信小程式也是要企業才能申請，沒想到小程式個人就能申請。 訊息推送平臺🔥推送下發【郵件】【短信】【微信服務號】【微信小程式】【企業微信】【釘釘】等訊息型別。 https://gitee.com/zhongfuch ......

    uj5u.com 2023-04-20 07:22:59 more
  • java -- 緩沖流、轉換流、序列化流

    緩沖流 緩沖流, 也叫高效流, 按照資料型別分類： 位元組緩沖流：BufferedInputStream，BufferedOutputStream 字符緩沖流：BufferedReader，BufferedWriter 緩沖流的基本原理，是在創建流物件時，會創建一個內置的默認大小的緩沖區陣列，通過緩沖 ......

    uj5u.com 2023-04-20 07:22:49 more
  • Java-SpringBoot-Range請求頭設定實作視頻分段傳輸

    老實說，人太懶了，現在基本都不喜歡寫筆記了，但是網上有關Range請求頭的文章都太水了 下面是抄的一段StackOverflow的代碼...自己大修改過的，寫的注釋挺全的，應該直接看得懂，就不解釋了 寫的不好...只是希望能給視頻網站開發的新手一點點幫助吧. 業務場景：視頻分段傳輸、視頻多段傳輸（理 ......

    uj5u.com 2023-04-20 07:22:42 more
  • Windows 10開發教程_編程入門自學教程_菜鳥教程-免費教程分享

    教程簡介 Windows 10開發入門教程 - 從簡單的步驟了解Windows 10開發，從基本到高級概念，包括簡介，UWP，第一個應用程式，商店，XAML控制元件，資料系結，XAML性能，自適應設計，自適應UI，自適應代碼，檔案管理，SQLite資料庫，應用程式到應用程式通信，應用程式本地化，應用程式 ......

    uj5u.com 2023-04-20 07:22:35 more

Copyright © 2010-2020 有解無憂