2. 程式人生 > >Jvm線上調優實戰（1）

Jvm線上調優實戰（1）

阿新 • • 發佈：2019-01-13

偵探問題根源

  • 通過top指令發現，當前5511的執行緒cup和記憶體的使用率過高：
top ：
 5511 root      20   0 16.841g 6.088g   5584 S  47.0 39.2   4011:41 java
 9550 root      20   0 2516200  67892   2436 S   0.7  0.4 204:20.40 java
21271 root      20   0 11.579g 0.987g   5056 S   0.7  6.4  46:29.88 java
   13 root      20   0       0      0      0 S   0.3
 
  0.0   0:35.21 ksoftirqd/1
 2128 root      20   0  9.833g 1.273g   6656 S   0.3  8.2  33:48.35 java
29464 root      20   0 11.578g 1.030g   5448 S   0.3  6.6  31:42.67 java
31721 root      20   0  157744   2264   1544 R   0.3  0.0   0:00.32 top
  • 查詢當前java程序詳情，利用 jinfo pid 5511
Attaching to process ID 5511, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.151
 
-b12
Java System Properties:

java.runtime.name = Java(TM) SE Runtime Environment
java.vm.version = 25.151-b12
sun.boot.library.path = /usr/local/java/jre/lib/amd64
java.vendor.url = http://java.oracle.com/
java.vm.vendor = Oracle Corporation
path.separator = :
file.encoding.pkg = sun.io
java.vm.name = Java HotSpot(TM) 64
 
-Bit Server VM
sun.os.patch.level = unknown
sun.java.launcher = SUN_STANDARD
user.country = US
user.dir = /mnt/app/bdcenter-base/bdcenter-service-base-1.0-SNAPSHOT
java.vm.specification.name = Java Virtual Machine Specification
PID = 5511
java.runtime.version = 1.8.0_151-b12
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
os.arch = amd64
java.endorsed.dirs = /usr/local/java/jre/lib/endorsed
line.separator = 

java.io.tmpdir = /tmp
java.vm.specification.vendor = Oracle Corporation
os.name = Linux
io.netty.noKeySetOptimization = true
sun.jnu.encoding = UTF-8
java.library.path = /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
spring.beaninfo.ignore = true
sun.nio.ch.bugLevel = 
java.specification.name = Java Platform API Specification
java.class.version = 52.0
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
os.version = 3.10.0-693.2.2.el7.x86_64
user.home = /root
user.timezone = Asia/Shanghai
catalina.useNaming = false
java.awt.printerjob = sun.print.PSPrinterJob
file.encoding = UTF-8
@appId = bdcenter-service-base
java.specification.version = 1.8
io.netty.recycler.maxCapacityPerThread = 0
catalina.home = /tmp/tomcat.7050606280722271893.9025
user.name = root
java.class.path = bdcenter-service-base-1.0-SNAPSHOT.jar
java.vm.specification.version = 1.8
sun.arch.data.model = 64
sun.java.command = bdcenter-service-base-1.0-SNAPSHOT.jar --spring.profiles.active=prod 5
java.home = /usr/local/java/jre
user.language = en
java.specification.vendor = Oracle Corporation
io.netty.noUnsafe = true
awt.toolkit = sun.awt.X11.XToolkit
java.vm.info = mixed mode
java.version = 1.8.0_151
java.ext.dirs = /usr/local/java/jre/lib/ext:/usr/java/packages/lib/ext
sun.boot.class.path = /usr/local/java/jre/lib/resources.jar:/usr/local/java/jre/lib/rt.jar:/usr/local/java/jre/lib/sunrsasign.jar:/usr/local/java/jre/lib/jsse.jar:/usr/local/java/jre/lib/jce.jar:/usr/local/java/jre/lib/charsets.jar:/usr/local/java/jre/lib/jfr.jar:/usr/local/java/jre/classes
java.awt.headless = true
java.vendor = Oracle Corporation
catalina.base = /tmp/tomcat.7050606280722271893.9025
file.separator = /
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
sun.io.unicode.encoding = UnicodeLittle
sun.cpu.endian = little
sun.cpu.isalist = 

VM Flags:
Non-default VM flags: -XX:+AggressiveOpts -XX:CICompilerCount=4 -XX:CMSInitiatingOccupancyFraction=75 -XX:+CMSParallelRemarkEnabled -XX:+DisableExplicitGC -XX:InitialHeapSize=6442450944 -XX:MaxDirectMemorySize=1073741824 -XX:MaxHeapSize=6442450944 -XX:MaxNewSize=697892864 -XX:MaxTenuringThreshold=6 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=697892864 -XX:OldPLABSize=16 -XX:OldSize=5744558080 -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ThreadStackSize=256 -XX:+UseBiasedLocking -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseFastAccessorMethods -XX:+UseParNewGC 
Command line:  -Xms6G -Xmx6G -XX:MaxPermSize=256M -XX:MaxDirectMemorySize=1G -Xss256k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+UseFastAccessorMethods -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:CMSInitiatingOccupancyFraction=75 -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails

Command line 可以看出JVM 使用者輸入參，對整個jvm的資訊進行訊息的描述

  • 檢視當前gc情況： jstat gcacuse 5511 
[root@bigdata-service-1:/root]# jstat -gccause 5511 1000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC                 
  0.00   8.86  61.50  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC               
  0.00   8.86  64.31  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC               
  0.00   8.86  65.04  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC               
  0.00   8.86  65.17  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC               
  0.00   8.86  65.26  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC               
  0.00   8.86  65.26  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC               
  0.00   8.86  67.80  72.16  95.05  91.62   4577  326.410     8    8.855  335.265 Allocation Failure   No GC

發現新生代頻繁的進行gc操【YGC：gc 次數, YGCT： gc時間】，老年的幾乎沒有gc【FGC：full gc次數，FGCT ：full gc時間】，可能原因是新生代的設計過小，導致新生代頻繁gc

  • 檢視當前jvm 記憶體分配： jmap -heap 5511
[[email protected]1:/root]# jmap -heap 5511
Attaching to process ID 5511, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.151-b12

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 6442450944 (6144.0MB)
   NewSize                  = 697892864 (665.5625MB)
   MaxNewSize               = 697892864 (665.5625MB)
   OldSize                  = 5744558080 (5478.4375MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 628162560 (599.0625MB)
   used     = 210724080 (200.96214294433594MB)
   free     = 417438480 (398.10035705566406MB)
   33.54610628178795% used
Eden Space:
   capacity = 558432256 (532.5625MB)
   used     = 203572032 (194.14141845703125MB)
   free     = 354860224 (338.42108154296875MB)
   36.45420367694519% used
From Space:
   capacity = 69730304 (66.5MB)
   used     = 7152048 (6.8207244873046875MB)
   free     = 62578256 (59.67927551269531MB)
   10.256728552337876% used
To Space:
   capacity = 69730304 (66.5MB)
   used     = 0 (0.0MB)
   free     = 69730304 (66.5MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 5744558080 (5478.4375MB)
   used     = 4145940376 (3953.876853942871MB)
   free     = 1598617704 (1524.560646057129MB)
   72.17161561016022% used

32720 interned Strings occupying 4008568 bytes.

從JVM的分配可以看出，新生代分配：capacity = 628162560 (599.0625MB)，Eden Space：capacity = 558432256 (532.5625MB)，老年代分配：capacity = 5744558080 (5478.4375MB)。從資料分析出，新生代設計過小，導致新生代頻繁gc。其次，新生代設計過小，導致大物件無法分配，直接分配到老年代。導致老年代空間佔用過大，從而佔用整個系統記憶體空間。可能導致其他服務記憶體不足。

  • 線上手動GC，檢視GC後的JVM詳情資訊

[root@bigdata-service-1:/root]# jmap -histo:live 5511
日誌過大.....

[root@bigdata-service-1:/root]# jstat -gc 5511 1000
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
68096.0 68096.0 7588.1  0.0   545344.0 394801.0 5609920.0  4050654.1  87952.0 83637.7 11392.0 10437.9   4592  327.582   9      8.855  336.437
68096.0 68096.0  0.0    0.0   545344.0   0.0    5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 46918.8  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 46922.8  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 46937.1  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 46937.1  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 46937.1  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 64190.0  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 64190.0  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 64190.0  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 64190.0  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 64190.0  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 82152.3  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 82152.3  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 82152.3  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 82156.4  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 82156.4  5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 101737.5 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 101737.5 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 103581.5 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 103581.5 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 103581.5 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 124812.4 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 124812.4 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578
68096.0 68096.0  0.0    0.0   545344.0 124814.5 5609920.0  4043257.0  87952.0 83637.7 11392.0 10437.9   4592  327.582   9     12.997  340.578

手動強制Full gc 以後發現，記憶體並沒有被釋放，說明當前系統可能存在記憶體洩漏，導致物件不能被清理釋放【OC：老年代空間，OU ：老年代使用空間（KB）】。
存在記憶體洩漏，主要是當前的物件引用沒有被釋放導致，比如殭屍執行緒的存在。說明當前系統可能存在大量的殭屍執行緒。進而進行進一步的排查

  • 檢視當前系統執行緒情況：jstack。可以看到當前執行緒的詳細情況
[[email protected]1:/root]# jstack 5511 | head -50
2018-07-20 11:59:27
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.151-b12 mixed mode):

"Keep-Alive-Timer" #19437 daemon prio=8 os_prio=0 tid=0x00007f8d749ce000 nid=0x4995 waiting on condition [0x00007f8bb7b2b000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at sun.net.www.http.KeepAliveCache.run(KeepAliveCache.java:172)
    at java.lang.Thread.run(Thread.java:748)

"http-nio-9025-exec-201" #19378 daemon prio=5 os_prio=0 tid=0x00007f8c8e3d3000 nid=0x7ffc waiting on condition [0x00007f8b3a724000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000679f4cbd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)

"http-nio-9025-exec-197" #19374 daemon prio=5 os_prio=0 tid=0x00007f8c8e3cc000 nid=0x7ff7 waiting on condition [0x00007f8b3a828000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000679f4cbd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)

"http-nio-9025-exec-196" #19373 daemon prio=5 os_prio=0 tid=0x00007f8c8a06d000 nid=0x7ff3 waiting on condition [0x00007f8b3a8aa000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000679f4cbd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
  • 檢視當前系統的執行緒總數：
jvm 開啟的執行緒數：
[root@bigdata-service-1:/root]# jstack 5511 | wc -l
254132

當前伺服器對不同IP的建立連線數：
[root@bigdata-service-1:/root]# netstat -nat|grep ESTABLISHED|awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn
  10244 10.27.70.185
     26 10.27.70.77
     26 10.24.237.150
     10 10.81.83.121
      7 10.29.148.127
      4 10.80.101.244
      3 10.27.4.125
      2 127.0.0.1
      2 10.80.112.35
      2 10.27.87.167
      2 10.25.0.162
      1 10.80.112.23
      1 106.11.248.20

可以分析出，當前系統對外建立了大量的連線，而且連線沒有釋放，導致系統開啟的執行緒數過多。通過分析連線最多的ip，定位到出現問題的節點

總結問題

從前面的一系列的分析，可以發現，系統底層存在大量的執行緒，導致引用沒法釋放。通過對java的棧資訊分析發現存在大量的ElasticSearch連線執行緒，導致JVM Full Gc 沒法釋放資源。

"elasticsearch[_client_][transport_client_boss][T#4]" #166 daemon prio=5 os_prio=0 tid=0x00007f8c9819e800 nid=0x20e3 runnable [0x00007f8c7403d000]
    - locked <0x0000000674995e98> (a sun.nio.ch.Util$3)
    - locked <0x0000000674995e80> (a java.util.Collections$UnmodifiableSet)
    - locked <0x0000000674986f58> (a sun.nio.ch.EPollSelectorImpl)
    at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:753)
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)

相關推薦

Jvm線上調優實戰（1）

偵探問題根源 通過top指令發現，當前5511的執行緒cup和記憶體的使用率過高： top ： 5511 root 20 0 16.841g 6.088g 5584 S 47.0 39.2 4011:41 java 9

Java並發/多線程系列——線程安全篇（1）

dna critical ron 查看 end 錯誤 完成 cor 數據 創建和啟動Java線程 Java線程是個對象，和其他任何的Java對象一樣。線程是類的實例java.lang.Thread，或該類的子類的實例。除了對象之外，java線程還可以執行代碼。 創建和啟動線

ceph分布式存儲實戰（1）——ceph集群測試主機規劃

monit dep release host eas rst 存儲 實戰 hostname 主機規劃節點磁盤（4塊）網卡（2塊）mem/cpuOSHostName節點1os-ceph-node1/10G私Eth0:dhcp1G/1CentOS Linux release

C#多線程編程（1）--線程，線程池和Task

gpo 第一次 span via 任務隊列 返回值 異步 如果 是你 　　新開了一個多線程編程系列，該系列主要講解C#中的多線程編程。　 利用多線程的目的有2個: 一是防止UI線程被耗時的程序占用，導致界面卡頓；二是能夠利用多核CPU的資源，提高運行效率。 　　我沒有

Spring實戰（1）

手動 之前 ava singleton 標簽 測試 之間 解決 業務邏輯 本博客是參考Spring實戰第四版，對其中重要的知識點進行總結。 Spring是如何簡化java開發的？ 答：（1）基於POJO的輕量級和最小侵入性編程；（2）通過依賴註入和面向接口來松耦合；

靈活強大的MySQL代理中間件ProxySQL應用實戰（1）

sys www 流量 均可 rpm -ivh 硬盤 代理 發的 table 一、常見的Mysql中間件介紹 很多人都會把中間件認為是讀寫分離，其實讀寫分離只是中間件可以提供的一種功能，最主要的功能還是在於他可以分庫分表。下面介紹下常見的開源mysql中間件。 DBProx

ServiceComb實戰 （1）org.springframework.web.HttpMediaTypeNotSupportedException

一、異常現象： @Override @PostMapping(path = "logon") public ResponseEntity<Boolean> logon(@RequestBody UserDTO user) { if (validateUs

springboot實戰（1）springboot基本配置

1 入口類和@SpringBootApplication package com.wuk.springbootHello; import org.springframework.boot.SpringApplication; import org.springframework.b

linux學習筆記-常見問題實戰（1）

現在我們幾個在工作或在面試中可能會遇到的一些linux基礎問題1 定義一個對所有使用者都生效的命令別名：設定別名的命令 alias[[email protected] ~]# alias cls='clear'如上設定只是區域性有效，當系統重啟動或切換使用者時及失效。要想對所有使用者永久有效需要修改

第一行程式碼學習筆記——Material Design實戰（1）

Toolbar 在MD設計中，用ToolBar去取代ActionBar，首先要去style.xml中設定隱藏ActionBar <style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar

演算法的樂趣實戰（1）--匈牙利演算法

在閱讀《演算法的樂趣》的時候，實在難以理解第七章中關於匈牙利演算法的描述，所以劣者在網上搜刮各種資料，整理如下，既為了自己複習之用，也為了後來者的方便 匈牙利演算法解決了舞伴的快速匹配問題，什麼是舞伴快速匹配問題呢？男女雙方都有各自的最優選擇名單，在一輪輪的選擇過後，最

深度學習實戰（1）--手機跑目標檢測模型（YOLO，從DarkNet到Caffe再到NCNN完整打通）

這篇算是關鍵技術貼，YOLO是什麼、DarkNet是什麼、Caffe是什麼、NCNN又是什麼…等等這一系列科普這裡就完全不說了，牽扯實在太多，通過其他帖子有一定的積累後，看這篇就相對容易了。 本文核心：把一個目標檢測模型跑到手機上 整個工作分以下幾個階段： 1

深度學習之PyTorch實戰（1）——基礎學習及搭建環境

　　最近在學習PyTorch框架，買了一本《深度學習之PyTorch實戰計算機視覺》，從學習開始，小編會整理學習筆記，並部落格記錄，希望自己好好學完這本書，最後能熟練應用此框架。 　　PyTorch是美國網際網路巨頭Facebook在深度學習框架Torch的基礎上使用Python重寫的一個全新的深度學習框架，

Elasticserach實戰（1） 資訊檢索概述

我們常用的搜尋引擎是 We 搜尋 是資訊檢索的 個分支，學術上的資訊檢索（ Information trieva l ， 簡稱 IR ）的定義為 資訊檢索是從大規模非結構化資料 （通常是文字）的集合（通 常儲存在計 機上〉中找出滿足使用者資訊需求的資料（通常是文件〉 的過程。

深度學習實戰（1）--手機端跑YOLO目標檢測網路（從DarkNet到Caffe再到NCNN完整打通）

深度學習實戰（1）--手機端跑YOLO目標檢測網路（從DarkNet到Caffe再到NCNN完整打通）   這篇算是關鍵技術貼，YOLO是什麼、DarkNet是什麼、Caffe是什麼、NCNN又是什麼…等等這一系列科普這裡就完全不說了，牽扯實在太多，通過其他帖子有一定的積累後，看這

Keras入門實戰（1）：MNIST手寫數字分類

前面的部落格中已經介紹瞭如何在Ubuntu下安裝Keras深度學習框架。 現在我們使用 Keras 庫來學習手寫數字分類。 我們這裡要解決的問題是：將手寫數字的灰度影象（28 畫素×28 畫素）劃分到 10 個類別 中（0~9）。我們將使用 MNIST 資料集，它是機器學

Spring Boot（二）：實戰（1）——入口程式類

import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.Sprin

Gradle 實戰（1）—— 配置環境變數

背景：Gradle 是一款構建工具，繼 Ant 、Maven 之後的現代構建工具，我會在接下來的博文中陸續介紹，我在工作中是如何使用 Gradle 的。 下載 Gradle 下面是 Gradle 的官方網站地址： Gradle l Modern Ope

機器學習實戰（1）—— 機器學習基礎

機器學習實戰（1）—— 機器學習基礎 老闆：小韓啊，來來來！工程是不是寫夠了啊？ 我：（what!!!）emmmm，還行還行。 老闆：一看你就是寫夠了。最近公司要搞機器學習，你帶頭來學習一下吧！ 我：行啊，工程程式碼我早就不想寫了。那就學習一下吧！

深度學習 - 模型調優經歷（1）

模型調優經歷（1） 背景 遇到問題 思路 解決辦法 背景 樣本規模及劃分