From a192e7f3977f742c4f5572dda7fcd95ff50b5de5 Mon Sep 17 00:00:00 2001
From: Wasabi1234 <sss2855845850@gmail.com>
Date: Fri, 2 Aug 2019 22:57:14 +0800
Subject: [PATCH 1/7] =?UTF-8?q?=E7=AA=81=E7=A0=B4Java=E9=9D=A2=E8=AF=95?=
 =?UTF-8?q?=E7=B3=BB=E5=88=97?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Java/JAVA-Calendar.md                         |   53 +
 ...05\345\255\230\346\250\241\345\236\213.md" |  403 ++++++
 ...76\346\224\266\351\233\206\345\231\250.md" |  221 +++
 ...66\351\233\206\347\256\227\346\263\225.md" |  249 ++++
 ...41\345\256\236\344\276\213\345\214\226.md" |  108 ++
 ...37\346\234\272\345\257\271\350\261\241.md" |  121 ++
 ...75\347\232\204\350\277\207\347\250\213.md" |  275 ++++
 ...43\200\207)---\347\256\200\344\273\213.md" |   28 +
 ...14\347\232\204\347\233\221\346\216\247.md" |   65 +
 ...270\203)---GC-\350\260\203\344\274\230.md" |   26 +
 ...272\214)---VM-\347\233\221\346\216\247.md" |   33 +
 ...01\346\214\207\344\273\244\357\274\211.md" |  243 ++++
 "Java/JVM/JVM\346\214\207\344\273\244.md"     |  217 +++
 ...06\346\236\220\344\271\213synchronized.md" |  145 ++
 ...ava-Fork-Join-\346\241\206\346\236\266.md" |  135 ++
 ...(Object-value)\346\226\271\346\263\225.md" |  116 ++
 ...13---extends-T-\345\222\214---super-T-.md" |  148 ++
 ...--ThreadLocal-\345\216\237\347\220\206.md" |  426 ++++++
 ...a-\347\232\204\346\263\250\350\247\243.md" |    1 +
 ...73\345\212\240\350\275\275\345\231\250.md" |  205 +++
 ...20\347\240\201\345\210\206\346\236\220.md" |  133 ++
 ...47\274\226Stream-DistinctOps,-SliceOps.md" |    1 +
 ...20\347\240\201\345\211\226\346\236\220.md" |  348 +++++
 ...va\344\270\216\347\272\277\347\250\213.md" |   61 +
 ...25\347\232\204\346\274\224\345\217\230.md" |   74 +
 ...31\350\241\250\350\276\276\345\274\217.md" |  197 +++
 ...a\344\270\255\347\232\204BlockingQueue.md" |  795 +++++++++++
 ...4\270\255\347\232\204VO,PO\347\255\211.md" |  156 ++
 ...04\351\224\201\344\274\230\345\214\226.md" |  125 ++
 ...35\347\232\204\345\214\272\345\210\253.md" |   72 +
 ...le\345\205\263\351\224\256\345\255\227.md" |  371 +++++
 ...50\241\345\274\217jdk\345\222\214cglib.md" |  224 +++
 ...25\347\232\204\347\220\206\350\247\243.md" |   87 ++
 ...20\347\240\201\350\247\243\346\236\220.md" |  789 ++++++++++
 ...5\244\207linux\345\221\275\344\273\244.md" |  758 ++++++++++
 ...44\271\213IllegalMonitorStateException.md" |   48 +
 ...DK\345\221\275\344\273\244\350\241\214.md" |   91 ++
 ...r-\347\272\277\347\250\213\346\261\240.md" | 1269 +++++++++++++++++
 ...va\350\257\255\346\263\225\347\263\226.md" |   27 +
 ...\201\350\247\243\346\236\220---HashMap.md" |  714 ++++++++++
 ...41\351\252\214\350\257\201\347\240\201.md" |   12 +
 ...72\346\234\254\346\263\250\350\247\243.md" |   19 +
 ...t-\345\244\232\346\250\241\345\235\227.md" |   16 +
 ...\344\270\200)-\345\257\274\350\257\273.md" |    7 +
 ...02\345\270\270\345\244\204\347\220\206.md" |   17 +
 ...gBoot\351\233\206\346\210\220BootStrap.md" |   11 +
 ...ngBoot\351\233\206\346\210\220RabbitMQ.md" |    9 +
 ...0\220Thymeleaf\346\250\241\346\235\277.md" |   49 +
 ...22\346\235\200\351\241\271\347\233\256.md" |   17 +
 ...gboot\351\233\206\346\210\220Thymeleaf.md" |    6 +
 ...0\351\207\217\347\264\242\345\274\225).md" |   35 +
 ...27\347\232\204\345\274\200\345\217\221.md" |   43 +
 ...72\350\204\232\346\211\213\346\236\266.md" |   89 ++
 ...5\345\212\241\350\260\203\347\224\250).md" |  188 +++
 ...1\344\270\216\345\256\236\347\216\260).md" |  100 ++
 ...37\347\232\204\345\274\200\345\217\221.md" |   96 ++
 ...44\270\200)---\346\246\202\350\277\260.md" |   26 +
 ...\344\270\200)-\347\256\200\344\273\213.md" |    9 +
 ...45\345\222\214\346\266\210\346\201\257.md" |    5 +
 ...55\347\232\204\345\256\236\350\267\265.md" |  103 ++
 ...14\344\270\216\345\217\221\347\216\260.md" |  121 ++
 ...15\345\212\241\344\273\213\347\273\215.md" |   18 +
 ...15\347\275\256\344\270\255\345\277\203.md" |   41 +
 ...\236\346\210\230(\345\215\201)-Hystrix.md" |    5 +
 ...15\345\212\241\346\213\206\345\210\206.md" |   95 ++
 ...0\216@Resource\344\271\213\344\272\211.md" |  236 +++
 .../Spring--Http\346\272\220\347\240\201.md"  |  541 +++++++
 ...44\270\255\346\226\207\347\211\210-3-9.md" |  697 +++++++++
 ...50\345\237\237\347\256\241\347\220\206.md" |  172 +++
 ...37\345\221\275\345\221\250\346\234\237.md" |   24 +
 ...13\345\212\241\347\256\241\347\220\206.md" |   42 +
 ...35\350\265\226\346\263\250\345\205\245.md" |  593 ++++++++
 Java/Spring/SpringBean.md                     |  449 ++++++
 ...37\347\220\206\350\257\246\350\247\243.md" |  269 ++++
 Java/Spring/SpringMVC-Restful.md              |    4 +
 ...06\346\213\246\346\210\252\345\231\250.md" |   75 +
 ...13@CookieValue\346\263\250\350\247\243.md" |   21 +
 ...3\345\214\226\345\257\271\346\257\224).md" |  575 ++++++++
 ...50\345\261\200\345\274\202\345\270\270.md" |   92 ++
 ...60\346\215\256\347\273\221\345\256\232.md" |  723 ++++++++++
 ...50\350\247\243\350\257\264\346\230\216.md" |   12 +
 ...40\344\270\216\351\235\242\350\257\225.md" |  128 ++
 ...\350\277\207\347\250\213(\344\270\212).md" |  174 +++
 ...03\346\200\247\345\215\261\351\231\251.md" |  322 +++++
 ...346\200\247Performance-and-Scalability.md" |  320 +++++
 ...5\274\217\351\224\201-(Explicit-Locks).md" |  362 +++++
 ...05\267-(Building-Custom-Synchronizers).md" |  783 ++++++++++
 ...ic-Variables-and-Non-blocking-Synchron.md" |  300 ++++
 ...5\255\230\346\250\241\345\236\213(JMM).md" |  326 +++++
 ...04\345\273\272\346\250\241\345\235\227.md" |  128 ++
 ...46\211\247\350\241\214(Task-Execution).md" |  152 ++
 ...10\344\270\216\345\205\263\351\227\255.md" |  185 +++
 ...40\347\232\204\344\275\277\347\224\250.md" |  146 ++
 ...71\345\205\250\346\200\273\347\273\223.md" |  874 ++++++++++++
 ...\222\214Docker\347\256\200\344\273\213.md" |   14 +
 ...34\346\233\264\344\272\244\347\273\207.md" |  139 ++
 ...257\225(00) - \350\257\264\346\230\216.md" |   96 ++
 ...\345\270\210\346\213\233\350\201\230JD.md" |   21 +
 ...350\277\20710\344\270\207+\357\274\237.md" |   45 +
 ...40\347\202\271\350\257\264\346\230\216.md" |   47 +
 ...00\346\234\257\351\200\211\345\236\213.md" |  131 ++
 ...30\345\217\257\347\224\250\346\200\247.md" |   99 ++
 ...10\350\264\271\346\225\260\346\215\256.md" |   60 +
 ...40\344\270\252\345\260\217\346\227\266.md" |   60 +
 ...0\346\201\257\351\230\237\345\210\227?.md" |   46 +
 ...42\350\257\225\346\212\200\345\267\247.md" |   24 +
 ...16\350\277\236\347\216\257\347\202\256.md" |   32 +
 ...16\347\232\204\346\236\266\346\236\204.md" |  103 ++
 ...45\344\275\234\346\265\201\347\250\213.md" |  142 ++
 ...50\347\275\262\347\232\204\345\221\242.md" |   27 +
 ...00\345\267\247\346\200\273\347\273\223.md" |    0
 ...00\344\270\252\351\227\256\351\242\230.md" |   61 +
 ...77\347\250\213\346\250\241\345\236\213.md" |   92 ++
 ...02\347\224\250\345\234\272\346\231\257.md" |  108 ++
 ...344\270\200\344\270\252LRU\357\274\237.md" |  110 ++
 ...12\351\253\230\345\217\257\347\224\250.md" |   35 +
 ...13\345\217\212\345\216\237\347\220\206.md" |   92 ++
 ...30\345\217\257\347\224\250\346\200\247.md" |   25 +
 ...50\345\205\265\346\236\266\346\236\204.md" |   82 ++
 ...42\345\244\261\351\227\256\351\242\230.md" |   70 +
 ...25\345\261\202\345\216\237\347\220\206.md" |   84 ++
 ...05\345\214\226\346\234\272\345\210\266.md" |  132 ++
 ...17\347\232\204\345\216\237\347\220\206.md" |  260 ++++
 ...77\351\200\217\351\227\256\351\242\230.md" |   38 +
 ...56\344\270\200\350\207\264\346\200\247.md" |  224 +++
 ...36\344\272\211\351\227\256\351\242\230.md" |   24 +
 ...16\344\271\210\346\240\267\347\232\204.md" |   31 +
 ...00\345\267\247\346\200\273\347\273\223.md" |   25 +
 ...37\350\277\236\347\216\257\347\202\256.md" |   53 +
 ...5\225\245\350\246\201\347\224\250dubbo.md" |   84 ++
 ...45\344\275\234\345\216\237\347\220\206.md" |   52 +
 ...01\347\232\204\345\215\217\350\256\256.md" |   66 +
 ...06\347\232\204\347\255\226\347\225\245.md" |   80 ++
 ...347\232\204SPI\346\234\272\345\210\266.md" |  137 ++
 ...45\345\217\212\351\207\215\350\257\225.md" |  154 ++
 ...04\345\271\202\347\255\211\346\200\247.md" |   67 +
 ...04\351\241\272\345\272\217\346\200\247.md" |   43 +
 ...347\232\204RPC\346\241\206\346\236\266.md" |   41 +
 ...02\347\224\250\345\234\272\346\231\257.md" |   67 +
 ...60\347\232\204\344\274\230\345\212\243.md" |  398 ++++++
 ...10\347\232\204\345\256\236\347\216\260.md" |  154 ++
 ...43\345\206\263\346\226\271\346\241\210.md" |  198 +++
 ...66\346\236\204\350\256\276\350\256\241.md" |  110 ++
 ...06\345\272\223\345\210\206\350\241\250.md" |  171 +++
 ...50\347\232\204\345\256\236\350\267\265.md" |   71 +
 ...06\345\272\223\345\210\206\350\241\250.md" |  108 ++
 ...id\347\232\204\347\224\237\346\210\220.md" |  278 ++++
 ...43\345\206\263\346\226\271\346\241\210.md" |  104 ++
 ...56\345\216\273\345\223\252\344\272\206.md" |   95 ++
 ...04\351\241\272\345\272\217\346\200\247.md" |   55 +
 ...24\350\277\233\350\277\207\347\250\213.md" |  188 +++
 .../1.md"                                     |  138 ++
 ...15\347\272\247\346\234\272\345\210\266.md" |   80 ++
 ...76\350\256\241\345\216\237\345\210\231.md" |   95 ++
 ...47\345\260\217\346\216\247\345\210\266.md" |  182 +++
 ...45\350\257\242\346\216\245\345\217\243.md" |  386 +++++
 ...11\345\205\250\344\277\235\346\212\244.md" |   40 +
 ...41\347\232\204\346\200\273\347\273\223.md" |   37 +
 ...73\344\270\216\351\231\220\346\265\201.md" |   67 +
 ...\256\241(0) - \345\257\274\350\257\273.md" |   20 +
 ...20\347\273\264\347\233\221\346\216\247.md" |   54 +
 ...76\350\256\241\345\216\237\345\210\231.md" |  103 ++
 ...06\346\236\266\350\257\264\346\230\216.md" |  130 ++
 163 files changed, 26105 insertions(+)
 create mode 100644 Java/JAVA-Calendar.md
 create mode 100644 "Java/JVM/JVM\345\256\236\346\210\230---\345\206\205\345\255\230\346\250\241\345\236\213.md"
 create mode 100644 "Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\345\231\250.md"
 create mode 100644 "Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\347\256\227\346\263\225.md"
 create mode 100644 "Java/JVM/JVM\345\256\236\346\210\230---\345\257\271\350\261\241\345\256\236\344\276\213\345\214\226.md"
 create mode 100644 "Java/JVM/JVM\345\256\236\346\210\230---\346\216\242\347\247\230HotSpot\350\231\232\346\213\237\346\234\272\345\257\271\350\261\241.md"
 create mode 100644 "Java/JVM/JVM\345\256\236\346\210\230---\347\261\273\345\212\240\350\275\275\347\232\204\350\277\207\347\250\213.md"
 create mode 100644 "Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\343\200\207)---\347\256\200\344\273\213.md"
 create mode 100644 "Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\200)---\345\237\272\344\272\216JDK\345\221\275\344\273\244\350\241\214\347\232\204\347\233\221\346\216\247.md"
 create mode 100644 "Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\203)---GC-\350\260\203\344\274\230.md"
 create mode 100644 "Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\272\214)---VM-\347\233\221\346\216\247.md"
 create mode 100644 "Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\345\205\253)---Java\344\273\243\347\240\201\345\261\202\350\260\203\344\274\230\357\274\210\345\255\227\350\212\202\347\240\201\346\214\207\344\273\244\357\274\211.md"
 create mode 100644 "Java/JVM/JVM\346\214\207\344\273\244.md"
 create mode 100644 "Java/JVM/JVM\346\272\220\347\240\201\345\210\206\346\236\220\344\271\213synchronized.md"
 create mode 100644 "Java/Java-Fork-Join-\346\241\206\346\236\266.md"
 create mode 100644 "Java/Java-Map\347\232\204containsKey(Object-key)\345\222\214containsValue(Object-value)\346\226\271\346\263\225.md"
 create mode 100644 "Java/Java-\346\263\233\345\236\213\350\247\243\346\203\221\344\271\213---extends-T-\345\222\214---super-T-.md"
 create mode 100644 "Java/Java-\346\272\220\347\240\201\350\247\243\346\236\220\345\256\236\346\210\230---ThreadLocal-\345\216\237\347\220\206.md"
 create mode 100644 "Java/Java-\347\232\204\346\263\250\350\247\243.md"
 create mode 100644 "Java/Java-\347\261\273\345\212\240\350\275\275\345\231\250.md"
 create mode 100644 "Java/Java8-\345\216\237\345\255\220\345\274\271\347\261\273\344\271\213LongAdder\346\272\220\347\240\201\345\210\206\346\236\220.md"
 create mode 100644 "Java/Java8\346\265\201\347\274\226Stream-DistinctOps,-SliceOps.md"
 create mode 100644 "Java/Java8\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220-Hashtable\346\272\220\347\240\201\345\211\226\346\236\220.md"
 create mode 100644 "Java/Java\344\270\216\347\272\277\347\250\213.md"
 create mode 100644 "Java/Java\344\270\255Collections-sort()\346\226\271\346\263\225\347\232\204\346\274\224\345\217\230.md"
 create mode 100644 "Java/Java\344\270\255\346\255\243\345\210\231\350\241\250\350\276\276\345\274\217.md"
 create mode 100644 "Java/Java\344\270\255\347\232\204BlockingQueue.md"
 create mode 100644 "Java/Java\344\270\255\347\232\204VO,PO\347\255\211.md"
 create mode 100644 "Java/Java\344\270\255\347\232\204\351\224\201\344\274\230\345\214\226.md"
 create mode 100644 "Java/Java\344\270\255\347\261\273\345\236\213\345\217\202\346\225\260\342\200\234-T-\342\200\235\345\222\214\346\227\240\347\225\214\351\200\232\351\205\215\347\254\246\342\200\234---\342\200\235\347\232\204\345\214\272\345\210\253.md"
 create mode 100644 "Java/Java\345\206\205\345\255\230\346\250\241\345\236\213\344\270\216volatile\345\205\263\351\224\256\345\255\227.md"
 create mode 100644 "Java/Java\345\212\250\346\200\201\344\273\243\347\220\206\346\250\241\345\274\217jdk\345\222\214cglib.md"
 create mode 100644 "Java/Java\345\244\232\347\272\277\347\250\213\344\270\255join\346\226\271\346\263\225\347\232\204\347\220\206\350\247\243.md"
 create mode 100644 "Java/Java\345\257\271\350\261\241\345\272\217\345\210\227\345\214\226\345\272\225\345\261\202\345\216\237\347\220\206\346\272\220\347\240\201\350\247\243\346\236\220.md"
 create mode 100644 "Java/Java\345\274\200\345\217\221\344\272\272\345\221\230\345\277\205\345\244\207linux\345\221\275\344\273\244.md"
 create mode 100644 "Java/Java\345\274\202\345\270\270\344\271\213IllegalMonitorStateException.md"
 create mode 100644 "Java/Java\346\200\247\350\203\275\350\260\203\344\274\230\345\267\245\345\205\267\344\271\213JDK\345\221\275\344\273\244\350\241\214.md"
 create mode 100644 "Java/Java\346\272\220\347\240\201\350\247\243\346\236\220---ThreadPoolExecutor-\347\272\277\347\250\213\346\261\240.md"
 create mode 100644 "Java/Java\350\257\255\346\263\225\347\263\226.md"
 create mode 100644 "Java/Java\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220---HashMap.md"
 create mode 100644 "Java/Spring Boot/SpringBoot+Security-\345\217\221\351\200\201\347\237\255\344\277\241\351\252\214\350\257\201\347\240\201.md"
 create mode 100644 "Java/Spring Boot/SpringBoot-\344\270\211\345\244\247\345\237\272\346\234\254\346\263\250\350\247\243.md"
 create mode 100644 "Java/Spring Boot/SpringBoot-\345\244\232\346\250\241\345\235\227.md"
 create mode 100644 "Java/Spring Boot/SpringBoot2-0\345\223\215\345\272\224\345\274\217\347\274\226\347\250\213\347\263\273\345\210\227(\344\270\200)-\345\257\274\350\257\273.md"
 create mode 100644 "Java/Spring Boot/SpringBoot\347\273\237\344\270\200\345\274\202\345\270\270\345\244\204\347\220\206.md"
 create mode 100644 "Java/Spring Boot/SpringBoot\351\233\206\346\210\220BootStrap.md"
 create mode 100644 "Java/Spring Boot/SpringBoot\351\233\206\346\210\220RabbitMQ.md"
 create mode 100644 "Java/Spring Boot/SpringBoot\351\233\206\346\210\220Thymeleaf\346\250\241\346\235\277.md"
 create mode 100644 "Java/Spring Boot/Springboot-\347\247\222\346\235\200\351\241\271\347\233\256.md"
 create mode 100644 "Java/Spring Boot/Springboot\351\233\206\346\210\220Thymeleaf.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\203)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\212\240\350\275\275\345\205\250\351\207\217\347\264\242\345\274\225).md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\211)---\351\200\232\347\224\250\346\250\241\345\235\227\347\232\204\345\274\200\345\217\221.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\214)---\346\220\255\345\273\272\350\204\232\346\211\213\346\236\266.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\224)---\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\276\256\346\234\215\345\212\241\350\260\203\347\224\250).md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\205\255)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\271\277\345\221\212\346\225\260\346\215\256\347\264\242\345\274\225\347\232\204\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260).md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\233\233)---\346\212\225\346\224\276\347\263\273\347\273\237\347\232\204\345\274\200\345\217\221.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260(\344\270\200)---\346\246\202\350\277\260.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\200)-\347\256\200\344\273\213.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\345\274\202\346\255\245\345\222\214\346\266\210\346\201\257.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\346\266\210\346\201\257\346\234\215\345\212\241\345\234\250\347\224\265\345\225\206\344\270\255\347\232\204\345\256\236\350\267\265.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\211)-\346\234\215\345\212\241\346\263\250\345\206\214\344\270\216\345\217\221\347\216\260.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\272\214)-\345\276\256\346\234\215\345\212\241\344\273\213\347\273\215.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\205\255)-\347\273\237\344\270\200\351\205\215\347\275\256\344\270\255\345\277\203.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\215\201)-Hystrix.md"
 create mode 100644 "Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\233\233)-\345\276\256\346\234\215\345\212\241\344\270\255\347\232\204\346\234\215\345\212\241\346\213\206\345\210\206.md"
 create mode 100644 "Java/Spring/@Autowired-\344\270\216@Resource\344\271\213\344\272\211.md"
 create mode 100644 "Java/Spring/Spring--Http\346\272\220\347\240\201.md"
 create mode 100644 "Java/Spring/Spring-5-0\344\270\255\346\226\207\347\211\210-3-9.md"
 create mode 100644 "Java/Spring/Spring-Bean\347\232\204\344\275\234\347\224\250\345\237\237\347\256\241\347\220\206.md"
 create mode 100644 "Java/Spring/Spring-Bean\347\232\204\347\224\237\345\221\275\345\221\250\346\234\237.md"
 create mode 100644 "Java/Spring/Spring-\344\272\213\345\212\241\347\256\241\347\220\206.md"
 create mode 100644 "Java/Spring/Spring-\345\256\236\346\210\230---IoC\345\256\271\345\231\250\347\232\204\344\276\235\350\265\226\346\263\250\345\205\245.md"
 create mode 100755 Java/Spring/SpringBean.md
 create mode 100755 "Java/Spring/SpringMVC \345\267\245\344\275\234\345\216\237\347\220\206\350\257\246\350\247\243.md"
 create mode 100644 Java/Spring/SpringMVC-Restful.md
 create mode 100644 "Java/Spring/SpringMVC-\347\232\204\345\244\204\347\220\206\346\213\246\346\210\252\345\231\250.md"
 create mode 100644 "Java/Spring/SpringMVC\344\271\213@CookieValue\346\263\250\350\247\243.md"
 create mode 100644 "Java/Spring/SpringMVC\344\271\213Controller\346\237\245\346\211\276(Spring4-0-3-Spring5-0-4\346\272\220\347\240\201\350\277\233\345\214\226\345\257\271\346\257\224).md"
 create mode 100644 "Java/Spring/SpringMVC\345\205\250\345\261\200\345\274\202\345\270\270.md"
 create mode 100644 "Java/Spring/SpringMVC\346\225\260\346\215\256\347\273\221\345\256\232.md"
 create mode 100644 "Java/Spring/SpringMVC\347\232\204@ResponseBody\346\263\250\350\247\243\350\257\264\346\230\216.md"
 create mode 100755 "Java/Spring/Spring\345\255\246\344\271\240\344\270\216\351\235\242\350\257\225.md"
 create mode 100644 "Java/Spring/Spring\346\272\220\347\240\201\350\247\243\346\236\220-IoC\345\256\271\345\231\250\347\232\204\345\210\235\345\247\213\345\214\226\350\277\207\347\250\213(\344\270\212).md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22710\344\271\213\351\201\277\345\205\215\346\264\273\350\267\203\346\200\247\345\215\261\351\231\251.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22711\344\271\213\346\200\247\350\203\275\344\270\216\345\217\257\344\274\270\347\274\251\346\200\247Performance-and-Scalability.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22713\344\271\213\346\230\276\345\274\217\351\224\201-(Explicit-Locks).md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22714\344\271\213\346\236\204\345\273\272\350\207\252\345\256\232\344\271\211\347\232\204\345\220\214\346\255\245\345\267\245\345\205\267-(Building-Custom-Synchronizers).md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22715\344\271\213\345\216\237\345\255\220\351\201\215\345\216\206\344\270\216\351\235\236\351\230\273\345\241\236\345\220\214\346\255\245\346\234\272\345\210\266(Atomic-Variables-and-Non-blocking-Synchron.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22716\344\271\213Java\345\206\205\345\255\230\346\250\241\345\236\213(JMM).md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2275\344\271\213\345\237\272\347\241\200\346\236\204\345\273\272\346\250\241\345\235\227.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2276\344\271\213\344\273\273\345\212\241\346\211\247\350\241\214(Task-Execution).md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2277\344\271\213\345\217\226\346\266\210\344\270\216\345\205\263\351\227\255.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2278\344\271\213\347\272\277\347\250\213\346\261\240\347\232\204\344\275\277\347\224\250.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\347\237\245\350\257\206\347\202\271\345\205\250\346\200\273\347\273\223.md"
 create mode 100644 "Java/\345\271\266\345\217\221\347\274\226\347\250\213/\345\217\262\344\270\212\346\234\200\345\277\253Docker\345\205\245\351\227\250!(\344\270\200)-\345\256\271\345\231\250\346\212\200\346\234\257\345\222\214Docker\347\256\200\344\273\213.md"
 create mode 100755 "\350\201\214\344\270\232\345\217\221\345\261\225/\346\274\253\346\274\253\345\244\247\345\255\246\346\261\237\346\271\226\345\275\225 - \347\210\261\344\270\216\346\201\250\345\224\257\344\270\216\345\267\245\344\275\234\346\233\264\344\272\244\347\273\207.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(00) - \350\257\264\346\230\216.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(01)-\347\216\260\344\273\243\344\272\222\350\201\224\347\275\221java\345\267\245\347\250\213\345\270\210\346\213\233\350\201\230JD.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(02) - Redis\345\246\202\344\275\225\351\200\232\350\277\207\350\257\273\345\206\231\345\210\206\347\246\273\346\235\245\346\211\277\350\275\275\350\257\273\350\257\267\346\261\202QPS\350\266\205\350\277\20710\344\270\207+\357\274\237.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(03)-\345\205\263\344\272\216\344\272\222\350\201\224\347\275\221Java\345\267\245\347\250\213\345\270\210\351\235\242\350\257\225\347\252\201\345\207\273\350\256\255\347\273\203\350\257\276\347\250\213\347\232\204\345\207\240\347\202\271\350\257\264\346\230\216.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(05)- \346\266\210\346\201\257\351\230\237\345\210\227\346\212\200\346\234\257\351\200\211\345\236\213.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(06)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\253\230\345\217\257\347\224\250\346\200\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(07)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\344\270\215\351\207\215\345\244\215\346\266\210\350\264\271\346\225\260\346\215\256.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(10)-\347\231\276\344\270\207\346\266\210\346\201\257\345\234\250\346\266\210\346\201\257\351\230\237\345\210\227\351\207\214\347\247\257\345\216\213\344\272\206\345\207\240\344\270\252\345\260\217\346\227\266.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(11)-\344\275\240\346\200\216\344\271\210\350\256\276\350\256\241\344\270\200\344\270\252\346\266\210\346\201\257\351\230\237\345\210\227?.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(12) - \346\200\273\347\273\223\346\266\210\346\201\257\351\230\237\345\210\227\347\233\270\345\205\263\351\227\256\351\242\230\347\232\204\351\235\242\350\257\225\346\212\200\345\267\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(13)\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\350\277\236\347\216\257\347\202\256.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(14)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\347\232\204\346\236\266\346\236\204.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(15)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216Elastic Search\347\232\204\345\267\245\344\275\234\346\265\201\347\250\213.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(17)-\344\275\240\344\273\254\345\205\254\345\217\270\347\224\237\344\272\247\347\216\257\345\242\203\347\232\204\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\346\230\257\346\200\216\344\271\210\351\203\250\347\275\262\347\232\204\345\221\242.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(18)-\346\266\210\346\201\257\351\230\237\345\210\227\351\235\242\350\257\225\346\212\200\345\267\247\346\200\273\347\273\223.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(19) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\347\232\204\347\254\254\344\270\200\344\270\252\351\227\256\351\242\230.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(20)-Redis\347\272\277\347\250\213\346\250\241\345\236\213.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(21) - redis\346\234\211\345\223\252\344\272\233\346\225\260\346\215\256\347\261\273\345\236\213,\350\260\210\350\260\210\351\200\202\347\224\250\345\234\272\346\231\257.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(22) - Redis\347\232\204\350\277\207\346\234\237\347\255\226\347\225\245\357\274\237\346\211\213\345\206\231\344\270\200\344\270\252LRU\357\274\237.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23)-\345\246\202\344\275\225\344\277\235\350\257\201redis\351\253\230\345\271\266\345\217\221\345\217\212\351\253\230\345\217\257\347\224\250.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-4)-\345\206\215\346\267\261\345\205\245Redis Replication\347\232\204\345\256\214\346\225\264\346\211\247\350\241\214\346\265\201\347\250\213\345\217\212\345\216\237\347\220\206.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-6)-\344\270\273\344\273\216\346\236\266\346\236\204\344\270\213\347\232\204Redis\345\246\202\344\275\225\345\201\232\345\210\260\351\253\230\345\217\257\347\224\250\346\200\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-7) - Redis\347\232\204\345\223\250\345\205\265\346\236\266\346\236\204.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-8) - Redis\345\223\250\345\205\265\344\270\273\345\244\207\345\210\207\346\215\242\347\232\204\346\225\260\346\215\256\344\270\242\345\244\261\351\227\256\351\242\230.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-9) - \346\267\261\345\205\245\350\247\243\346\236\220Redis\345\223\250\345\205\265\345\272\225\345\261\202\345\216\237\347\220\206.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(24)-Redis\347\232\204\346\214\201\344\271\205\345\214\226\346\234\272\345\210\266.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(25) - Redis cluster\351\233\206\347\276\244\346\250\241\345\274\217\347\232\204\345\216\237\347\220\206.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(26)-\350\257\264\350\257\264\345\246\202\344\275\225\345\272\224\345\257\271\347\274\223\345\255\230\351\233\252\345\264\251\344\273\245\345\217\212\347\251\277\351\200\217\351\227\256\351\242\230.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(27) - \345\246\202\344\275\225\344\277\235\350\257\201\347\274\223\345\255\230\344\270\216\346\225\260\346\215\256\345\272\223\347\232\204\346\225\260\346\215\256\344\270\200\350\207\264\346\200\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(28) - \345\246\202\344\275\225\350\247\243\345\206\263Redis\347\232\204\345\271\266\345\217\221\347\253\236\344\272\211\351\227\256\351\242\230.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(29) - \347\224\237\344\272\247\347\216\257\345\242\203\347\232\204redis\351\233\206\347\276\244\347\232\204\351\203\250\347\275\262\346\236\266\346\236\204\346\230\257\346\200\216\344\271\210\346\240\267\347\232\204.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(30) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230\345\233\236\347\255\224\346\212\200\345\267\247\346\200\273\347\273\223.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(31)-\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\350\277\236\347\216\257\347\202\256.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(32)-\344\270\272\344\273\200\344\271\210\350\246\201\346\212\212\347\263\273\347\273\237\346\213\206\345\210\206\346\210\220\345\210\206\345\270\203\345\274\217\347\232\204\357\274\237\344\270\272\345\225\245\350\246\201\347\224\250dubbo.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(33)-Dubbo\347\232\204\345\267\245\344\275\234\345\216\237\347\220\206.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(34)-dubbo\346\224\257\346\214\201\347\232\204\345\215\217\350\256\256.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(35)-Dubbo\350\264\237\350\275\275\345\235\207\350\241\241\345\217\212\345\212\250\346\200\201\344\273\243\347\220\206\347\232\204\347\255\226\347\225\245.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(36)-\350\201\212\350\201\212Dubbo\347\232\204SPI\346\234\272\345\210\266.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(37)-\345\237\272\344\272\216Dubbo\347\232\204\346\234\215\345\212\241\346\262\273\347\220\206\343\200\201\346\234\215\345\212\241\351\231\215\347\272\247\344\273\245\345\217\212\351\207\215\350\257\225.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(38)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\345\271\202\347\255\211\346\200\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(39)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\350\257\267\346\261\202\347\232\204\351\241\272\345\272\217\346\200\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(40)-\345\246\202\344\275\225\350\256\276\350\256\241\344\270\200\344\270\252\347\261\273\344\274\274Dubbo\347\232\204RPC\346\241\206\346\236\266.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(41)-ZooKeeper\347\232\204\351\200\202\347\224\250\345\234\272\346\231\257.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(42) - Redis & ZooKeeper\344\270\244\347\247\215\345\210\206\345\270\203\345\274\217\351\224\201\345\256\236\347\216\260\347\232\204\344\274\230\345\212\243.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(43)-\345\210\206\345\270\203\345\274\217Session\346\226\271\346\241\210\347\232\204\345\256\236\347\216\260.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(44)-\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241\350\247\243\345\206\263\346\226\271\346\241\210.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(45)-\351\253\230\345\271\266\345\217\221\347\263\273\347\273\237\347\232\204\346\236\266\346\236\204\350\256\276\350\256\241.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(46)-\345\210\206\345\272\223\345\210\206\350\241\250.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(47)-\345\210\206\345\272\223\345\210\206\350\241\250\347\232\204\345\256\236\350\267\265.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(48)-\350\256\276\350\256\241\345\217\257\345\212\250\346\200\201\346\211\251\345\256\271\347\274\251\347\232\204\345\210\206\345\272\223\345\210\206\350\241\250.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(49)-\345\210\206\345\272\223\345\210\206\350\241\250\344\271\213\345\220\216\345\205\250\345\261\200id\347\232\204\347\224\237\346\210\220.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(50)-MySQL\350\257\273\345\206\231\345\210\206\347\246\273\345\217\212\344\270\273\344\273\216\345\220\214\346\255\245\345\273\266\346\227\266\350\247\243\345\206\263\346\226\271\346\241\210.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(8)-MQ\347\232\204\346\225\260\346\215\256\345\216\273\345\223\252\344\272\206.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(9)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\241\272\345\272\217\346\200\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\357\274\21053\357\274\211- \345\210\206\345\270\203\345\274\217\346\236\266\346\236\204\347\232\204\346\274\224\350\277\233\350\277\207\347\250\213.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/1.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/13_\345\274\200\345\217\221\345\223\201\347\211\214\345\220\215\347\247\260\350\216\267\345\217\226\346\216\245\345\217\243\347\232\204\345\237\272\344\272\216\346\234\254\345\234\260\347\274\223\345\255\230\347\232\204fallback\351\231\215\347\272\247\346\234\272\345\210\266.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\347\252\201\347\240\264Java\351\235\242\350\257\225-hystrix\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\345\217\212\350\256\276\350\256\241\345\216\237\345\210\231.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(10)-Hystrix\347\232\204\347\272\277\347\250\213\346\261\240+\346\234\215\345\212\241+\346\216\245\345\217\243\345\210\222\345\210\206\344\273\245\345\217\212\350\265\204\346\272\220\346\261\240\347\232\204\345\256\271\351\207\217\345\244\247\345\260\217\346\216\247\345\210\266.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(12) - \345\237\272\344\272\216request cache\350\257\267\346\261\202\347\274\223\345\255\230\346\212\200\346\234\257\344\274\230\345\214\226\346\211\271\351\207\217\345\225\206\345\223\201\346\225\260\346\215\256\346\237\245\350\257\242\346\216\245\345\217\243.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(16) - \345\237\272\344\272\216timeout\346\234\272\345\210\266\346\235\245\344\270\272\345\225\206\345\223\201\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\350\260\203\347\224\250\350\266\205\346\227\266\346\217\220\344\276\233\345\256\211\345\205\250\344\277\235\346\212\244.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(17) - \345\237\272\344\272\216Hystrix\347\232\204\351\253\230\345\217\257\347\224\250\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\346\200\273\347\273\223.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(9) - \345\237\272\344\272\216Hystrix\347\232\204\344\277\241\345\217\267\351\207\217\346\212\200\346\234\257\345\257\271\345\234\260\347\220\206\344\275\215\347\275\256\350\216\267\345\217\226\351\200\273\350\276\221\350\277\233\350\241\214\350\265\204\346\272\220\351\232\224\347\246\273\344\270\216\351\231\220\346\265\201.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(0) - \345\257\274\350\257\273.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(1) - hystrix\344\270\216\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\357\274\232\350\265\204\346\272\220\351\232\224\347\246\273+\351\231\220\346\265\201+\347\206\224\346\226\255+\351\231\215\347\272\247+\350\277\220\347\273\264\347\233\221\346\216\247.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(2) - hystrix\350\246\201\350\247\243\345\206\263\347\232\204\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\351\227\256\351\242\230\344\273\245\345\217\212\345\205\266\350\256\276\350\256\241\345\216\237\345\210\231.md"
 create mode 100644 "\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(3) -\347\224\265\345\225\206\345\225\206\345\223\201\350\257\246\346\203\205\351\241\265\347\274\223\345\255\230\350\203\214\346\231\257\345\217\212\346\241\206\346\236\266\350\257\264\346\230\216.md"

diff --git a/Java/JAVA-Calendar.md b/Java/JAVA-Calendar.md
new file mode 100644
index 0000000000..64594b83ad
--- /dev/null
+++ b/Java/JAVA-Calendar.md
@@ -0,0 +1,53 @@
+ Calendar.getInstance() 中所获得的实例就是一个 "GreogrianCalendar" 对象(与通过 new GregorianCalendar() 获得的结果一致)。
+
+#Calendar 与 Date 的转换
+Calendar calendar = Calendar.getInstance();
+// 从一个 Calendar 对象中获取 Date 对象
+Date date = calendar.getTime();
+// 将 Date 对象反应到一个 Calendar 对象中，
+// Calendar/GregorianCalendar 没有构造函数可以接受 Date 对象
+// 所以我们必需先获得一个实例，然后设置 Date 对象
+calendar.setTime(date);
+#注意的事项：
+##1. Calendar 的 set() 方法
+
+set(int field, int value) - 是用来设置"年/月/日/小时/分钟/秒/微秒"等值
+
+field 的定义在 Calendar 中
+
+set(int year, int month, int day, int hour, int minute, int second) 但没有
+
+set(int year, int month, int day, int hour, int minute, int second, int millisecond) 前面 set(int,int,int,int,int,int) 方法不会自动将 MilliSecond 清为 0。
+
+另外，月份的起始值为０而不是１，所以要设置八月时，我们用７而不是8。
+
+calendar.set(Calendar.MONTH, 7);
+
+我们通常需要在程序逻辑中将它清为 0， Calendar 不是马上就刷新其内部的记录
+
+在 Calendar 的方法中，get() 和 add() 会让 Calendar 立刻刷新。Set() 的这个特性会给我们的开发带来一些意想不到的结果。
+##add() 与 roll() 的区别
+
+add() 的功能非常强大，add 可以对 Calendar 的字段进行计算。如果需要减去值，那么使用负数值就可以了，如 add(field, -value)。
+
+add() 有两条规则：
+
+当被修改的字段超出它可以的范围时，那么比它大的字段会自动修正。如：
+Calendar cal1 = Calendar.getInstance();
+cal1.set(2000, 7, 31, 0, 0 , 0); //2000-8-31
+cal1.add(Calendar.MONTH, 1); //2000-9-31 => 2000-10-1，对吗？
+System.out.println(cal1.getTime()); //结果是 2000-9-30
+
+另一个规则是，如果比它小的字段是不可变的（由 Calendar 的实现类决定），那么该小字段会修正到变化最小的值。
+
+以上面的例子，9-31 就会变成 9-30，因为变化最小。
+
+Roll() 的规则只有一条：
+当被修改的字段超出它可以的范围时，那么比它大的字段不会被修正。如：
+
+Calendar cal1 = Calendar.getInstance();
+cal1.set(1999, 5, 6, 0, 0, 0); //1999-6-6, 周日
+cal1.roll(Calendar.WEEK_OF_MONTH, -1); //1999-6-1, 周二
+cal1.set(1999, 5, 6, 0, 0, 0); //1999-6-6, 周日
+cal1.add(Calendar.WEEK_OF_MONTH, -1); //1999-5-30, 周日
+WEEK_OF_MONTH 比 MONTH 字段小，所以 roll 不能修正 MONTH 字段。
diff --git "a/Java/JVM/JVM\345\256\236\346\210\230---\345\206\205\345\255\230\346\250\241\345\236\213.md" "b/Java/JVM/JVM\345\256\236\346\210\230---\345\206\205\345\255\230\346\250\241\345\236\213.md"
new file mode 100644
index 0000000000..ddf75bcd8b
--- /dev/null
+++ "b/Java/JVM/JVM\345\256\236\346\210\230---\345\206\205\345\255\230\346\250\241\345\236\213.md"
@@ -0,0 +1,403 @@
+# 0 [相关源码](https://github.com/Wasabi1234)
+
+内存是非常重要的系统资源，是硬盘和CPU的中间仓库及桥梁，承载着操作系统和应用程序的实时运行
+JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM的高效稳定运行
+不同的JVM对于内存的划分方式和管理机制存在着部分差异
+结合JVM虚拟机规范，来探讨经典的JVM内存布局
+![JVM内存模型-1](http://upload-images.jianshu.io/upload_images/2614605-246286b040ad10c1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![JVM内存模型-2](https://upload-images.jianshu.io/upload_images/4685968-2502bef3bd1d1692.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 1 Program Counter Register (程序计数寄存器)
+Register 的命名源于CPU的寄存器，CPU只有把数据装载到寄存器才能够运行
+寄存器存储指令相关的现场信息，由于CPU时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。这样必然导致经常中断或恢复，如何保证分毫无差呢?
+每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器用来存放执行指令的偏移量和行号指示器等，线程执行或恢复都要依赖程序计数器。程序计数器在各个线程之间互不影响，此区域也不会发生内存溢出异常。
+
+## 1.1. 定义
+程序计数器是一块较小的内存空间，可看作当前线程正在执行的字节码的行号指示器
+如果当前线程正在执行的是
+- Java方法
+计数器记录的就是当前线程正在执行的字节码指令的地址
+- 本地方法
+那么程序计数器值为undefined                   
+## 1.2. 作用
+程序计数器有两个作用
+- 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
+- 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。 
+## 1.3. 特点
+一块较小的内存空间
+线程私有。每条线程都有一个独立的程序计数器。
+是唯一一个不会出现OOM的内存区域。
+生命周期随着线程的创建而创建，随着线程的结束而死亡。 
+
+#  2. Java虚拟机栈(JVM Stack)
+
+## 2.1. 定义
+相对于基于寄存器的运行环境来说，JVM是基于栈结构的运行环境
+栈结构移植性更好，可控性更强
+JVM中的虚拟机栈是描述Java方法执行的内存区域，它是线程私有的
+
+栈中的元素用于支持虚拟机进行方法调用，每个方法从开始调用到执行完成的过程，就是栈帧从入栈到出栈的过程
+在活动线程中，只有位于栈顶的帧才是有效的，称为`当前栈帧`
+正在执行的方法称为`当前方法`
+栈帧是方法运行的基本结构
+
+在执行引擎运行时，所有指令都只能针对当前栈帧进行操作
+`StackOverflowError`表示请求的栈溢出，导致内存耗尽，通常出现在递归方法中
+JVM能够横扫千军，虚拟机栈就是它的心腹大将，当前方法的栈帧，都是正在战斗的战场，其中的操作栈是参与战斗的士兵
+![操作栈的压栈与出栈](https://upload-images.jianshu.io/upload_images/4685968-a6b55efe15a7a9ed.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+虚拟机栈通过压/出栈的方式，对每个方法对应的活动栈帧进行运算处理，方法正常执行结束，肯定会跳转到另一个栈帧上
+在执行的过程中，如果出现异常，会进行异常回溯，返回地址通过异常处理表确定
+栈帧在整个JVM体系中的地位颇高,包括局部变量表、操作栈、动态连接、方法返回地址等
+- 局部变量表
+存放方法参数和局部变量
+相对于类属性变量的准备阶段和初始化阶段来说，局部变量没有准备阶段，必须显式初始化
+如果是非静态方法，则在index[0]位置上存储的是方法所属对象的实例引用，随后存储的是参数和局部变量
+字节码指令中的STORE指令就是将操作栈中计算完成的局部变量写回局部变量表的存储空间内
+- 操作栈
+操作栈是一个初始状态为空的桶式结构栈
+在方法执行过程中，会有各种指令往栈中写入和提取信息
+JVM的执行引擎是基于栈的执行引擎，其中的栈指的就是操作栈
+字节码指令集的定义都是基于栈类型的,栈的深度在方法元信息的stack属性中
+
+下面用一段简单的代码说明操作栈与局部变量表的交互
+![](https://upload-images.jianshu.io/upload_images/4685968-7d0dd10c4f74fc3d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 详细的字节码操作顺序如下:
+![](https://upload-images.jianshu.io/upload_images/4685968-772b5a46c8180573.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+第1处说明:局部变量表就像个中药柜，里面有很多抽屉,依次编号为0, 1, 2,3，.,. n
+字节码指令`istore_ 1`就是打开1号抽屉，把栈顶中的数13存进去
+栈是一个很深的竖桶，任何时候只能对桶口元素进行操作，所以数据只能在栈顶进行存取
+
+某些指令可以直接在抽屉里进行，比如`inc`指令，直接对抽屉里的数值进行+1操作
+程序员面试过程中，常见的i++和++i的区别，可以从字节码上对比出来
+![i++和++i的区别](https://upload-images.jianshu.io/upload_images/4685968-2cefbb729fa8be63.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- `iload_ 1`  从局部变量表的第1号抽屉里取出一个数,压入栈顶，下一步直接在抽屉里实现+1的操作，而这个操作对栈顶元素的值没有影响
+所以istore_ 2只是把栈顶元素赋值给a
+- 表格右列，先在第1号抽屉里执行+1操作，然后通过iload_ 1 把第1号抽屉里的数压入栈顶，所以istore_ 2存入的是+1之后的值
+
+这里延伸一个信息，i++并非原子操作。即使通过volatile关键字进行修饰，多个线程同时写的话，也会产生数据互相覆盖的问题.
+
+- 动态连接
+每个栈帧中包含一个在常量池中对当前方法的引用，目的是支持方法调用过程的动态连接
+- 方法返回地址
+方法执行时有两种退出情况
+    - 正常退出
+正常执行到任何方法的返回字节码指令，如RETURN、IRETURN、ARETURN等
+    - 异常退出
+
+无论何种退出情况，都将返回至方法当前被调用的位置。方法退出的过程相当于弹出当前栈帧
+
+
+退出可能有三种方式:
+- 返回值压入，上层调用栈帧
+- 异常信息抛给能够处理的栈帧
+- PC计数器指向方法调用后的下一条指令
+
+Java虚拟机栈是描述Java方法运行过程的内存模型
+
+Java虚拟机栈会为每一个即将运行的Java方法创建“栈帧”
+用于存储该方法在运行过程中所需要的一些信息
+- 局部变量表 
+存放基本数据类型变量、引用类型的变量、returnAddress类型的变量
+- 操作数栈
+- 动态链接
+- 当前方法的常量池指针
+- 当前方法的返回地址
+- 方法出口等信息
+
+每一个方法从被调用到执行完成的过程,都对应着一个个栈帧在JVM栈中的入栈和出栈过程
+
+> 注意：人们常说，Java的内存空间分为“栈”和“堆”，栈中存放局部变量，堆中存放对象。 
+> 这句话不完全正确！这里的“堆”可以这么理解，但这里的“栈”就是现在讲的虚拟机栈,或者说Java虚拟机栈中的局部变量表部分.
+> 真正的Java虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息.
+## 2.2. 特点
+局部变量表的创建是在方法被执行的时候,随着栈帧的创建而创建.
+而且表的大小在编译期就确定,在创建的时候只需分配事先规定好的大小即可.
+在方法运行过程中,表的大小不会改变
+
+Java虚拟机栈会出现两种异常
+
+- **StackOverFlowError**
+若Java虚拟机栈的内存大小不允许动态扩展,那么当线程请求的栈深度大于虚拟机允许的最大深度时(但内存空间可能还有很多),就抛出此异常 
+- **OutOfMemoryError**
+若Java虚拟机栈的内存大小允许动态扩展,且当线程请求栈时内存用完了,无法再动态扩展了,此时抛出OutOfMemoryError异常
+
+Java虚拟机栈也是线程私有的,每个线程都有各自的Java虚拟机栈,而且随着线程的创建而创建,随着线程的死亡而死亡.
+
+
+
+# 3. 本地方法栈(Native Method Stack)
+本地方法栈和Java虚拟机栈实现的功能与抛出异常几乎相同
+只不过虚拟机栈是为虚拟机执行Java方法(也就是字节码)服务,本地方法区则为虚拟机使用到的Native方法服务.
+
+在JVM内存布局中，也是线程对象私有的,但是虚拟机栈“主内”，而本地方法栈“主外”
+这个“内外”是针对JVM来说的，本地方法栈为Native方法服务
+线程开始调用本地方法时，会进入一个不再受JVM约束的世界
+本地方法可以通过JNI(Java Native Interface)来访问虚拟机运行时的数据区，甚至可以调用寄存器,具有和JVM相同的能力和权限
+当大量本地方法出现时,势必会削弱JVM对系统的控制力,因为它的出错信息都比较黑盒.
+对于内存不足的情况，本地方法栈还是会拋出native heap OutOfMemory
+
+最著名的本地方法应该是`System.currentTimeMillis()`，JNI 使Java深度使用OS的特性功能，复用非Java代码
+但是在项目过程中，如果大量使用其他语言来实现JNI,就会丧失跨平台特性，威胁到程序运行的稳定性
+假如需要与本地代码交互，就可以用中间标准框架进行解耦，这样即使本地方法崩溃也不至于影响到JVM的稳定
+当然，如果要求极高的执行效率、偏底层的跨进程操作等，可以考虑设计为JNI调用方式
+
+
+# 4 Java堆(Java Heap)
+Heap是OOM故障最主要的发源地，它存储着几乎所有的实例对象，堆由垃圾收集器自动回收，堆区由各子线程共享使用
+通常情况下，它占用的空间是所有内存区域中最大的，但如果无节制地创建大量对象，也容易消耗完所有的空间
+堆的内存空间既可以固定大小，也可运行时动态地调整，通过如下参数设定初始值和最大值，比如
+```
+-Xms256M. -Xmx1024M
+```
+其中-X表示它是JVM运行参数
+- ms是memorystart的简称 最小堆容量
+- mx是memory max的简称 最大堆容量
+
+但是在通常情况下，服务器在运行过程中，堆空间不断地扩容与回缩，势必形成不必要的系统压力，所以在线上生产环境中，JVM的Xms和Xmx设置成一样大小，避免在GC后调整堆大小时带来的额外压力
+
+堆分成两大块:新生代和老年代
+对象产生之初在新生代，步入暮年时进入老年代，但是老年代也接纳在新生代无法容纳的超大对象
+
+新生代= 1个Eden区+ 2个Survivor区
+绝大部分对象在Eden区生成，当Eden区装填满的时候，会触发Young GC。垃圾回收的时候，在Eden区实现清除策略，没有被引用的对象则直接回收。依然存活的对象会被移送到Survivor区，这个区真是名副其实的存在
+Survivor 区分为S0和S1两块内存空间，送到哪块空间呢?每次Young GC的时候，将存活的对象复制到未使用的那块空间，然后将当前正在使用的空间完全清除，交换两块空间的使用状态
+如果YGC要移送的对象大于Survivor区容量上限，则直接移交给老年代
+假如一些没有进取心的对象以为可以一直在新生代的Survivor区交换来交换去，那就错了。每个对象都有一个计数器，每次YGC都会加1。
+```
+-XX:MaxTenuringThreshold 
+```
+参数能配置计数器的值到达某个阈值的时候，对象从新生代晋升至老年代。如果该参数配置为1,那么从新生代的Eden区直接移至老年代。默认值是15，可以在Survivor 区交换14次之后，晋升至老年代
+![对象分配与简要GC流程图](https://upload-images.jianshu.io/upload_images/4685968-57ed647f10498521.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+若`Survivor`区无法放下，或者超大对象的阈值超过上限，则尝试在老年代中进行分配;
+如果老年代也无法放下，则会触发Full Garbage Collection(Full GC);
+如果依然无法放下，则抛OOM.
+
+堆出现OOM的概率是所有内存耗尽异常中最高的
+出错时的堆内信息对解决问题非常有帮助，所以给JVM设置运行参数-
+```
+XX:+HeapDumpOnOutOfMemoryError
+```
+让JVM遇到OOM异常时能输出堆内信息
+
+>在不同的JVM实现及不同的回收机制中，堆内存的划分方式是不一样的
+
+
+
+
+
+存放所有的类实例及数组对象
+除了实例数据，还保存了对象的其他信息，如Mark Word（存储对象哈希码，GC标志，GC年龄，同步锁等信息），Klass Pointy(指向存储类型元数据的指针）及一些字节对齐补白的填充数据（若实例数据刚好满足8字节对齐，则可不存在补白）
+## 特点
+Java虚拟机所需要管理的内存中最大的一块. 
+
+堆内存物理上不一定要连续,只需要逻辑上连续即可,就像磁盘空间一样.
+堆是垃圾回收的主要区域,所以也被称为GC堆.
+
+堆的大小既可以固定也可以扩展,但主流的虚拟机堆的大小是可扩展的(通过-Xmx和-Xms控制),因此当线程请求分配内存,但堆已满,且内存已满无法再扩展时,就抛出OutOfMemoryError.
+
+线程共享 
+整个Java虚拟机只有一个堆,所有的线程都访问同一个堆.
+它是被所有线程共享的一块内存区域,在虚拟机启动时创建.
+而程序计数器、Java虚拟机栈、本地方法栈都是一个线程对应一个
+
+# 5 方法区
+## 5.1 定义
+Java虚拟机规范中定义方法区是堆的一个逻辑部分,但是别名Non-Heap(非堆),以与Java堆区分.
+方法区中存放已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据.
+
+
+## 5.2 特点
+- 线程共享 
+方法区是堆的一个逻辑部分,因此和堆一样,都是线程共享的.整个虚拟机中只有一个方法区.
+- 永久代 
+方法区中的信息一般需要长期存在，而且它又是堆的逻辑分区，因此用堆的划分方法，我们把方法区称为永久代.
+- 内存回收效率低 
+Java虚拟机规范对方法区的要求比较宽松,可以不实现垃圾收集.
+方法区中的信息一般需要长期存在,回收一遍内存之后可能只有少量信息无效.
+对方法区的内存回收的主要目标是:**对常量池的回收和对类型的卸载**
+
+和堆一样，允许固定大小，也允许可扩展的大小，还允许不实现垃圾回收。 
+
+当方法区内存空间无法满足内存分配需求时,将抛出OutOfMemoryError异常.
+
+## 5.3  运行时常量池(Runtime Constant Pool)
+### 5.3.1 定义 
+运行时常量池是方法区的一部分.
+方法区中存放三种数据：类信息、常量、静态变量、即时编译器编译后的代码.其中常量存储在运行时常量池中.
+
+我们知道，.java文件被编译之后生成的.class文件中除了包含：类的版本、字段、方法、接口等信息外，还有一项就是常量池
+常量池中存放编译时期产生的各种字面量和符号引用，.class文件中的常量池中的所有的内容在类被加载后存放到方法区的运行时常量池中。 
+PS：int age = 21;//age是一个变量，可以被赋值；21就是一个字面值常量，不能被赋值； 
+int final pai = 3.14;//pai就是一个符号常量，一旦被赋值之后就不能被修改。
+
+Class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池( Constant pool table)，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入运行时常量池中存放。运行时常量池相对于class文件常量池的另外一个特性是具备动态性，java语言并不要求常量一定只有编译器才产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。
+
+在近三个JDK版本（6、7、8）中， 运行时常量池的所处区域一直在不断的变化，
+在JDK6时它是方法区的一部分
+7又把他放到了堆内存中
+8之后出现了元空间，它又回到了方法区。
+其实，这也说明了官方对“永久代”的优化从7就已经开始了
+### 5.3.2 特性 
+class文件中的常量池具有动态性.
+Java并不要求常量只能在编译时候产生,Java允许在运行期间将新的常量放入方法区的运行时常量池中. 
+String类中的intern()方法就是采用了运行时常量池的动态性.当调用 intern 方法时,如果池已经包含一个等于此 String 对象的字符串,则返回池中的字符串.否则,将此 String 对象添加到池中,并返回此 String 对象的引用.
+### 5.3.3 可能抛出的异常 
+运行时常量池是方法区的一部分,所以会受到方法区内存的限制,因此当常量池无法再申请到内存时就会抛出OutOfMemoryError异常.
+
+
+
+我们一般在一个类中通过public static final来声明一个常量。这个类被编译后便生成Class文件，这个类的所有信息都存储在这个class文件中。
+
+当这个类被Java虚拟机加载后，class文件中的常量就存放在方法区的运行时常量池中。而且在运行期间，可以向常量池中添加新的常量。如：String类的intern()方法就能在运行期间向常量池中添加字符串常量。
+
+当运行时常量池中的某些常量没有被对象引用，同时也没有被变量引用，那么就需要垃圾收集器回收。 
+
+# 6 直接内存(Direct Memory)
+直接内存不是虚拟机运行时数据区的一部分,也不是JVM规范中定义的内存区域,但在JVM的实际运行过程中会频繁地使用这块区域.而且也会抛OOM 
+
+在JDK 1.4中加入了NIO(New Input／Output)类,引入了一种基于管道和缓冲区的IO方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在堆里的`DirectByteBuffer`对象作为这块内存的引用来操作堆外内存中的数据.
+这样能在一些场景中显著提升性能,因为避免了在Java堆和Native堆中来回复制数据. 
+
+> 综上看来
+程序计数器、Java虚拟机栈、本地方法栈是线程私有的，即每个线程都拥有各自的程序计数器、Java虚拟机栈、本地方法区。并且他们的生命周期和所属的线程一样。 
+而堆、方法区是线程共享的，在Java虚拟机中只有一个堆、一个方法栈。并在JVM启动的时候就创建，JVM停止才销毁。
+
+# 7 Metaspace (元空间)
+在JDK8，元空间的前身Perm区已经被淘汰,在JDK7及之前的版本中，只有Hotspot才有Perm区(永久代),它在启动时固定大小,很难进行调优,并且Full GC时会移动类元信息
+
+在某些场景下,如果动态加载类过多,容易产生Perm区的OOM.
+比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多的类，经常出现致命错误:
+```
+Exception in thread ‘dubbo client x.x connector' java.lang.OutOfMemoryError: PermGenspac
+```
+为解决该问题，需要设定运行参数
+```
+-XX:MaxPermSize= l280m
+```
+如果部署到新机器上，往往会因为JVM参数没有修改导致故障再现。不熟悉此应用的人排查问题时往往苦不堪言，除此之外，永久代在GC过程中还存在诸多问题
+
+所以，JDK8使用元空间替换永久代.区别于永久代，元空间在本地内存中分配.
+也就是说，只要本地内存足够，它不会出现像永久代中`java.lang.OutOfMemoryError: PermGen space`
+
+同样的，对永久代的设置参数 `PermSize` 和` MaxPermSize `也会失效
+在JDK8及以上版本中，设定`MaxPermSize`参数，JVM在启动时并不会报错，但是会提示:
+```
+ Java HotSpot 64Bit Server VM warning:ignoring option MaxPermSize=2560m; support was removed in 8.0
+```
+
+默认情况下，“元空间”的大小可以动态调整，或者使用新参数`MaxMetaspaceSize `来限制本地内存分配给类元数据的大小.
+
+在JDK8里，Perm 区所有内容中
+- 字符串常量移至堆内存
+- 其他内容包括类元信息、字段、静态属性、方法、常量等都移动至元空间
+![](https://upload-images.jianshu.io/upload_images/4685968-60f401503b9a75e0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+比如上图中的Object类元信息、静态属性System.out、整型常量000000等
+图中显示在常量池中的String，其实际对象是被保存在堆内存中的。
+
+## **元空间特色**
+*   充分利用了Java语言规范：类及相关的元数据的生命周期与类加载器的一致
+*   每个类加载器都有它的内存区域-元空间
+*   只进行线性分配
+*   不会单独回收某个类（除了重定义类 RedefineClasses 或类加载失败）
+*   没有GC扫描或压缩
+*   元空间里的对象不会被转移
+*   如果GC发现某个类加载器不再存活，会对整个元空间进行集体回收
+
+## **GC**
+*   Full GC时，指向元数据指针都不用再扫描，减少了Full GC的时间
+*   很多复杂的元数据扫描的代码（尤其是CMS里面的那些）都删除了
+*   元空间只有少量的指针指向Java堆
+这包括：类的元数据中指向java.lang.Class实例的指针;数组类的元数据中，指向java.lang.Class集合的指针。
+*   没有元数据压缩的开销
+*   减少了GC Root的扫描（不再扫描虚拟机里面的已加载类的目录和其它的内部哈希表）
+*   G1回收器中，并发标记阶段完成后就可以进行类的卸载
+
+## **元空间内存分配模型**
+*   绝大多数的类元数据的空间都在本地内存中分配
+*   用来描述类元数据的对象也被移除
+*   为元数据分配了多个映射的虚拟内存空间
+*   为每个类加载器分配一个内存块列表
+    *   块的大小取决于类加载器的类型
+    *   Java反射的字节码存取器（sun.reflect.DelegatingClassLoader ）占用内存更小
+*   空闲块内存返还给块内存列表
+*   当元空间为空，虚拟内存空间会被回收
+*   减少了内存碎片
+
+
+最后,从线程共享的角度来看
+- 堆和元空间是所有线程共享的
+- 虚拟机栈、本地方法栈、程序计数器是线程内部私有的
+
+从这个角度看一下Java内存结构
+![Java 的线程与内存](https://upload-images.jianshu.io/upload_images/4685968-aa2e002ac2fec675.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 8 从GC角度看Java堆
+
+> 堆和方法区都是线程共享的区域，主要用来存放对象的相关信息。我们知道，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序运行期间才能知道会创建哪些对象，因此， 这部分的内存和回收都是动态的，垃圾收集器所关注的就是这部分内存（本节后续所说的“内存”分配与回收也仅指这部分内存）。而在JDK1.7和1.8对这部分内存的分配也有所不同，下面我们来详细看一下
+
+Java8中堆内存分配如下图：
+![](http://upload-images.jianshu.io/upload_images/4685968-3d30d129baba9f06.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+# 9 JVM关闭
+- 正常关闭：当最后一个非守护线程结束或调用了System.exit或通过其他特定于平台的方式,比如ctrl+c。
+- 强制关闭：调用Runtime.halt方法，或在操作系统中直接kill（发送single信号）掉JVM进程。
+- 异常关闭：运行中遇到RuntimeException 异常等
+ 
+在某些情况下，我们需要在JVM关闭时做一些扫尾的工作，比如删除临时文件、停止日志服务。为此JVM提供了关闭钩子（shutdown hocks）来做这些事件。 
+
+Runtime类封装java应用运行时的环境，每个java应用程序都有一个Runtime类实例，使用程序能与其运行环境相连。
+ 
+关闭钩子本质上是一个线程（也称为hock线程），可以通过Runtime的addshutdownhock （Thread hock）向主jvm注册一个关闭钩子。hock线程在jvm正常关闭时执行，强制关闭不执行。 
+
+对于在jvm中注册的多个关闭钩子，他们会并发执行，jvm并不能保证他们的执行顺序。 
+
+# 参考
+《码出高效》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\345\231\250.md" "b/Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\345\231\250.md"
new file mode 100644
index 0000000000..4a0b13682f
--- /dev/null
+++ "b/Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\345\231\250.md"
@@ -0,0 +1,221 @@
+使用分代垃圾收集器,基于以下观察事实(弱分代假设)
+- 大多数分配对象的存活时间短
+- 存活时间久的对象很少引用存活时间短的对象
+
+由此, HotSpot VM 将堆分为两个物理区空间,这就是分代(永久代只存储元数据, eg. 类的数据结构,保留字符串( Interned String))
+
+
+根据新生代和老年代各自的特点,我们应该分别为它们选择不同的收集器,以提升垃圾回收效率.
+![](http://upload-images.jianshu.io/upload_images/4685968-3a367913acebef67.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 1 新生代垃圾收集器
+
+##  1.1  Serial垃圾收集器
+一个主要应用于Y-GC的垃圾回收器，采用串行单线程的方式完成GC任务，其中“Stop The World"简称STW,即垃圾回收的某个阶段会暂停整个应用程序的执行
+F-GC的时间相对较长，频繁FGC会严重影响应用程序的性能
+![Serial 回收流程](https://upload-images.jianshu.io/upload_images/4685968-407a95f442c62819.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`单线程 Stop-The-World 式`
+![](http://upload-images.jianshu.io/upload_images/4685968-ebdf41221960630c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 单线程 
+只会使用一个CPU或一条GC线程进行GC,并且在GC过程中暂停其他所有的工作线程,因此用户的请求或图形化界面会出现卡顿
+- 适合Client模式
+一般客户端应用所需内存较小,不会创建太多的对象,而且堆内存不大,因此GC时间比较短,即使在这段时间停止一切用户线程,也不会感到明显停顿
+- 简单高效 
+由于Serial收集器只有一条GC线程,避免了线程切换的开销
+- 采用"复制"算法 
+## 1.2 ParNew垃圾收集器
+ParNew是Serial的多线程版本.
+![](http://upload-images.jianshu.io/upload_images/4685968-e4947c56e4c734f2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 2.1 多线程并行执行 
+ParNew由多条GC线程并行地进行垃圾清理.
+但清理过程仍然需要暂停一切其他用户线程.
+但由于有多条GC线程同时清理,清理速度比Serial有一定的提升
+## 2.2 适合多CPU的服务器环境 
+由于使用多线程,是许多运行在 server 模式下的虚拟机首选的新生代收集器
+- 与Serial性能对比 
+ParNew和Serial唯一区别就是使用了多线程垃圾回收,在多CPU的环境下性能比Serial会有一定程度的提升
+但线程切换需要额外的开销,因此在单CPU环境中表现不如Serial,双CPU环境也不一定就比Serial高效
+默认开启的收集线程数与CPU数量相同
+## 2.3 采用"复制"算法
+## 2.4 追求"降低停顿时间" 
+和Serial相比,ParNew使用多线程的目的就是缩短GC时间,从而减少用户线程被停顿的时间
+# 3 Parallel : 吞吐量为先!
+## 3.1 Scavenge垃圾收集器
+Parallel Scavenge和ParNew一样都是并行的多线程、新生代收集器,都使用"复制"算法(`Stop-The-World`)进行垃圾回收
+
+但它们有个巨大不同点:
+- ParNew收集器追求降低GC时用户线程的停顿时间,适合交互式应用,良好的反应速度提升用户体验.
+- Parallel Scavenge追求可控的CPU吞吐量,能够在较短的时间内完成指定任务,适合不需太多交互的后台运算
+
+>吞吐量是指用户线程运行时间占CPU总时间的比例.
+>CPU总时间包括 : 用户线程运行时间 和 GC线程运行的时间. 
+> 因此,吞吐量越高表示用户线程运行时间越长,从而用户线程能够被快速处理完.
+
+- 降低停顿时间的两种方式 
+1.在多CPU环境中使用多条GC线程,从而垃圾回收的时间减少,从而用户线程停顿的时间也减少;
+2.实现GC线程与用户线程并发执行。所谓并发，就是用户线程与GC线程交替执行，从而每次停顿的时间会减少，用户感受到的停顿感降低，但线程之间不断切换意味着需要额外的开销，从而垃圾回收和用户线程的总时间将会延长。
+
+- Parallel Scavenge提供的参数
+ - -XX:GCTimeRadio
+直接设置吞吐量大小,GC时间占总时间比率.相当于是吞吐量的倒数.
+
+ - -XX:MaxGCPauseMillis
+设置最大GC停顿时间
+Parallel Scavenge会根据这个值的大小确定新生代的大小.
+这个值越小,新生代就越小,从而收集器就能以较短时间进行一次GC
+但新生代变小后,回收的频率就会提高,吞吐量也降下来了,因此要合理控制这个值
+ - -XX:+UseAdaptiveSizePolicy
+开启GC **自适应的调节策略(区别于ParNew)**.
+我们只要设置最大堆(-Xmx)和MaxGCPauseMillis或GCTimeRadio,收集器会自动调整新生代的大小、Eden和Survior的比例、对象进入老年代的年龄,以最大程度上接近我们设置的MaxGCPauseMillis或GCTimeRadio
+## 3.2 Old垃圾收集器
+Parallel Scavenge的老年代版本,一般它们搭配使用,追求CPU吞吐量
+
+它们在垃圾收集时都是由多条GC线程并行执行,并暂停一切用户线程,使用"标记-整理"算法.因此,由于在GC过程中没有使垃圾收集和用户线程并行执行,因此它们是追求吞吐量的垃圾收集器. 
+![](http://upload-images.jianshu.io/upload_images/4685968-7dfdda76a61a31cf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# **老年代垃圾收集器**
+# 1 Serial Old垃圾收集器
+Serial的老年代版本,都是单线程收集器,GC时只启动一条GC线程,因此都适合客户端应用.
+
+
+它们唯一的区别就是
+- Serial Old工作在老年代,使用"标记-整理"算法
+- Serial工作在新生代,使用"复制"算法. 
+![](http://upload-images.jianshu.io/upload_images/4685968-b150a60a1bae36a8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 4  CMS垃圾收集器(Concurrent Mark Sweep Collector) : 低延迟为先!
+回收停顿时间比较短、目前比较常用的垃圾回收器。它通过初始标记(InitialMark)、并发标记(Concurrent   Mark)、重新标记( Remark)、并发清除( Concurrent Sweep )四个步骤完成垃圾回收工作
+由于CMS采用的是“标记-清除算法"，因此戸生大量的空间碎片。为了解决这个问题，CMS可以通过配置
+```
+-XX:+UseCMSCompactAtFullCollection
+```
+参数，强制JVM在FGC完成后対老年代迸行圧縮，执行一次空间碎片整理，但是空间碎片整理阶段也会引发STW。为了减少STW次数，CMS还可以通过配置
+```
+-XX:+CMSFullGCsBeforeCompaction=n
+```
+参数，在执行了n次FGC后, JVM再在老年代执行空间碎片整理
+
+对许多应用来说,快速响应比端到端的吞吐量更为重要
+
+管理新生代的方法与 parallel 和 serial 相同
+在老年代则尽可能并发执行,每个 GC 周期只有2次短的停顿
+
+一种追求最短停顿时间的收集器
+在GC时使得用户线程和GC线程并发执行,因此在GC过程中用户也不会感受到明显卡顿
+但用户线程和GC线程之间不停地切换会有额外的开销,因此垃圾回收总时间就会被延长
+**垃圾回收过程**
+前两步需要"Stop The World"
+- 初始标记 (Initial Mark)
+停止一切用户线程,仅使用一条初始标记线程对所有与GC Roots直接相关联的 老年代对象进行标记,速度很快
+- 并发标记 (Concurrent Marking Phase)
+使用多条并发标记线程并行执行,并与用户线程并发执行.此过程进行可达性分析,标记所有这些对象可达的存货对象,速度很慢
+- 重新标记 ( Remark)
+因为并发标记时有用户线程在执行，标记结果可能有变化
+停止一切用户线程,并使用多条重新标记线程并行执行,重新遍历所有在并发标记期间有变化的对象进行最后的标记.这个过程的运行时间介于初始标记和并发标记之间
+- 并发清除 (Concurrent Sweeping)
+只使用一条并发清除线程,和用户线程们并发执行,清除刚才标记的对象
+这个过程非常耗时
+![](http://upload-images.jianshu.io/upload_images/4685968-fb1723e25639cf21.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 4.1 **CMS的缺点**
+- 吞吐量低 
+由于CMS在GC过程用户线程和GC线程并行,从而有线程切换的额外开销
+因此CPU吞吐量就不如在GC过程中停止一切用户线程的方式来的高
+- 无法处理浮动垃圾,导致频繁Full GC 
+由于垃圾清除过程中,用户线程和GC线程并发执行,也就是用户线程仍在执行,那么在执行过程中会产生垃圾,这些垃圾称为"浮动垃圾"
+如果CMS在GC过程中,用户线程需要在老年代中分配内存时发现空间不足,就需再次发起Full GC,而此时CMS正在进行清除工作,因此此时只能由Serial Old临时对老年代进行一次Full GC
+- 使用"标记-清除"算法产生碎片空间 
+由于CMS使用了"标记-清除"算法, 因此清除之后会产生大量的碎片空间,不利于空间利用率.不过CMS提供了应对策略:
+   - 开启-XX:+UseCMSCompactAtFullCollection 
+开启该参数后,每次FullGC完成后都会进行一次内存压缩整理,将零散在各处的对象整理到一块儿.但每次都整理效率不高,因此提供了以下参数.
+   - 设置参数-XX:CMSFullGCsBeforeCompaction 
+本参数告诉CMS,经过了N次Full GC过后再进行一次内存整理.
+
+# 5 G1收集器(Garbage-First)
+Hotspot 在JDK7中推出了新一代 G1 ( Garbage-First Garbage Collector )垃圾回收，通过
+```
+-XX:+UseG1GC
+```
+参数启用
+和CMS相比，Gl具备压缩功能，能避免碎片向題，G1的暂停时间更加可控。性能总体还是非常不错的,G1是当今最前沿的垃圾收集器成果之一.
+
+## 5.1 G1的特点
+- 追求停顿时间
+- 多线程GC
+- 面向服务端应用
+- 整体来看基于标记-整理和局部来看基于复制算法合并 
+不会产生内存空间碎片
+- 可对整个堆进行垃圾回收
+- 可预测的停顿时间
+## 5.2 G1的内存模型
+没有新生代和老年代的概念,而是将Java堆划分为一块块独立的大小相等的Region.
+当要进行垃圾收集时,首先估计每个Region中的垃圾数量,每次都从垃圾回收价值最大的Region开始回收,因此可以获得最大的回收效率
+![](https://upload-images.jianshu.io/upload_images/4685968-db8d827f816cca34.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ G1将Java堆空间分割成了若干相同大小的区域，即region
+包括
+- Eden
+- Survivor
+- Old
+- Humongous 
+
+其中，`Humongous `是特殊的Old类型,专门放置大型对象.
+这样的划分方式意味着不需要一个连续的内存空间管理对象.G1将空间分为多个区域,**优先回收垃圾最多**的区域.
+G1采用的是**Mark-Copy** ，有非常好的空间整合能力,不会产生大量的空间碎片
+G1的一大优势在于可预测的停顿时间,能够尽可能快地在指定时间内完成垃圾回收任务
+在JDK11中，已经将G1设为默认垃圾回收器，通过jstat命令可以查看垃圾回收情况,在YGC时S0/S1并不会交换.
+
+## 5.3 Remembered Set
+一个对象和它内部所引用的对象可能不在同一个Region中,那么当垃圾回收时,是否需要扫描整个堆内存才能完整地进行一次可达性分析?
+当然不是,每个Region都有一个Remembered Set,用于记录本区域中所有对象引用的对象所在的区域,从而在进行可达性分析时,只要在GC Roots中再加上Remembered Set即可防止对所有堆内存的遍历.
+## 5.4 G1垃圾收集过程
+
+- 初始标记 
+标记与GC Roots直接关联的对象,停止所有用户线程,只启动一条初始标记线程,这个过程很快.
+- 并发标记 
+进行全面的可达性分析,开启一条并发标记线程与用户线程并行执行.这个过程比较长.
+- 最终标记 
+标记出并发标记过程中用户线程新产生的垃圾.停止所有用户线程,并使用多条最终标记线程并行执行.
+- 筛选回收 
+回收废弃的对象.此时也需要停止一切用户线程,并使用多条筛选回收线程并行执行.
+![这里写图片描述](http://upload-images.jianshu.io/upload_images/4685968-0ea2b3a18ecc561a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+S0/S1的功能由G1中的Survivor region来承载,通过GC日志可以观察到完整的垃圾回收过程如下，其中就有Survivor regions的区域从0个到1个
+![](https://upload-images.jianshu.io/upload_images/4685968-ad5f6b99b3de502e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ 红色标识的为G1中的四种region,都处于Heap中.
+G1执行时使用4个worker并发执行，在初始标记时，还是会触发STW,如第一步所示的Pause
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\347\256\227\346\263\225.md" "b/Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\347\256\227\346\263\225.md"
new file mode 100644
index 0000000000..80f2fc0a09
--- /dev/null
+++ "b/Java/JVM/JVM\345\256\236\346\210\230---\345\236\203\345\234\276\346\224\266\351\233\206\347\256\227\346\263\225.md"
@@ -0,0 +1,249 @@
+Java会对内存进行自动分配与回收管理，使上层业务更加安全，方便地使用内存实现程序逻辑
+在不同的JVM实现及不同的回收机制中，堆内存的划分方式是不一样的
+这里简要介绍垃圾回收( Garbage Collection, GC)。垃圾回收的主要目的是清除不再使用的对象，自动释放内存.
+
+# 静态内存分配和回收
+在程序开始运行时由编译器分配的内存
+在被编译时就已经能够确定需要的空间,当程序被加载时系统把内存一次性分配给它,这些内存不会在程序执行时发生变化,直到程序执行结束时才回收内存.
+
+- 包括原生数据类型及对象的引用
+
+- 这些静态内存空间在栈上分配,方法运行结束,对应的栈帧撤销,内存空间被回收.
+
+- 每个栈帧中的本地变量表都是在类被加载的时候就确定的,每一个栈帧中分配多少内存基本上是在类结构确定时就已知了,因此这几块区域内存分配和回收都具备确定性,就不需要过多考虑回收问题了
+
+# 动态内存分配和回收
+- 在程序执行时才知道要分配的存储空间大小,对象何时被回收也是不确定的,只有等到该对象不再使用才会被回收.
+
+堆和方法区的内存回收具有不确定性,因此垃圾收集器在回收堆和方法区内存的时候花了一点心思.
+
+# 1 Java堆内存的回收
+## 1.1 判定回收的对象
+GC是如何判断对象是否可以被回收的呢?为了判断对象是否存活，JVM引入了GC Roots
+如果一个对象与GC Roots之间没有直接或间接的引用关系，比如某个失去任何引用的对象，或者两个互相环岛状循环引用的对象等，判决这些对象“死缓”，是可以被回收的
+
+在对堆进行对象回收之前,首先要判断哪些是无效对象(一个对象不被任何对象或变量引用)需要被回收
+
+一般有两种判别方式:
+- 引用计数法 (Reference Counting)
+每个对象都有一个整型的计数器,当这个对象被一个变量或对象引用时，该计数器加一;当该引用失效时,计数器值减一.当计数器为0时,就认为该对象是无效对象.
+- 可达性分析法 (Reachability Analysis)
+所有和GC Roots直接或间接关联的对象都是有效对象,和GC Roots没有关联的对象就是无效对象.
+![](http://upload-images.jianshu.io/upload_images/1801191-72215219d013bf70.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`GC Roots对象`
+ - 虚拟机栈(栈帧中的本地变量表)中引用的对象
+ - 方法区中静态属性引用的对象
+ - 方法区中常量引用的对象
+ - 本地方法栈JNI(native方法)引用的对象
+
+> **GC Roots并不包括堆中对象所引用的对象！这样就不会出现循环引用.**
+
+- 两者对比
+引用计数法虽然简单,但存在无法解决对象之间相互循环引用的严重问题,且伴随加减法操作的性能影响. 
+
+因此,目前主流语言均使用可达性分析方法来判断对象是否有效.
+
+# 2 回收无效对象的过程
+当经可达性算法筛选出失效的对象之后,并不是立即清除,而是再给对象一次重生的机会
+- 判断是否覆盖finalize()
+   - 未覆盖该或已调用过该方法,直接释放对象内存
+  -  已覆盖该方法且还未被执行,则将finalize()扔到F-Queue队列中
+- 执行F-Queue中的finalize() 
+ 虚拟机会以较低的优先级执行这些finalize(),不会确保所有的finalize()都会执行结束
+如果finalize()中出现耗时操作,虚拟机就直接停止执行,将该对象清除
+- 对象重生或死亡 
+  - 如果在执行finalize()方法时,将this赋给了某一个引用,则该对象重生
+  - 如果没有,那么就会被垃圾收集器清除
+> 注意:强烈不建议使用finalize()进行任何操作!
+如果需要释放资源,请用try-finally或者其他方式都能做得更好. 
+> 因为finalize()不确定性大,开销大,无法保证各个对象的调用顺序.
+
+以下代码示例看到:一个对象的finalize被执行,但依然可以存活
+```
+/**
+ * 演示两点:
+ * 1.对象可以在被GC时自救
+ * 2.这种自救机会只有一次,因为一个对象的finalize()最多只能被系统自动调用一次,因此第二次自救失败
+ * @author sss
+ * @since 17-9-17 下午12:02
+ *
+ */
+public class FinalizeEscapeGC {
+
+    private static FinalizeEscapeGC SAVE_HOOK = null;
+
+    private void isAlive() {
+        System.out.println("yes,I am still alive :)");
+    }
+
+    @Override
+    protected void finalize() throws Throwable {
+        super.finalize();
+        System.out.println("finalize methodd executed!");
+        FinalizeEscapeGC.SAVE_HOOK = this;
+    }
+
+
+    public static void main(String[] args) throws InterruptedException {
+        SAVE_HOOK = new FinalizeEscapeGC();
+
+        // 对象第一次成功自救
+        SAVE_HOOK = null;
+        System.gc();
+        // 因为finalize方法优先级很低,所以暂停0.5s以等待它
+        Thread.sleep(500);
+        if (SAVE_HOOK != null) {
+            SAVE_HOOK.isAlive();
+        } else {
+            System.out.println("no,I am dead :(");
+        }
+
+        // 自救失败
+        SAVE_HOOK = null;
+        System.gc();
+        Thread.sleep(500);
+        if (SAVE_HOOK != null) {
+            SAVE_HOOK.isAlive();
+        } else {
+            System.out.println("no,I am dead :(");
+        }
+    }
+}
+```
+运行结果
+
+```
+finalize methodd executed!
+yes,I am still alive :)
+no,I am dead :(
+```
+
+# 3 方法区的内存回收
+使用`复制算法`实现堆的内存回收,堆被分为`新生代`和`老年代`
+- 新生代中的对象"朝生夕死",每次垃圾回收都会清除掉大量对象
+- 老年代中的对象生命较长,每次垃圾回收只有少量的对象被清除
+
+由于方法区中存放生命周期较长的类信息、常量、静态变量.
+因此方法区就像堆的老年代,每次GC只有少量垃圾被清除.
+
+方法区中主要清除两种垃圾 
+- 废弃常量 
+- 无用类
+
+## 3.1 回收废弃常量
+回收废弃常量和回收对象类似,只要常量池中的常量不被任何变量或对象引用,那么这些常量就会被清除.
+
+## 3.2 回收无用类
+判定无用类的条件则较为苛刻 
+- 该类所有实例都已被回收
+即Java堆不存在该类的任何实例 
+- 加载该类的ClassLoader已被回收
+- 该类的java.lang.Class对象没有被任何对象或变量引用,无法通过反射访问该类的方法
+只要一个类被虚拟机加载进方法区,那么在堆中就会有一个代表该类的对象:java.lang.Class.这个对象在类被加载进方法区的时候创建,在方法区中该类被删除时清除. 
+
+
+# 4 垃圾收集算法
+
+## 4.1 标记-清除(Mark-Sweep)
+`最基础`的收集算法,后续算法也都是基于此并改进其不足而得.
+
+该算法会从每个GC Roots出发，依次标记有引用关系的对象，最后将没有被标记的对象清除
+
+### 不足
+这种算法会带来大量的空间碎片，导致需要分配一个较大连续空间时容易触发FullGC,降低了空间利用率.
+![标记-清除算法](http://upload-images.jianshu.io/upload_images/4685968-2f4485f2b21d0496?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+为了解决这个问题，又提出了“标记-整理算法”，该算法类似计算机的磁盘整理，首先会从GC Roots出发标记存活的对象，然后将存活对象整理到内存空间的一端，形成连续的已使用空间，最后把已使用空间之外的部分全部清理掉，这样就不会产生空间碎片的问题
+
+## 4.2 复制算法(Mark-Copy)
+为了能够并行地标记和整理将空间分为两块,每次只激活其中一块,垃圾回收时只需把存活的对象复制到另一块未激活空间上,将未激活空间标记为已激活,将已激活空间标记为未激活,然后清除原空间中的原对象
+
+将内存分成大小相等两份,只将数据存储在其中一块上
+- 当需要回收时,首先标记废弃数据
+- 然后将有用数据复制到另一块内存
+- 最后将第一块内存空间全部清除
+![复制算法](http://upload-images.jianshu.io/upload_images/4685968-df08eebdab044bef.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 4.2.1 分析
+  - 这种算法避免了空间碎片,但内存缩小了一半.
+  - 每次都需将有用数据全部复制到另一片内存,效率不高
+
+### 4.2.2 解决空间利用率问题
+堆内存空间分为较大的Eden和两块较小的Survivor,每次只使用Eden和Survivor区的一块。这种情形下的“ Mark-Copy"减少了内存空间的浪费。“Mark-Copy”现作为主流的YGC算法进行新生代的垃圾回收。
+在新生代中,由于大量对象都是"朝生夕死",也就是一次垃圾收集后只有少量对象存活
+因此我们可以将内存划分成三块
+ - `Eden、Survior1、Survior2`
+- 内存大小分别是8:1:1
+
+分配内存时,只使用Eden和一块Survior1.
+- 当发现Eden+Survior1的内存即将满时,JVM会发起一次`Minor GC`,清除掉废弃的对象,
+- 并将所有存活下来的对象复制到另一块Survior2中.
+- 接下来就使用Survior2+Eden进行内存分配
+
+通过这种方式,只需要浪费10%的内存空间即可实现带有压缩功能的垃圾收集方法,避免了内存碎片的问题.
+
+### 4.2.3 分配担保 
+准备为一个对象分配内存时,发现此时Eden+Survior中空闲的区域无法装下该对象
+就会触发`MinorGC`(新生代 GC 算法),对该区域的废弃对象进行回收.
+
+但如果MinorGC过后只有少量对象被回收,仍然无法装下新对象
+ - 那么此时需要将Eden+Survior中的`所有对象`都`转移到老年代`中,然后再将新对象存入Eden区.这个过程就是"分配担保".
+
+在发生 minor gc 前，虚拟机会检测`老年代最大可用连续空间是否大于新生代所有对象总空间`
+若成立，minor gc 可确保安全
+若不成立，JVM会查看 `HandlePromotionFailure`是否允许担保失败
+- 若允许
+那么会继续检测老年代最大可用的连续空间是否 > 历次晋升到老年代对象的平均大小
+  - 若大于
+则将尝试进行一次 minor gc，尽管这次 minor gc 是有风险的
+  - 若小于或 HandlePromotionFailure 设置不允许冒险
+改为进行一次 full gc (老年代GC)
+
+## 4.3 标记-压缩算法(Mark-Compact)
+在回收前,标记过程仍与"标记-清除"一样
+但后续不是直接清理可回收对象,而是
+ - 将所有存活对象移到一端
+ - 直接清掉端边界之外内存
+![标记-整理算法](http://upload-images.jianshu.io/upload_images/4685968-794931bd0bba6b8d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 分析
+这是一种**老年代垃圾收集算法**.
+老年代中对象一般寿命较长,每次垃圾回收会有大量对象存活
+因此如果选用"复制"算法,每次需要較多的复制操作,效率低
+
+而且,在新生代中使用"复制"算法
+当 Eden+Survior 都装不下某个对象时,可使用老年代内存进行"分配担保"
+
+而如果在老年代使用该算法,那么在老年代中如果出现 Eden+Survior 装不下某个对象时,没有其他区域给他作分配担保
+
+因此,老年代中一般使用"标记-压缩"算法
+
+## 4.4 分代收集算法(Generational Collection)
+当前商业虚拟机都采用此算法.
+根据对象存活周期的不同将Java堆划分为老年代和新生代,根据各个年代的特点使用最佳的收集算法.
+- 老年代中对象存活率高,无额外空间对其分配担保,必须使用"标记-清除"或"标记-压缩"算法
+- 新生代中存放"朝生夕死"的对象,用复制算法,只需要付出少量存活对象的复制成本,就可完成收集
+
+# 5 Java中引用的种类
+Java中根据生命周期的长短,将引用分为4类
+- 强引用
+我们平时所使用的引用就是强引用
+类似`A a = new A();` 
+即通过关键字new创建的对象所关联的引用就是强引用
+只要强引用还存在,该对象永远不会被回收 
+- 软引用
+一些还有用但并非必需的对象
+只有当堆即将发生OOM异常时,JVM才会回收软引用所指向的对象. 
+软引用通过SoftReference类实现
+软引用的生命周期比强引用短一些 
+- 弱引用
+也是描述非必需对象,比软引用更弱
+所关联的对象只能存活到下一次GC发生前.
+只要垃圾收集器工作,无论内存是否足够,弱引用所关联的对象都会被回收. 
+弱引用通过WeakReference类实现. 
+- 虚引用
+也叫幽灵(幻影)引用,最弱的引用关系.
+它和没有引用没有区别,无法通过虚引用取得对象实例. 
+设置虚引用唯一的作用就是在该对象被回收之前收到一条系统通知. 
+虚引用通过PhantomReference类来实现.
+
+
+
diff --git "a/Java/JVM/JVM\345\256\236\346\210\230---\345\257\271\350\261\241\345\256\236\344\276\213\345\214\226.md" "b/Java/JVM/JVM\345\256\236\346\210\230---\345\257\271\350\261\241\345\256\236\344\276\213\345\214\226.md"
new file mode 100644
index 0000000000..aa67ce8ca4
--- /dev/null
+++ "b/Java/JVM/JVM\345\256\236\346\210\230---\345\257\271\350\261\241\345\256\236\344\276\213\345\214\226.md"
@@ -0,0 +1,108 @@
+Java是面向对象的静态强类型语言，声明并创建对象的代码很常见，根据某个类声明一个引用变量指向被创建的对象，并使用此引用变量操作该对象
+在实例化对象的过程中，JVM中发生了什么化学反应呢?
+
+(1)下面从最简单的
+![](https://upload-images.jianshu.io/upload_images/4685968-2746aafdc112f2e5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+代码进行分析，利用javap -verbose- p命令查看对象创建的字节码
+![](https://upload-images.jianshu.io/upload_images/4685968-e237247e0a2739df.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+● new : 如果找不到Class对象,则进行类加载
+加载成功后,则在堆中分配内存,从`Object`开始到本类路径上的所有属性值都要分配内存
+分配完毕之后，进行零值初始化
+在分配过程中，注意引用是占据存储空间的,它是一个变量,占用4个字节
+这个指令完毕后，将指向实例对象的引用变量压入虛拟机栈顶
+
+● dup : 在栈顶复制该引用变量,这时的栈顶有两个指向堆内实例对象的引用变量
+如果`<init>`方法有参数,还需要把参数压入操作栈中
+两个引用变量的目的不同,其中压至底下的引用用于赋值,或者保存到局部变量表,另一个栈顶的引用变量作为句柄调用相关方法
+
+● invokespecial : 调用对象实例方法,通过栈顶的引用变量调用<init>方法
+-  `<clinit>`是类初始化时执行的方法
+- <init>是对象初始化时执行的方法
+
+(2) 前面所述是从字节码的角度看待对象的创建过程，现在从执行步骤的角度来分析:
+● 确认类元信息是否存在
+当JVM接收到new指令时，首先在`metaspace`内检查需要创建的类元信息是否存在
+若不存在,在双亲委派模式下，使用当前类加载器以`ClassLoader+包名+类名`为Key进行查找对应的.class文件
+- 如果没有找到文件，则抛出`ClassNotFoundException`
+- 如果找到，则进行类加载，并生成对应的Class类对象
+
+● 分配对象内存
+首先计算对象占用空间大小，如果实例成员变量是引用变量，仅分配引用变量空间即可(4个字节),接着在堆中划分一块内存给新对象
+在分配内存空间时,需要进行同步操作,比如采用CAS失败重试、区域加锁等方式保证分配操作的原子性
+
+● 设定默认值
+成员变量值都需要设定为默认值，即各种不同形式的零值
+
+● 设置对象头
+设置新对象的哈希码、GC信息、锁信息对象所属的类元信息等
+这个过程的具体设置方式取决于JVM实现
+
+● 执行init方法
+初始化成员变量，执行实例化代码块，调用类的构造方法，并把堆内对象的首地址赋值给引用变量
+
+# 1 对象的创建过程
+当虚拟机遇到一条含有new的指令时,会进行一系列对象创建的操作
+ 1. 检查常量池中是否有要创建的这个对象所属类的符号引用
+  - 若无,说明这个类还没有被定义!抛ClassNotFoundException
+  - 若有,转2
+  2. 检查这个符号引用所代表的类是否已被JVM加载
+  - 若否,就找该类的class文件,并加载进方法区
+  - 若是,转3
+  3. 根据方法区中该类的信息确定该类所需的内存大小 
+ 一个对象所需的内存大小是在这个对象所属类被定义完就能确定的!
+且一个类所生产的所有对象的内存大小是一样的!
+JVM在一个类被加载进方法区的时候就知道该类生产的每一个对象所需要的内存大小
+从堆中划分一块对应大小的内存空间给新的对象,分配堆中内存有两种方式
+- 指针碰撞(Bump the Pointer) 
+如果JVM的垃圾收集器采用**复制算法**或**标记-整理算法**,那么堆中空闲内存是完整的区域,并且空闲内存和已使用内存之间由一个指针标记.
+那么当为一个对象分配内存时,只需移动指针即可.因此,这种在完整空闲区域上通过移动指针来分配内存的方式就叫做"指针碰撞"
+- 空闲列表 (Free List)
+如果JVM的GC器采用**标记-清除算法**,那么堆中空闲区域和已使用区域交错，因此需要用一张“空闲列表”来记录堆中哪些区域是空闲区域，从而在创建对象的时候根据这张“空闲列表”找到空闲区域，并分配内存
+
+综上所述：JVM究竟采用哪种内存分配方法，取决于它使用了何种GC器
+为对象中的成员变量赋上初始值(默认初始化)
+ 4. 设置对象头(Object Header)
+ 5. 调用对象的构造函数进行初始化 
+
+至此,整个对象的创建过程就完成了
+# 2 对象的内存布局
+一个对象从逻辑角度看,由域和方法构成
+从物理角度来看,对象是存储在堆中的一串二进制数
+
+对象在内存中存储的布局分三部分
+ 
+- 对象头(Header)
+- 实例数据(Instance Data)
+- 对齐补充(Padding)
+##2.1 对象头                                                                                                                
+- 存储对象在运行过程中自身所需要的一些数据
+哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等
+ - 类型指针
+  即对象指向它的类元数据的指针,JVM通过该指针能确定这个对象是哪个类的实例.
+  另外,如果对象是一个数组,那么对象头中还要包含数组长度(因为从数组的元数据无法确定数组的大小).
+ ##2.2 实例数据
+实例数据部分就是程序定义的各种字段的内容,包含父/子类的都会记录下来
+##2.3 对齐填充(并非必然存在,无特别含义,仅起占位符作用)
+HotSpot要求对象的大小必须是8字节的整数倍
+由于对象起始地址必须是8字节的整数倍,但实例数据部分的长度是任意的,因此需要对齐补充字段确保整个对象的总长度为8的整数倍
+# 3 访问对象的过程
+栈上的reference数据存放的是一个地址,那么根据地址类型的不同,对象有不同的访问方式
+- 句柄访问方式 
+Java堆中需要有一块叫做"句柄池"的内存,存放所有对象的地址和所有对象所属类的类信息 
+![](http://upload-images.jianshu.io/upload_images/4685968-0cef2d0c4cf527d0?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+reference中存放的是对象在句柄池中的地址.
+访问对象时,首先需要通过reference找到该对象的句柄,然后根据句柄中对象的地址再访问对象
+- 直接指针访问方式 
+reference直接存放对象地址,从而不需要句柄池,通过引用能够直接访问对象 
+但对象所在的内存空间中需要额外的策略存储对象所属的类信息的地址   
+![](http://upload-images.jianshu.io/upload_images/4685968-ca169ca1646753a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 两种方式的比较        
+使用句柄最大好处是reference中存储的是稳定的句柄地址,在对象被移动时也只改变句柄中的实例数据指针,而reference本身不需要修改                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
+`而HotSpot采用直接指针访问方式`,因为它只需一次寻址操作,节省了一次指针定位的时间开销,对象的访问又十分频繁,从而性能比句柄访问方式快一倍
+
+
+
+
+
diff --git "a/Java/JVM/JVM\345\256\236\346\210\230---\346\216\242\347\247\230HotSpot\350\231\232\346\213\237\346\234\272\345\257\271\350\261\241.md" "b/Java/JVM/JVM\345\256\236\346\210\230---\346\216\242\347\247\230HotSpot\350\231\232\346\213\237\346\234\272\345\257\271\350\261\241.md"
new file mode 100644
index 0000000000..b36eb00981
--- /dev/null
+++ "b/Java/JVM/JVM\345\256\236\346\210\230---\346\216\242\347\247\230HotSpot\350\231\232\346\213\237\346\234\272\345\257\271\350\261\241.md"
@@ -0,0 +1,121 @@
+Java是面向对象的静态强类型语言，声明并创建对象的代码很常见，根据某个类声明一个引用变量指向被创建的对象，并使用此引用变量操作该对象
+
+在实例化对象的过程中，JVM中发生了什么呢?
+
+(1)下面从最简单的
+![](https://upload-images.jianshu.io/upload_images/4685968-2746aafdc112f2e5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+代码进行分析，利用javap -verbose- p命令查看对象创建的字节码
+![](https://upload-images.jianshu.io/upload_images/4685968-e237247e0a2739df.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+● new : 如果找不到Class对象,则进行类加载
+加载成功后,则在堆中分配内存,从`Object`开始到本类路径上的所有属性值都要分配内存
+分配完毕之后，进行零值初始化
+在分配过程中，注意引用是占据存储空间的,它是一个变量,占用4个字节
+这个指令完毕后，将指向实例对象的引用变量压入虛拟机栈顶
+
+● dup : 在栈顶复制该引用变量,这时的栈顶有两个指向堆内实例对象的引用变量
+如果`<init>`方法有参数,还需要把参数压入操作栈中
+两个引用变量的目的不同,其中压至底下的引用用于赋值,或者保存到局部变量表,另一个栈顶的引用变量作为句柄调用相关方法
+
+● invokespecial : 调用对象实例方法,通过栈顶的引用变量调用<init>方法
+-  `<clinit>`是类初始化时执行的方法
+- <init>是对象初始化时执行的方法
+
+(2) 前面所述是从字节码的角度看待对象的创建过程，现在从执行步骤的角度来分析:
+● 确认类元信息是否存在
+当JVM接收到new指令时，首先在`metaspace`内检查需要创建的类元信息是否存在
+若不存在,在双亲委派模式下，使用当前类加载器以`ClassLoader+包名+类名`为Key进行查找对应的.class文件
+- 如果没有找到文件，则抛出`ClassNotFoundException`
+- 如果找到，则进行类加载，并生成对应的Class类对象
+
+● 分配对象内存
+首先计算对象占用空间大小，如果实例成员变量是引用变量，仅分配引用变量空间即可(4个字节),接着在堆中划分一块内存给新对象
+在分配内存空间时,需要进行同步操作,比如采用CAS失败重试、区域加锁等方式保证分配操作的原子性
+
+● 设定默认值
+成员变量值都需要设定为默认值，即各种不同形式的零值
+
+● 设置对象头
+设置新对象的哈希码、GC信息、锁信息对象所属的类元信息等
+这个过程的具体设置方式取决于JVM实现
+
+● 执行init方法
+初始化成员变量，执行实例化代码块，调用类的构造方法，并把堆内对象的首地址赋值给引用变量
+
+# 1 对象的创建
+当虚拟机遇到一条含有new的指令时,会进行一系列对象创建的操作
+
+1.检查常量池中是否有要创建的这个对象所属类的符号引用
+  - 若无,说明这个类还没有被定义!抛ClassNotFoundException
+  - 若有,转2
+  
+  
+2.检查这个符号引用所代表的类是否已被JVM加载
+  - 若否,就找该类的class文件,并加载进方法区
+  - 若是,转3
+ 
+3.根据方法区中该类的信息确定该类所需的内存大小 
+ 
+一个对象所需的内存大小是在这个对象所属类被定义完就能确定的!
+
+且一个类所生产的所有对象的内存大小是一样的!
+
+JVM在一个类被加载进方法区的时候就知道该类生产的每一个对象所需要的内存大小
+从堆中划分一块对应大小的内存空间给新的对象,分配堆中内存有两种方式
+- 指针碰撞(Bump the Pointer) 
+如果JVM的垃圾收集器采用**复制算法**或**标记-整理算法**,那么堆中空闲内存是完整的区域,并且空闲内存和已使用内存之间由一个指针标记.
+那么当为一个对象分配内存时,只需移动指针即可.因此,这种在完整空闲区域上通过移动指针来分配内存的方式就叫做"指针碰撞"
+- 空闲列表 (Free List)
+如果JVM的GC器采用**标记-清除算法**,那么堆中空闲区域和已使用区域交错，因此需要用一张“空闲列表”来记录堆中哪些区域是空闲区域，从而在创建对象的时候根据这张“空闲列表”找到空闲区域，并分配内存
+
+综上所述：JVM究竟采用哪种内存分配方法，取决于它使用了何种GC器
+为对象中的成员变量赋上初始值(默认初始化)
+ 4. 设置对象头(Object Header)
+ 5. 调用对象的构造函数进行初始化 
+
+至此,整个对象的创建过程就完成了
+
+# 2 对象的内存布局
+一个对象从逻辑角度看,由域和方法构成
+从物理角度来看,对象是存储在堆中的一串二进制数
+
+对象在内存中存储的布局分三部分
+ 
+- 对象头(Header)
+- 实例数据(Instance Data)
+- 对齐补充(Padding)
+
+## 2.1 对象头                                                                                                                
+- 存储对象在运行过程中自身所需要的一些数据
+哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等
+ - 类型指针
+  即对象指向它的类元数据的指针,JVM通过该指针能确定这个对象是哪个类的实例.
+  另外,如果对象是一个数组,那么对象头中还要包含数组长度(因为从数组的元数据无法确定数组的大小).
+
+## 2.2 实例数据
+实例数据部分就是程序定义的各种字段的内容,包含父/子类的都会记录下来
+
+## 2.3 对齐填充(并非必然存在,无特别含义,仅起占位符作用)
+HotSpot要求对象的大小必须是8字节的整数倍
+由于对象起始地址必须是8字节的整数倍,但实例数据部分的长度是任意的,因此需要对齐补充字段确保整个对象的总长度为8的整数倍
+
+# 3 访问对象的过程
+栈上的reference数据存放的是一个地址,那么根据地址类型的不同,对象有不同的访问方式
+- 句柄访问方式 
+Java堆中需要有一块叫做"句柄池"的内存,存放所有对象的地址和所有对象所属类的类信息 
+![](http://upload-images.jianshu.io/upload_images/4685968-0cef2d0c4cf527d0?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+reference中存放的是对象在句柄池中的地址.
+访问对象时,首先需要通过reference找到该对象的句柄,然后根据句柄中对象的地址再访问对象
+- 直接指针访问方式 
+reference直接存放对象地址,从而不需要句柄池,通过引用能够直接访问对象 
+但对象所在的内存空间中需要额外的策略存储对象所属的类信息的地址   
+![](http://upload-images.jianshu.io/upload_images/4685968-ca169ca1646753a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 两种方式的比较        
+使用句柄最大好处是reference中存储的是稳定的句柄地址,在对象被移动时也只改变句柄中的实例数据指针,而reference本身不需要修改                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
+`而HotSpot采用直接指针访问方式`,因为它只需一次寻址操作,节省了一次指针定位的时间开销,对象的访问又十分频繁,从而性能比句柄访问方式快一倍
+
+
+
+
+
diff --git "a/Java/JVM/JVM\345\256\236\346\210\230---\347\261\273\345\212\240\350\275\275\347\232\204\350\277\207\347\250\213.md" "b/Java/JVM/JVM\345\256\236\346\210\230---\347\261\273\345\212\240\350\275\275\347\232\204\350\277\207\347\250\213.md"
new file mode 100644
index 0000000000..b7400587b9
--- /dev/null
+++ "b/Java/JVM/JVM\345\256\236\346\210\230---\347\261\273\345\212\240\350\275\275\347\232\204\350\277\207\347\250\213.md"
@@ -0,0 +1,275 @@
+任何程序都需要加载到内存才能与CPU进行交流
+同理, 字节码.class文件同样需要加载到内存中，才可以实例化类
+`ClassLoader`的使命就是提前加载.class 类文件到内存中
+在加载类时，使用的是Parents Delegation Model(溯源委派加载模型)
+
+Java的类加载器是一个运行时核心基础设施模块，主要是在启动之初进行类的加载、链接、初始化
+![Java 类加载过程](https://upload-images.jianshu.io/upload_images/4685968-bfddab53299e22e4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 第一步，Load阶段
+读取类文件产生二进制流，并转为特定数据结构，初步校验cafe babe魔法数、常量池、文件长度、是否有父类等，然后创建对应类的java.lang.Class实例
+
+## 第二步，Link阶段
+包括验证、准备、解析三个步骤
+- 验证是更详细的校验，比如final是否合规、类型是否正确、静态变量是否合理等
+- 准备阶段是为静态变量分配内存，并设定默认值，解析类和方法确保类与类之间的相互引用正确性，完成内存结构布局
+## 第三步，Init 阶段
+执行类构造器<clinit> 方法，如果赋值运算是通过其他类的静态方法来完成的，那么会马上解析另外一个类，在虚拟机栈中执行完毕后通过返回值进行赋值
+
+ 类加载是一个将.class字节码文件实例化成Class对象并进行相关初始化的过程。
+在这个过程中，JVM会初始化继承树上还没有被初始化过的所有父类，并且会执行这个链路上所有未执行过的静态代码块、静态变量赋值语句等。
+某些类在使用时，也可以按需由类加载器进行加载。
+
+全小写的class是关键字，用来定义类
+而首字母大写的Class,它是所有class的类
+这句话理解起来有难度，类已经是现实世界中某种事物的抽象，为什么这个抽象还是另外一个类Class的对象?
+示例代码如下:
+![](https://upload-images.jianshu.io/upload_images/4685968-341974cb59ee682a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7ebceb2445fc0725.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5bd82815858024ae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a82c475218ac4970.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ ● 第1处说明:
+Class类下的`newInstance()`在JDK9中已经置为过时，使用`getDeclaredConstructor().newInstance()`的方式
+着重说明一下new与newInstance的区别
+- new是强类型校验，可以调用任何构造方法，在使用new操作的时候，这个类可以没有被加载过
+- 而Class类下的newInstance是弱类型，只能调用无参构造方法
+    - 如果没有默认构造方法，就拋出`InstantiationException`异常;
+    - 如果此构造方法没有权限访问，则拋 `IllegalAccessException`异常
+
+Java 通过类加载器把类的实现与类的定义进行解耦，所以是实现面向接口编程、依赖倒置的必然选择。
+
+● 第2处说明:
+可以使用类似的方式获取其他声明，如注解、方法等
+![类的反射信息](https://upload-images.jianshu.io/upload_images/4685968-7d54a82692945875.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+   
+● 第3处说明: private 成员在类外是否可以修改?
+通过`setccessible(true)`,即可使用Class类的set方法修改其值
+如果没有这一步,则抛出如下异常:
+![](https://upload-images.jianshu.io/upload_images/4685968-47acf654ed276c95.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 类加载器
+类加载器是如何定位具体的类文件并读取的呢?
+
+在类加载器家族中存在着类似人类社会的权力等级制度
+
+- 最高层的`Bootstrap`
+在JVM启动时创建的,通常由与操作系统相关的本地代码实现,是最根基的类加载器,负责装载最核心的Java类,比如Object、System、 String ,Java运行时的rt.jar等jar包
+- JDK9的`Platform ClassLoader`
+负责加载<JAVA_HOME>\lib\ext目录中的，或者java.ext.dirs系统变量指定的路径中的所以类库;
+加载一些扩展的系统类，比如XML、加密、压缩相关的功能类等;
+JDK9之前是`Extension ClassLoader`.
+- 第三层 `Application ClassLoader` 
+应用类加载器，主要是加载用户定义的`CLASSPATH`路径下的类
+
+第二、三层类加载器为Java语言实现，用户也可以自定义类加载器
+查看本地类加载器的方式如下:
+![](https://upload-images.jianshu.io/upload_images/4685968-c6a9d7f0910d3bdc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+在JDK8环境中，执行结果如下
+![](https://upload-images.jianshu.io/upload_images/4685968-a1b077e3a4bc4af3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+AppClassLoader的Parent为Bootstrap,它是通过C/C++实现的，并不存在于JVM体系内,所以输出为 null
+![](https://upload-images.jianshu.io/upload_images/4685968-d6de545693f4fcb1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+低层次的当前类加载器，不能覆盖更高层次类加载器已经加载的类
+如果低层次的类加载器想加载一个未知类，要非常礼貌地向上逐级询问:“请问，这个类已经加载了吗?”
+被询问的高层次类加载器会自问两个问题
+- 我是否已加载过此类
+- 如果没有，是否可以加载此类
+
+只有当所有高层次类加载器在两个问题的答案均为“否”时，才可以让当前类加载器加载这个未知类
+左侧绿色箭头向上逐级询问是否已加载此类，直至`Bootstrap ClassLoader`,然后向下逐级尝试是否能够加载此类，如果都加载不了，则通知发起加载请求的当前类加载器，准予加载
+在右侧的三个小标签里，列举了此层类加载器主要加载的代表性类库，事实上不止于此
+
+通过如下代码可以查看Bootstrap 所有已加载类库
+![](https://upload-images.jianshu.io/upload_images/4685968-840a04505b5cb5a8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+执行结果
+![](https://upload-images.jianshu.io/upload_images/4685968-cb57ddcff0fd24ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+Bootstrap加载的路径可以追加，不建议修改或删除原有加载路径
+在JVM中增加如下启动参数，则能通过`Class.forName`正常读取到指定类，说明此参数可以增加Bootstrap的类加载路径:
+```
+-Xbootclasspath/a:/Users/sss/book/ easyCoding/byJdk11/src
+```
+如果想在启动时观察加载了哪个jar包中的哪个类，可以增加
+```
+-XX:+TraceClassLoading
+```
+此参数在解决类冲突时非常实用，毕竟不同的JVM环境对于加载类的顺序并非是一致的
+有时想观察特定类的加载上下文，由于加载的类数量众多，调试时很难捕捉到指定类的加载过程，这时可以使用条件断点功能
+比如，想查看HashMap的加载过程，在loadClass处打个断点，并且在condition框内输入如图
+![设置条件断点](https://upload-images.jianshu.io/upload_images/4685968-6a294b8a75dac812.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### JVM如何确立每个类在JVM的唯一性
+类的全限定名和加载这个类的类加载器的ID
+
+在学习了类加载器的实现机制后，知道双亲委派模型并非强制模型，用户可以自定义类加载器，在什么情况下需要自定义类加载器呢?
+- 隔离加载类
+在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境
+比如，阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包
+- 修改类加载方式
+类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载
+- 扩展加载源
+比如从数据库、网络，甚至是电视机机顶盒进行加载
+- 防止源码泄露
+Java代码容易被编译和篡改，可以进行编译加密。那么类加载器也需要自定义，还原加密的字节码。
+
+实现自定义类加载器的步骤
+- 继承ClassLoader
+- 重写findClass()方法
+- 调用defineClass()方法
+
+一个简单的类加载器实现的示例代码如下
+![](https://upload-images.jianshu.io/upload_images/4685968-7bb954b558e90030.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+由于中间件一般都有自己的依赖jar包，在同一个工程内引用多个框架时，往往被迫进行类的仲裁
+按某种规则jar包的版本被统一指定， 导致某些类存在包路径、类名相同的情况，就会引起类冲突，导致应用程序出现异常
+主流的容器类框架都会自定义类加载器，实现不同中间件之间的类隔离，有效避免了类冲突。
+# 1 加载的定位
+> “加载”是“类加载”(Class Loading)过程的第一步
+## 1.1 加载的过程
+在加载的过程中,JVM主要做3件事情
+- 通过一个类的全限定名来获取定义此类的二进制字节流(class文件)
+在程序运行过程中,当要访问一个类时,若发现这个类尚未被加载,并满足类初始化的条件时，就根据要被初始化的这个类的全限定名找到该类的二进制字节流,开始加载过程
+- 将这个字节流的静态存储结构转化为方法区的运行时数据结构
+- 在内存中创建一个该类的java.lang.Class对象,作为方法区该类的各种数据的访问入口
+
+程序在运行中所有对该类的访问都通过这个类对象,也就是这个Class对象是提供给外界访问该类的接口
+## 1.2 加载源
+JVM规范对于加载过程给予了较大的宽松度.一般二进制字节流都从已经编译好的本地class文件中读取,此外还可以从以下地方读取
+- zip包
+Jar、War、Ear等
+- 其它文件生成 
+由JSP文件中生成对应的Class类.
+- 数据库中
+将二进制字节流存储至数据库中,然后在加载时从数据库中读取.有些中间件会这么做,用来实现代码在集群间分发
+- 网络
+从网络中获取二进制字节流.典型就是Applet.
+- 运行时计算生成
+动态代理技术,用PRoxyGenerator.generateProxyClass为特定接口生成形式为"*$Proxy"的代理类的二进制字节流.
+## 1.3 类和数组加载过程的区别
+数组也有类型,称为“数组类型”.如:
+```
+String[] str = new String[10];
+```
+这个数组的数组类型是`Ljava.lang.String`,而String只是这个数组的元素类型
+
+当程序在运行过程中遇到new关键字创建一个数组时,由JVM直接创建数组类,再由类加载器创建数组中的元素类型.
+
+而普通类的加载由类加载器创建.既可以使用系统提供的引导类加载器,也可以由用户自定义的类加载器完成(即重写一个类加载器的loadClass()方法)
+## 1.4 加载过程的注意点
+- JVM规范并未给出类在方法区中存放的数据结构 
+类完成加载后,二进制字节流就以特定的数据结构存储在方法区中,但存储的数据结构是由虚拟机自己定义的,虚拟机规范并没有指定
+- JVM规范并没有指定Class对象存放的位置 
+在二进制字节流以特定格式存储在方法区后,JVM会创建一个java.lang.Class类的对象,作为本类的外部访问接口
+既然是对象就应该存放在Java堆中,不过JVM规范并没有给出限制,不同的虚拟机根据自己的需求存放这个对象
+HotSpot将Class对象存放在方法区.
+- 加载阶段和链接阶段是交叉的 
+类加载的过程中每个步骤的开始顺序都有严格限制,但每个步骤的结束顺序没有限制.也就是说,类加载过程中,必须按照如下顺序开始: 
+>加载 -> 链接 -> 初始化
+
+但结束顺序无所谓,因此由于每个步骤处理时间的长短不一就会导致有些步骤会出现交叉 
+# 2 验证
+验证阶段比较耗时,它非常重要但不一定必要(因为对程序运行期没有影响),如果所运行的代码已经被反复使用和验证过,那么可以使用`-Xverify:none`参数关闭,以缩短类加载时间
+## 2.1 验证的目的
+保证二进制字节流中的信息符合虚拟机规范,并没有安全问题
+## 2.2 验证的必要性
+虽然Java语言是一门安全的语言,它能确保程序猿无法访问数组边界以外的内存、避免让一个对象转换成任意类型、避免跳转到不存在的代码行.也就是说,Java语言的安全性是通过编译器来保证的.
+
+但是我们知道,编译器和虚拟机是两个独立的东西,虚拟机只认二进制字节流,它不会管所获得的二进制字节流是哪来的，当然，如果是编译器给它的，那么就相对安全，但如果是从其它途径获得的，那么无法确保该二进制字节流是安全的。
+
+通过上文可知，虚拟机规范中没有限制二进制字节流的来源，在字节码层面上,上述Java代码无法做到的都是可以实现的,至少语义上是可以表达出来的,为了防止字节流中有安全问题，需要验证！
+## 2.3 验证的过程
+- 文件格式验证 
+验证字节流是否符合Class文件格式的规范,并且能被当前的虚拟机处理.
+本验证阶段是基于二进制字节流进行的,只有`通过本阶段验证,才被允许存到方法区`
+后面的三个验证阶段都是基于方法区的存储结构进行,不会再直接操作字节流.
+
+> 通过上文可知，加载开始前，二进制字节流还没进方法区，而加载完成后，二进制字节流已经存入方法区
+> 而在文件格式验证前，二进制字节流尚未进入方法区，文件格式验证通过之后才进入方法区
+> 也就是说，加载开始后，立即启动了文件格式验证，本阶段验证通过后，二进制字节流被转换成特定数据结构存储至方法区中，继而开始下阶段的验证和创建Class对象等操作
+这个过程印证了：加载和验证是交叉进行的
+
+- 元数据验证 
+对字节码描述信息进行语义分析,确保符合Java语法规范.
+- 字节码验证 
+本阶段是验证过程的最复杂的一个阶段. 
+本阶段对方法体进行语义分析,保证方法在运行时不会出现危害虚拟机的事件.
+字节码验证将对类的方法进行校验分析，保证被校验的方法在运行时不会做出危害虚拟机的事，一个类方法体的字节码没有通过字节码验证，那一定有问题，但若一个方法通过了验证，也不能说明它一定安全
+- 符号引用验证 
+发生在JVM将符号引用转化为直接引用的时候,这个转化动作发生在解析阶段,对类自身以外的信息进行匹配校验,确保解析能正常执行.
+# 3 准备
+完成两件事情
+- 为已在方法区中的类的静态成员变量分配内存 
+- 为静态成员变量设置初始值 
+初始值为0、false、null等
+![](http://upload-images.jianshu.io/upload_images/4685968-f62a56c034c51820.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+public static final int value = 123;
+```
+准备阶段后 a 的值为 0，而不是 123，要在初始化之后才变为 123,但若被final修饰的常量如果有初始值,那么在编译阶段就会将初始值存入constantValue属性中,在准备阶段就将constantValue的值赋给该字段(此处将value赋为123).
+# 4 解析
+解析阶段是虚拟机将常量池中的符号引用替换为直接引用的过程.
+# 5 初始化
+真正开始执行类中定义的Java程序代码(或者说是字节码)
+初始化阶段就是执行类构造器clinit()的过程.
+
+clinit()方法由编译器自动产生，收集类中static{}代码块中的类变量赋值语句和类中静态成员变量的赋值语句。在准备阶段，类中静态成员变量已经完成了默认初始化，而在初始化阶段，clinit()方法对静态成员变量进行显示初始化。
+## 5.1 初始化过程的注意点
+- clinit()方法是IDE自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的,IDE收集的顺序是由语句在源文件中出现的顺序所决定的.
+- 静态代码块只能访问到出现在静态代码块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问.
+```
+public class Test {
+    static {
+        i=0;
+        System.out.println(i);//编译失败:"非法向前引用"
+    }
+    static int i = 1;
+}
+```
+- 实例构造器init()需要显示调用父类构造函数,而类的clinit()不需要调用父类的类构造函数,虚拟机会确保子类的clinit()方法执行前已经执行完毕父类的clinit()方法.因此在JVM中第一个被执行的clinit()方法的类肯定是java.lang.Object.
+- 如果一个类/接口中没有静态代码块,也没有静态成员变量的赋值操作,那么编译器就不会为此类生成clinit()方法.
+- 接口也需要通过clinit()方法为接口中定义的静态成员变量显示初始化。
+- 接口中不能使用静态代码块,但仍然有变量初始化的赋值操作,因此接口与类一样都会生成clinit()方法.不同的是,执行接口的clinit()方法不需要先执行父接口的clinit()方法.只有当父接口中的静态成员变量被使用到时才会执行父接口的clinit()方法.
+- 虚拟机会保证在多线程环境中一个类的clinit()方法别正确地加锁,同步.当多条线程同时去初始化一个类时，只会有一个线程去执行该类的clinit()方法,其它线程都被阻塞等待,直到活动线程执行clinit()方法完毕.
+
+> 其他线程虽会被阻塞,只要有一个clinit()方法执行完,其它线程唤醒后不会再进入clinit()方法.同一个类加载器下,一个类型只会初始化一次.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\343\200\207)---\347\256\200\344\273\213.md" "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\343\200\207)---\347\256\200\344\273\213.md"
new file mode 100644
index 0000000000..fe72d78775
--- /dev/null
+++ "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\343\200\207)---\347\256\200\344\273\213.md"
@@ -0,0 +1,28 @@
+![](https://upload-images.jianshu.io/upload_images/4685968-33035abe8ef76f8e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-cf91eb08b7f1bcc4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-8a997d2ecc519ba3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c0d46a45f844ac9d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-127a9f968b9f2bca.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d21348cd6b5a6a2c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c549d2ebba4007c9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-4f04d0a3ecdd8090.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 收获
+![](https://upload-images.jianshu.io/upload_images/4685968-d5e1011563b06859.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-48afdfa386f84979.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9c4a89f78443980b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-02999327f173ffd5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-b1d769508ccc15b9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 计划安排
+## 基于JDK命令行工具的监控
+![](https://upload-images.jianshu.io/upload_images/4685968-19b4acab0cf50a41.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3ccb5c411b7a9942.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 基于Btrace的监控调试
+![](https://upload-images.jianshu.io/upload_images/4685968-273b74fc03cb7e7f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## Tomcat性能监控与调优
+![](https://upload-images.jianshu.io/upload_images/4685968-91b0634596ca43be.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##  Nginx性能监控与调优
+![](https://upload-images.jianshu.io/upload_images/4685968-090cbb1c0a829cdd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## JVM层GC调优
+![](https://upload-images.jianshu.io/upload_images/4685968-b8579d32e4aa76ca.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## JVM字节码与Java代码层调优
+![](https://upload-images.jianshu.io/upload_images/4685968-8bad9b8d0c9cc3dc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\200)---\345\237\272\344\272\216JDK\345\221\275\344\273\244\350\241\214\347\232\204\347\233\221\346\216\247.md" "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\200)---\345\237\272\344\272\216JDK\345\221\275\344\273\244\350\241\214\347\232\204\347\233\221\346\216\247.md"
new file mode 100644
index 0000000000..ec0dc4b3d6
--- /dev/null
+++ "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\200)---\345\237\272\344\272\216JDK\345\221\275\344\273\244\350\241\214\347\232\204\347\233\221\346\216\247.md"
@@ -0,0 +1,65 @@
+# 1 JVM的参数类型
+![](https://upload-images.jianshu.io/upload_images/4685968-c3d630c35921ef3e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 标准参数
+![](https://upload-images.jianshu.io/upload_images/4685968-d9a2caed3c70e363.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## X 参数
+![](https://upload-images.jianshu.io/upload_images/4685968-36aa325e5aa882d2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![JDK8默认混合模式](https://upload-images.jianshu.io/upload_images/4685968-d51270fdcaa59b7b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![更为编译执行](https://upload-images.jianshu.io/upload_images/4685968-e63d2a9dc4b84f81.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## XX 参数
+![](https://upload-images.jianshu.io/upload_images/4685968-df514d5bb6b1ba93.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ee3ab014c641a459.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-eb6ad233da284eb3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-dd0e0efc049f68ca.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 2 查看JVM运行时参数
+![](https://upload-images.jianshu.io/upload_images/4685968-3dc1345851a41222.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3efa76cbfa5f3729.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 查看XX选项的值
+- -XX:+PrintCommandLineFlags
+-  -XX:+PrintFlagsInitial -XX:+PrintFlagsFinal
+![](https://upload-images.jianshu.io/upload_images/4685968-3365ede0c36c24e7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2fa01042c93bb9ed.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![重定向到文本文件](https://upload-images.jianshu.io/upload_images/4685968-ba9262a02db7b704.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## jps
+![jps](https://upload-images.jianshu.io/upload_images/4685968-b001d1166ef29bd4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![jps -l](https://upload-images.jianshu.io/upload_images/4685968-7fd046c9ca7419f8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## jinfo
+![](https://upload-images.jianshu.io/upload_images/4685968-958eb9084e37765d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 3 jstat查看JVM统计信息
+![](https://upload-images.jianshu.io/upload_images/4685968-6152877a6fd3d12f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 3.1 类装载
+![](https://upload-images.jianshu.io/upload_images/4685968-fcf19859fe9853c0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 3.2 GC
+![](https://upload-images.jianshu.io/upload_images/4685968-cfcd242ffae74229.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0673720236b8c6dc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## -gc输出结果
+![](https://upload-images.jianshu.io/upload_images/4685968-21033eab9130f123.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### JVM 的内存结构
+![](https://upload-images.jianshu.io/upload_images/4685968-d1b10aef1ac30942.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## JIT 编译
+![](https://upload-images.jianshu.io/upload_images/4685968-21d0f29d0f6ebbcf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-b58d13ff46ce4199.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 4 jmap + MAT 实战内存溢出
+## 堆区
+![](https://upload-images.jianshu.io/upload_images/4685968-1799898c82d15414.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-59caf7a72915c7c6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 非堆区
+![](https://upload-images.jianshu.io/upload_images/4685968-0ad3bbee4eb603b1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3e2f874a0e5fca13.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7ef84c46801894f2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 5 导出内存映像文件
+## OutofMemory（OOM）相关的选项
+如果程序发生了OOM后，JVM可以配置一些选项来做些善后工作，比如把内存给dump下来，或者自动采取一些别的动作
+- -XX:+HeapDumpOnOutOfMemoryError
+在内存出现OOM的时候，把Heap转存(Dump)到文件以便后续分析，文件名通常是`java_pid<pid>.hprof`
+- -XX:HeapDumpPath=<path>
+指定heap转存文件的存储路径，需要指定的路径下有足够的空间来保存转存文件
+- -XX:OnOutOfMemoryError
+指定一个可行性程序或者脚本的路径，当发生OOM的时候，去执行这个脚本
+![](https://upload-images.jianshu.io/upload_images/4685968-6c2f25ca31c79899.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-38da79139ddf1ff7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5d3a5066ab57066d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d368c169ca25e061.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2d0c94547582fdbb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3d4c21c5f43717de.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 6 MAT分析内存溢出
diff --git "a/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\203)---GC-\350\260\203\344\274\230.md" "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\203)---GC-\350\260\203\344\274\230.md"
new file mode 100644
index 0000000000..a6f030693f
--- /dev/null
+++ "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\270\203)---GC-\350\260\203\344\274\230.md"
@@ -0,0 +1,26 @@
+# 0  主要内容
+![](https://upload-images.jianshu.io/upload_images/4685968-6aa986aa1a8eff2d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7b555dcce7b4a5cd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 1 内存结构
+## 1.1 运行时数据区
+![](https://upload-images.jianshu.io/upload_images/4685968-b700be36cd98f2ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![https://docs.oracle.com/javase/specs/jvms/se8/html/index.html](https://upload-images.jianshu.io/upload_images/4685968-01c553f684a22519.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### PC 寄存器
+![](https://upload-images.jianshu.io/upload_images/4685968-3c6cfeb0a9e3c47c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-6d6c5759cc058edc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### JVM 栈
+![](https://upload-images.jianshu.io/upload_images/4685968-88a03c5ffc39ed60.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-75030c323b8410b3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 堆
+![](https://upload-images.jianshu.io/upload_images/4685968-f5dd962dce7aca56.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-335dada6197f182c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 方法区
+![](https://upload-images.jianshu.io/upload_images/4685968-e1e0a7133ab2238d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-56edc462426ab336.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 运行时常量池
+![](https://upload-images.jianshu.io/upload_images/4685968-5ba743e46716fd27.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-85127110efc744f8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 本地方法栈
+![](https://upload-images.jianshu.io/upload_images/4685968-713d4580316a457c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9418b3555ae10a94.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-cb21e2dc0d99a35d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\272\214)---VM-\347\233\221\346\216\247.md" "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\272\214)---VM-\347\233\221\346\216\247.md"
new file mode 100644
index 0000000000..25f17135d6
--- /dev/null
+++ "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\344\272\214)---VM-\347\233\221\346\216\247.md"
@@ -0,0 +1,33 @@
+![](https://upload-images.jianshu.io/upload_images/4685968-a9e3e1b3e8423961.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 1 监控本地java进程
+![](https://upload-images.jianshu.io/upload_images/4685968-7afa05325eebf996.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![jvisualvm](https://upload-images.jianshu.io/upload_images/4685968-20b285175202099b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![ 可直接监视本地 Java 线程](https://upload-images.jianshu.io/upload_images/4685968-eb00cc4341eea83a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c31370bf86a70428.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-682ce936dfb2aafb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c4274175ac8106da.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-e0f0f92f558be1fd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+导入
+![](https://upload-images.jianshu.io/upload_images/4685968-c9a088a5a3909394.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-049a5e2216db1607.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-1923ddeccc6e0bfc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9b3757961f7c0589.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-002269794e5d97b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-cf0e1cb18256e2aa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 抽样器
+![](https://upload-images.jianshu.io/upload_images/4685968-8b81d75de8c5c16e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+由此,不需再使用 
+```
+System.out.println(System.currentTimeMillis());
+```
+验证方法执行时间!!!
+![](https://upload-images.jianshu.io/upload_images/4685968-345083285ef6cbbe.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+插件
+![](https://upload-images.jianshu.io/upload_images/4685968-81c0a86c878f26cb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![https://visualvm.github.io/pluginscenters.html](https://upload-images.jianshu.io/upload_images/4685968-c0017c6ad2eba92b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3cc8eed7afd2c2fb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![](https://upload-images.jianshu.io/upload_images/4685968-b301857c5fdae059.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-fd57a78ced8651d8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+安装无法连接到服务器!!!
+# 2 监控远程的java进程
diff --git "a/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\345\205\253)---Java\344\273\243\347\240\201\345\261\202\350\260\203\344\274\230\357\274\210\345\255\227\350\212\202\347\240\201\346\214\207\344\273\244\357\274\211.md" "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\345\205\253)---Java\344\273\243\347\240\201\345\261\202\350\260\203\344\274\230\357\274\210\345\255\227\350\212\202\347\240\201\346\214\207\344\273\244\357\274\211.md"
new file mode 100644
index 0000000000..2307e9da85
--- /dev/null
+++ "b/Java/JVM/JVM\346\200\247\350\203\275\350\260\203\344\274\230\345\256\236\346\210\230(\345\205\253)---Java\344\273\243\347\240\201\345\261\202\350\260\203\344\274\230\357\274\210\345\255\227\350\212\202\347\240\201\346\214\207\344\273\244\357\274\211.md"
@@ -0,0 +1,243 @@
+# 0 主要内容
+![](https://upload-images.jianshu.io/upload_images/4685968-98d2f60376422b87.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#1 JVM字节码指令与 javap
+![](https://upload-images.jianshu.io/upload_images/4685968-b7c70f5b346ef29d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 样例代码
+![](https://upload-images.jianshu.io/upload_images/4685968-562849e9307f4f8a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 将结果重定向到一个 txt 文件中，便于分析
+![](https://upload-images.jianshu.io/upload_images/4685968-864542f0bc938769.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## Field Descriptors
+字段描述符表示类，实例或局部变量的类型。它是由语法生成的一系列字符：
+```
+FieldDescriptor:
+    FieldType
+
+FieldType:
+    BaseType
+    ObjectType
+    ArrayType	
+
+BaseType:
+    B
+    C
+    D
+    F
+    I
+    J
+    S
+    Z
+
+ObjectType:
+    L ClassName ;
+
+ArrayType:
+    [ ComponentType
+
+ComponentType:
+    FieldType
+```
+`L ClassName；`： 引用类型
+`[`  ： 数组类型
+都是ASCII字符
+
+ClassName表示以内部形式编码的二进制类或接口名称
+
+字段描述符的解释类型如表
+![](https://upload-images.jianshu.io/upload_images/4685968-16239c4760aaa62e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+表示数组类型的字段描述符仅在表示具有255或更少维度的类型时才有效
+
+int类型的实例变量的字段描述符就是I.
+
+Object类型的实例变量的字段描述符是`Ljava / lang / Object`
+请注意，使用的是类Object的二进制名称的内部形式。 
+
+一个多维double数组实例变量的字段描述符，double d [] [] []，是[[[D
+## Method Descriptors
+方法描述符表示方法采用的参数及其返回的值：
+```
+MethodDescriptor:
+    ( ParameterDescriptor* ) ReturnDescriptor
+```
+参数描述符表示传递给方法的参数：
+```
+ParameterDescriptor:
+    FieldType
+```
+返回描述符表示从方法返回的值的类型。它是由语法生成的一系列字符：
+```
+ReturnDescriptor:
+    FieldType
+    VoidDescriptor
+
+VoidDescriptor:
+    V
+```
+字符V表示该方法没有返回值（其返回类型为void）
+
+方法描述符仅在表示总长度为255或更小的方法参数时才有效，其中该长度包括在实例或接口方法调用的情况下对此的贡献
+总长度是通过对各个参数的贡献求和来计算的，其中long或double类型的参数对长度贡献两个单位，而任何其他类型的参数贡献一个单位
+
+### 方法的方法描述符
+比如方法
+```
+Object m(int i, double d, Thread t) {..}
+```
+是`（IDLjava / lang / Thread;）Ljava / lang / Object;`
+注意，使用了Thread和Object的二进制名称的内部形式 
+
+无论m是类方法还是实例方法,对于m的方法描述符是相同的
+虽然传递了一个实例方法，但是除了预期的参数之外，对当前类实例的引用不会反映在方法描述符中
+对此的引用由调用实例方法的Java虚拟机的方法调用指令隐式传递
+对此的引用不会传递给类方法。
+```
+Classfile /Volumes/doc/IDEAProjects/monitor_tuning/target/classes/com/sss/monitortuning/cp8/Test1.class
+  Last modified 2019-1-4; size 629 bytes
+  MD5 checksum 91438ed9eb3506def6a5580d6b448ebb
+  Compiled from "Test1.java"
+public class com.sss.monitortuning.cp8.Test1
+  minor version: 0
+  major version: 52  // JDK版本号
+  flags: ACC_PUBLIC, ACC_SUPER
+// 常量池
+Constant pool:
+   #1 = Methodref          #5.#24         // java/lang/Object."<init>":()V
+   #2 = Fieldref           #25.#26        // java/lang/System.out:Ljava/io/PrintStream;
+   #3 = Methodref          #27.#28        // java/io/PrintStream.println:(I)V
+   #4 = Class              #29            // com/sss/monitortuning/cp8/Test1 即类名
+   #5 = Class              #30            // java/lang/Object
+   #6 = Utf8               <init>
+   #7 = Utf8               ()V
+   #8 = Utf8               Code
+   #9 = Utf8               LineNumberTable
+  #10 = Utf8               LocalVariableTable
+  #11 = Utf8               this
+  #12 = Utf8               Lcom/sss/monitortuning/cp8/Test1;
+  #13 = Utf8               main
+  #14 = Utf8               (Ljava/lang/String;)V
+  #15 = Utf8               args
+  #16 = Utf8               Ljava/lang/String;
+  #17 = Utf8               a
+  #18 = Utf8               I
+  #19 = Utf8               b
+  #20 = Utf8               c
+  #21 = Utf8               MethodParameters
+  #22 = Utf8               SourceFile
+  #23 = Utf8               Test1.java
+  #24 = NameAndType        #6:#7          // "<init>":()V
+  #25 = Class              #31            // java/lang/System
+  #26 = NameAndType        #32:#33        // out:Ljava/io/PrintStream;
+  #27 = Class              #34            // java/io/PrintStream
+  #28 = NameAndType        #35:#36        // println:(I)V
+  #29 = Utf8               com/sss/monitortuning/cp8/Test1
+  #30 = Utf8               java/lang/Object
+  #31 = Utf8               java/lang/System
+  #32 = Utf8               out
+  #33 = Utf8               Ljava/io/PrintStream;
+  #34 = Utf8               java/io/PrintStream
+  #35 = Utf8               println
+  #36 = Utf8               (I)V
+{
+  public com.sss.monitortuning.cp8.Test1();
+    descriptor: ()V
+    flags: ACC_PUBLIC
+    Code:
+      stack=1, locals=1, args_size=1
+         0: aload_0
+         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
+         4: return
+      LineNumberTable:
+        line 7: 0
+      LocalVariableTable:
+        Start  Length  Slot  Name   Signature
+            0       5     0  this   Lcom/sss/monitortuning/cp8/Test1;
+
+  public static void main(java.lang.String);
+    descriptor: (Ljava/lang/String;)V
+    flags: ACC_PUBLIC, ACC_STATIC
+    Code:
+      stack=2, locals=4, args_size=1
+         0: iconst_2
+         1: istore_1
+         2: iconst_3
+         3: istore_2
+         4: iload_1
+         5: iload_2
+         6: iadd
+         7: istore_3
+         8: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
+        11: iload_3
+        12: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V
+        15: return
+      LineNumberTable:
+        line 9: 0
+        line 10: 2
+        line 11: 4
+        line 12: 8
+        line 13: 15
+      LocalVariableTable:
+        Start  Length  Slot  Name   Signature
+            0      16     0  args   Ljava/lang/String;
+            2      14     1     a   I
+            4      12     2     b   I
+            8       8     3     c   I
+    MethodParameters:
+      Name                           Flags
+      args
+}
+SourceFile: "Test1.java"
+
+ /***
+     public static void main(java.lang.String);
+     descriptor: (Ljava/lang/String;)V
+     flags: ACC_PUBLIC, ACC_STATIC
+     Code:
+     # 操作数栈的深度2
+     # 本地变量表最大长度（slot为单位），64位的是2，其他是1，索引从0开始，如果是非static方法索引0代表this，后面是入参，后面是本地变量
+     # 1个参数，实例方法多一个this参数
+     stack=2, locals=4, args_size=1
+     0: iconst_2  #常量2压栈
+     1: istore_1  #出栈保存到本地变量1里面
+     2: iconst_3  #常量3压栈
+     3: istore_2  #出栈保存到本地变量2里面
+     4: iload_1    #局部变量1压栈
+     5: iload_2    #局部变量2压栈
+     6: iadd        # 栈顶两个元素相加，计算结果压栈
+     7: istore_3  # 出栈保存到局部变量3里面
+     8: getstatic     #16                 // Field java/lang/System.out:Ljava/io/PrintStream;
+     11: iload_3
+     12: invokevirtual #22                 // Method java/io/PrintStream.println:(I)V
+     15: return
+     LineNumberTable:
+     // 代码行数 ： 常量池
+     line 5: 0
+     line 6: 2
+     line 7: 4
+     line 8: 8
+     line 9: 15
+     LocalVariableTable:
+     Start  Length  Slot  Name   Signature
+     0      16     0  args   Ljava/lang/String;
+     2      14     1     a   I
+     4      12     2     b   I
+     8       8     3     c   I
+     **/
+```
+# 基于栈的架构
+![](https://upload-images.jianshu.io/upload_images/4685968-b642515f808bfef0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+把常量2压栈,存到本地变量1中
+![](https://upload-images.jianshu.io/upload_images/4685968-2ad691ed43d31bc7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+把常量3压栈,存到本地变量2中
+![](https://upload-images.jianshu.io/upload_images/4685968-7be399e19ea7592c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+将本地变量1数据压栈
+将本地变量2数据压栈
+![](https://upload-images.jianshu.io/upload_images/4685968-d1b964019cf5a0a9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+栈顶两元素相加,存到本地变量3
+![](https://upload-images.jianshu.io/upload_images/4685968-4298c2d9b2e6293c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-72c447370ff99ef7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-962f378779b48b9c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 3 i++  与 ++i
+![](https://upload-images.jianshu.io/upload_images/4685968-c744b124347c1aef.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+对于 for 循环,无任何区别!
+# 4 字符串拼接 + 
diff --git "a/Java/JVM/JVM\346\214\207\344\273\244.md" "b/Java/JVM/JVM\346\214\207\344\273\244.md"
new file mode 100644
index 0000000000..cb6170c8a3
--- /dev/null
+++ "b/Java/JVM/JVM\346\214\207\344\273\244.md"
@@ -0,0 +1,217 @@
+```java
+指令码 助记符    说明
+0×00 nop      什么都不做
+0×01 aconst_null 将null推送至栈顶
+0×02 iconst_m1   将int型-1推送至栈顶
+0×03 iconst_0   将int型0推送至栈顶
+0×04 iconst_1   将int型1推送至栈顶
+0×05 iconst_2   将int型2推送至栈顶
+0×06 iconst_3   将int型3推送至栈顶
+0×07 iconst_4   将int型4推送至栈顶
+0×08 iconst_5   将int型5推送至栈顶
+0×09 lconst_0   将long型0推送至栈顶
+0x0a lconst_1   将long型1推送至栈顶
+0x0b fconst_0   将float型0推送至栈顶
+0x0c fconst_1   将float型1推送至栈顶
+0x0d fconst_2   将float型2推送至栈顶
+0x0e dconst_0   将double型0推送至栈顶
+0x0f dconst_1   将double型1推送至栈顶
+0×10 bipush    将单字节的常量值(-128~127)推送至栈顶
+0×11 sipush    将一个短整型常量值(-32768~32767)推送至栈顶
+0×12 ldc      将int, float或String型常量值从常量池中推送至栈顶
+0×13 ldc_w     将int, float或String型常量值从常量池中推送至栈顶（宽索引）
+0×14 ldc2_w    将long或double型常量值从常量池中推送至栈顶（宽索引）
+0×15 iload     将指定的int型本地变量推送至栈顶
+0×16 lload     将指定的long型本地变量推送至栈顶
+0×17 fload     将指定的float型本地变量推送至栈顶
+0×18 dload     将指定的double型本地变量推送至栈顶
+0×19 aload     将指定的引用类型本地变量推送至栈顶
+0x1a iload_0    将第一个int型本地变量推送至栈顶
+0x1b iload_1    将第二个int型本地变量推送至栈顶
+0x1c iload_2    将第三个int型本地变量推送至栈顶
+0x1d iload_3    将第四个int型本地变量推送至栈顶
+0x1e lload_0    将第一个long型本地变量推送至栈顶
+0x1f lload_1    将第二个long型本地变量推送至栈顶
+0×20 lload_2    将第三个long型本地变量推送至栈顶
+0×21 lload_3    将第四个long型本地变量推送至栈顶
+0×22 fload_0    将第一个float型本地变量推送至栈顶
+0×23 fload_1    将第二个float型本地变量推送至栈顶
+0×24 fload_2    将第三个float型本地变量推送至栈顶
+0×25 fload_3    将第四个float型本地变量推送至栈顶
+0×26 dload_0    将第一个double型本地变量推送至栈顶
+0×27 dload_1    将第二个double型本地变量推送至栈顶
+0×28 dload_2    将第三个double型本地变量推送至栈顶
+0×29 dload_3    将第四个double型本地变量推送至栈顶
+0x2a aload_0    将第一个引用类型本地变量推送至栈顶
+0x2b aload_1    将第二个引用类型本地变量推送至栈顶
+0x2c aload_2    将第三个引用类型本地变量推送至栈顶
+0x2d aload_3    将第四个引用类型本地变量推送至栈顶
+0x2e iaload    将int型数组指定索引的值推送至栈顶
+0x2f laload    将long型数组指定索引的值推送至栈顶
+0×30 faload    将float型数组指定索引的值推送至栈顶
+0×31 daload    将double型数组指定索引的值推送至栈顶
+0×32 aaload    将引用型数组指定索引的值推送至栈顶
+0×33 baload    将boolean或byte型数组指定索引的值推送至栈顶
+0×34 caload    将char型数组指定索引的值推送至栈顶
+0×35 saload    将short型数组指定索引的值推送至栈顶
+0×36 istore    将栈顶int型数值存入指定本地变量
+0×37 lstore    将栈顶long型数值存入指定本地变量
+0×38 fstore    将栈顶float型数值存入指定本地变量
+0×39 dstore    将栈顶double型数值存入指定本地变量
+0x3a astore    将栈顶引用型数值存入指定本地变量
+0x3b istore_0   将栈顶int型数值存入第一个本地变量
+0x3c istore_1   将栈顶int型数值存入第二个本地变量
+0x3d istore_2   将栈顶int型数值存入第三个本地变量
+0x3e istore_3   将栈顶int型数值存入第四个本地变量
+0x3f lstore_0   将栈顶long型数值存入第一个本地变量
+0×40 lstore_1   将栈顶long型数值存入第二个本地变量
+0×41 lstore_2   将栈顶long型数值存入第三个本地变量
+0×42 lstore_3   将栈顶long型数值存入第四个本地变量
+0×43 fstore_0   将栈顶float型数值存入第一个本地变量
+0×44 fstore_1   将栈顶float型数值存入第二个本地变量
+0×45 fstore_2   将栈顶float型数值存入第三个本地变量
+0×46 fstore_3   将栈顶float型数值存入第四个本地变量
+0×47 dstore_0   将栈顶double型数值存入第一个本地变量
+0×48 dstore_1   将栈顶double型数值存入第二个本地变量
+0×49 dstore_2   将栈顶double型数值存入第三个本地变量
+0x4a dstore_3   将栈顶double型数值存入第四个本地变量
+0x4b astore_0   将栈顶引用型数值存入第一个本地变量
+0x4c astore_1   将栈顶引用型数值存入第二个本地变量
+0x4d astore_2   将栈顶引用型数值存入第三个本地变量
+0x4e astore_3   将栈顶引用型数值存入第四个本地变量
+0x4f iastore    将栈顶int型数值存入指定数组的指定索引位置
+0×50 lastore    将栈顶long型数值存入指定数组的指定索引位置
+0×51 fastore    将栈顶float型数值存入指定数组的指定索引位置
+0×52 dastore    将栈顶double型数值存入指定数组的指定索引位置
+0×53 aastore    将栈顶引用型数值存入指定数组的指定索引位置
+0×54 bastore    将栈顶boolean或byte型数值存入指定数组的指定索引位置
+0×55 castore    将栈顶char型数值存入指定数组的指定索引位置
+0×56 sastore    将栈顶short型数值存入指定数组的指定索引位置
+0×57 pop      将栈顶数值弹出 (数值不能是long或double类型的)
+0×58 pop2     将栈顶的一个（long或double类型的)或两个数值弹出（其它）
+0×59 dup      复制栈顶数值并将复制值压入栈顶
+0x5a dup_x1    复制栈顶数值并将两个复制值压入栈顶
+0x5b dup_x2    复制栈顶数值并将三个（或两个）复制值压入栈顶
+0x5c dup2     复制栈顶一个（long或double类型的)或两个（其它）数值并将复制值压入栈顶
+0x5d dup2_x1    <待补充>
+0x5e dup2_x2    <待补充>
+0x5f swap     将栈最顶端的两个数值互换(数值不能是long或double类型的)
+0×60 iadd     将栈顶两int型数值相加并将结果压入栈顶
+0×61 ladd     将栈顶两long型数值相加并将结果压入栈顶
+0×62 fadd     将栈顶两float型数值相加并将结果压入栈顶
+0×63 dadd     将栈顶两double型数值相加并将结果压入栈顶
+0×64 isub     将栈顶两int型数值相减并将结果压入栈顶
+0×65 lsub     将栈顶两long型数值相减并将结果压入栈顶
+0×66 fsub     将栈顶两float型数值相减并将结果压入栈顶
+0×67 dsub     将栈顶两double型数值相减并将结果压入栈顶
+0×68 imul     将栈顶两int型数值相乘并将结果压入栈顶
+0×69 lmul     将栈顶两long型数值相乘并将结果压入栈顶
+0x6a fmul     将栈顶两float型数值相乘并将结果压入栈顶
+0x6b dmul     将栈顶两double型数值相乘并将结果压入栈顶
+0x6c idiv     将栈顶两int型数值相除并将结果压入栈顶
+0x6d ldiv     将栈顶两long型数值相除并将结果压入栈顶
+0x6e fdiv     将栈顶两float型数值相除并将结果压入栈顶
+0x6f ddiv     将栈顶两double型数值相除并将结果压入栈顶
+0×70 irem     将栈顶两int型数值作取模运算并将结果压入栈顶
+0×71 lrem     将栈顶两long型数值作取模运算并将结果压入栈顶
+0×72 frem     将栈顶两float型数值作取模运算并将结果压入栈顶
+0×73 drem     将栈顶两double型数值作取模运算并将结果压入栈顶
+0×74 ineg     将栈顶int型数值取负并将结果压入栈顶
+0×75 lneg     将栈顶long型数值取负并将结果压入栈顶
+0×76 fneg     将栈顶float型数值取负并将结果压入栈顶
+0×77 dneg     将栈顶double型数值取负并将结果压入栈顶
+0×78 ishl     将int型数值左移位指定位数并将结果压入栈顶
+0×79 lshl     将long型数值左移位指定位数并将结果压入栈顶
+0x7a ishr     将int型数值右（符号）移位指定位数并将结果压入栈顶
+0x7b lshr     将long型数值右（符号）移位指定位数并将结果压入栈顶
+0x7c iushr     将int型数值右（无符号）移位指定位数并将结果压入栈顶
+0x7d lushr     将long型数值右（无符号）移位指定位数并将结果压入栈顶
+0x7e iand     将栈顶两int型数值作“按位与”并将结果压入栈顶
+0x7f land     将栈顶两long型数值作“按位与”并将结果压入栈顶
+0×80 ior      将栈顶两int型数值作“按位或”并将结果压入栈顶
+0×81 lor      将栈顶两long型数值作“按位或”并将结果压入栈顶
+0×82 ixor     将栈顶两int型数值作“按位异或”并将结果压入栈顶
+0×83 lxor     将栈顶两long型数值作“按位异或”并将结果压入栈顶
+0×84 iinc     将指定int型变量增加指定值（i++, i–, i+=2）
+0×85 i2l      将栈顶int型数值强制转换成long型数值并将结果压入栈顶
+0×86 i2f      将栈顶int型数值强制转换成float型数值并将结果压入栈顶
+0×87 i2d      将栈顶int型数值强制转换成double型数值并将结果压入栈顶
+0×88 l2i      将栈顶long型数值强制转换成int型数值并将结果压入栈顶
+0×89 l2f      将栈顶long型数值强制转换成float型数值并将结果压入栈顶
+0x8a l2d      将栈顶long型数值强制转换成double型数值并将结果压入栈顶
+0x8b f2i      将栈顶float型数值强制转换成int型数值并将结果压入栈顶
+0x8c f2l      将栈顶float型数值强制转换成long型数值并将结果压入栈顶
+0x8d f2d      将栈顶float型数值强制转换成double型数值并将结果压入栈顶
+0x8e d2i      将栈顶double型数值强制转换成int型数值并将结果压入栈顶
+0x8f d2l      将栈顶double型数值强制转换成long型数值并将结果压入栈顶
+0×90 d2f      将栈顶double型数值强制转换成float型数值并将结果压入栈顶
+0×91 i2b      将栈顶int型数值强制转换成byte型数值并将结果压入栈顶
+0×92 i2c      将栈顶int型数值强制转换成char型数值并将结果压入栈顶
+0×93 i2s      将栈顶int型数值强制转换成short型数值并将结果压入栈顶
+0×94 lcmp     比较栈顶两long型数值大小，并将结果（1，0，-1）压入栈顶
+0×95 fcmpl     比较栈顶两float型数值大小，并将结果（1，0，-1）压入栈顶；当其中一个数值为NaN时，将-1压入栈顶
+0×96 fcmpg     比较栈顶两float型数值大小，并将结果（1，0，-1）压入栈顶；当其中一个数值为NaN时，将1压入栈顶
+0×97 dcmpl     比较栈顶两double型数值大小，并将结果（1，0，-1）压入栈顶；当其中一个数值为NaN时，将-1压入栈顶
+0×98 dcmpg     比较栈顶两double型数值大小，并将结果（1，0，-1）压入栈顶；当其中一个数值为NaN时，将1压入栈顶
+0×99 ifeq     当栈顶int型数值等于0时跳转
+0x9a ifne     当栈顶int型数值不等于0时跳转
+0x9b iflt     当栈顶int型数值小于0时跳转
+0x9c ifge     当栈顶int型数值大于等于0时跳转
+0x9d ifgt     当栈顶int型数值大于0时跳转
+0x9e ifle     当栈顶int型数值小于等于0时跳转
+0x9f if_icmpeq   比较栈顶两int型数值大小，当结果等于0时跳转
+0xa0 if_icmpne   比较栈顶两int型数值大小，当结果不等于0时跳转
+0xa1 if_icmplt   比较栈顶两int型数值大小，当结果小于0时跳转
+0xa2 if_icmpge   比较栈顶两int型数值大小，当结果大于等于0时跳转
+0xa3 if_icmpgt   比较栈顶两int型数值大小，当结果大于0时跳转
+0xa4 if_icmple   比较栈顶两int型数值大小，当结果小于等于0时跳转
+0xa5 if_acmpeq   比较栈顶两引用型数值，当结果相等时跳转
+0xa6 if_acmpne   比较栈顶两引用型数值，当结果不相等时跳转
+0xa7 goto     无条件跳转
+0xa8 jsr      跳转至指定16位offset位置，并将jsr下一条指令地址压入栈顶
+0xa9 ret      返回至本地变量指定的index的指令位置（一般与jsr, jsr_w联合使用）
+0xaa tableswitch    用于switch条件跳转，case值连续（可变长度指令）
+0xab lookupswitch   用于switch条件跳转，case值不连续（可变长度指令）
+0xac ireturn    从当前方法返回int
+0xad lreturn    从当前方法返回long
+0xae freturn    从当前方法返回float
+0xaf dreturn    从当前方法返回double
+0xb0 areturn    从当前方法返回对象引用
+0xb1 return    从当前方法返回void
+0xb2 getstatic   获取指定类的静态域，并将其值压入栈顶
+0xb3 putstatic   为指定的类的静态域赋值
+0xb4 getfield   获取指定类的实例域，并将其值压入栈顶
+0xb5 putfield   为指定的类的实例域赋值
+0xb6 invokevirtual   调用实例方法
+0xb7 invokespecial   调用超类构造方法，实例初始化方法，私有方法
+0xb8 invokestatic   调用静态方法
+0xb9 invokeinterface 调用接口方法
+0xba –
+0xbb new      创建一个对象，并将其引用值压入栈顶
+0xbc newarray   创建一个指定原始类型（如int, float, char…）的数组，并将其引用值压入栈顶
+0xbd anewarray   创建一个引用型（如类，接口，数组）的数组，并将其引用值压入栈顶
+0xbe arraylength 获得数组的长度值并压入栈顶
+0xbf athrow    将栈顶的异常抛出
+0xc0 checkcast   检验类型转换，检验未通过将抛出ClassCastException
+0xc1 instanceof 检验对象是否是指定的类的实例，如果是将1压入栈顶，否则将0压入栈顶
+0xc2 monitorenter   获得对象的锁，用于同步方法或同步块
+0xc3 monitorexit    释放对象的锁，用于同步方法或同步块
+0xc4 wide     当本地变量的索引超过255时使用该指令扩展索引宽度。
+```
+用法1： wide indexbyte1 indexbyte2
+
+其中是iload, fload, aload, lload, dload, istore, fstore, astore, lstore, dstore, ret 之一；索引的值为无符号 (indexbyte1<<8 | indexbyte2).
+
+用法 2：wide iinc indexbyte1 indexbyte2 constbyte1 constbyte2
+
+其中索引的值为无符号 (indexbyte1<<8 | indexbyte2)；常量值为有符号(constbyte1<<8 | constbyte2)
+
+0xc5 multianewarray 创建指定类型和指定维度的多维数组（执行该指令时，操作栈中必须包含各维度的长度值），并将其引用值压入栈顶
+
+0xc6 ifnull 为null时跳转
+
+0xc7 ifnonnull 不为null时跳转
+
+0xc8 goto_w 无条件跳转（宽索引）
+
+0xc9 jsr_w 跳转至指定32位offset位置，并将jsr_w下一条指令地址压入栈顶
diff --git "a/Java/JVM/JVM\346\272\220\347\240\201\345\210\206\346\236\220\344\271\213synchronized.md" "b/Java/JVM/JVM\346\272\220\347\240\201\345\210\206\346\236\220\344\271\213synchronized.md"
new file mode 100644
index 0000000000..2d911f2fe8
--- /dev/null
+++ "b/Java/JVM/JVM\346\272\220\347\240\201\345\210\206\346\236\220\344\271\213synchronized.md"
@@ -0,0 +1,145 @@
+# 1 字节码实现
+javap命令生成的字节码中包含 ** monitorenter ** 和 ** monitorexit **指令
+
+synchronized关键字基于上述两个指令实现了锁的获取和释放过程，解释器执行monitorenter时会进入到`InterpreterRuntime.cpp`的`InterpreterRuntime::monitorenter`函数
+![](https://upload-images.jianshu.io/upload_images/4685968-cbcd2d465b7f83c8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`JavaThread* thread`指向java中的当前线程
+`BasicObjectLock`类型的elem对象包含一个`BasicLock`类型 _lock 对象和一个指向`Object`对象的指针 _obj
+
+```
+class BasicObjectLock {
+  BasicLock _lock; 
+  // object holds the lock;
+  oop  _obj;   
+}
+
+```
+`BasicLock`类型 _lock 对象主要用来保存 _obj 所指向的Object对象的对象头数据
+
+```
+class BasicLock {
+    volatile markOop _displaced_header;
+}
+
+```
+**UseBiasedLocking**标识虚拟机是否开启偏向锁功能，如果开启则执行fast_enter逻辑，否则执行slow_enter
+
+# 2  偏向锁
+## 2.1 引入偏向锁的目的
+在没有多线程竞争的情况下，尽量减少不必要的轻量级锁执行路径
+轻量级锁的获取及释放依赖多次CAS指令，而偏向锁只依赖一次CAS原子指令置换`ThreadID`，不过一旦出现多个线程竞争时必须撤销偏向锁，所以撤销偏向锁消耗的性能必须小于之前节省下来的CAS原子操作的性能消耗，不然得不偿失
+JDK 1.6中默认开启偏向锁，可以通过`-XX:-UseBiasedLocking`来禁用偏向锁
+
+在HotSpot中，偏向锁的入口位于`synchronizer.cpp`文件的`ObjectSynchronizer::fast_enter`函数：
+![](https://upload-images.jianshu.io/upload_images/4685968-61d59362651ec1bd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 2.2  偏向锁的获取
+由`BiasedLocking::revoke_and_rebias`方法实现,逻辑如下：
+1、通过`markOop mark = obj->mark()`获取对象的markOop数据mark，即对象头的Mark Word
+2、判断mark是否为可偏向状态，即mark的偏向锁标志位为 **1**，锁标志位为 **01**
+3、判断mark中JavaThread的状态：如果为空，则进入步骤（4）；如果指向当前线程，则执行同步代码块；如果指向其它线程，进入步骤（5）；
+4、通过CAS原子指令设置mark中JavaThread为当前线程ID，如果执行CAS成功，则执行同步代码块，否则进入步骤（5）；
+5、如果执行CAS失败，表示当前存在多个线程竞争锁，当达到全局安全点（safepoint），获得偏向锁的线程被挂起，撤销偏向锁，并升级为轻量级，升级完成后被阻塞在安全点的线程继续执行同步代码块；
+## 2.3 偏向锁的撤销
+只有当其它线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，偏向锁的撤销由`BiasedLocking::revoke_at_safepoint`方法实现：
+![](https://upload-images.jianshu.io/upload_images/4685968-b90fe2b92d2e7e06.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+1、偏向锁的撤销动作必须等待全局安全点；
+2、暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态；
+3、撤销偏向锁，恢复到无锁（标志位为 **01**）或轻量级锁（标志位为 **00**）的状态；
+
+偏向锁在Java 1.6之后是默认启用的，但在应用程序启动几秒钟之后才激活，可以使用
+`-XX:BiasedLockingStartupDelay=0`
+参数关闭延迟，如果确定应用程序中所有锁通常情况下处于竞争状态，可以通过
+`XX:-UseBiasedLocking=false`
+参数关闭偏向锁。
+## 2.4 轻量级锁
+### 2.4.1 引入轻量级锁的目的
+在多线程交替执行同步块的情况下，尽量避免重量级锁引起的性能消耗，但是如果多个线程在同一时刻进入临界区，会导致轻量级锁膨胀升级重量级锁，所以轻量级锁的出现并非是要替代重量级锁
+###2.4.2 轻量级锁的获取
+当关闭偏向锁功能，或多个线程竞争偏向锁导致偏向锁升级为轻量级锁，会尝试获取轻量级锁，其入口位于`ObjectSynchronizer::slow_enter`
+![](https://upload-images.jianshu.io/upload_images/4685968-99e5814794fb2c0a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+1、`markOop mark = obj->mark()`方法获取对象的markOop数据mark；
+2、`mark->is_neutral()`方法判断mark是否为无锁状态：mark的偏向锁标志位为 **0**，锁标志位为 **01**；
+3、如果mark处于无锁状态，则进入步骤（4），否则执行步骤（6）；
+4、把mark保存到BasicLock对象的_displaced_header字段；
+5、通过CAS尝试将Mark Word更新为指向BasicLock对象的指针，如果更新成功，表示竞争到锁，则执行同步代码，否则执行步骤（6）；
+6、如果当前mark处于加锁状态，且mark中的ptr指针指向当前线程的栈帧，则执行同步代码，否则说明有多个线程竞争轻量级锁，轻量级锁需要膨胀升级为重量级锁；
+
+**假设线程A和B同时执行到临界区`if (mark->is_neutral())`**：
+1、线程AB都把Mark Word复制到各自的_displaced_header字段，该数据保存在线程的栈帧上，是线程私有的；
+2、`Atomic::cmpxchg_ptr`原子操作保证只有一个线程可以把指向栈帧的指针复制到Mark Word，假设此时线程A执行成功，并返回继续执行同步代码块；
+3、线程B执行失败，退出临界区，通过`ObjectSynchronizer::inflate`方法开始膨胀锁；
+
+##### 轻量级锁的释放
+
+轻量级锁的释放通过`ObjectSynchronizer::fast_exit`完成。
+![](https://upload-images.jianshu.io/upload_images/4685968-566e2aa55e6e07a4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+1、确保处于偏向锁状态时不会执行这段逻辑；
+2、取出在获取轻量级锁时保存在BasicLock对象的mark数据dhw；
+3、通过CAS尝试把dhw替换到当前的Mark Word，如果CAS成功，说明成功的释放了锁，否则执行步骤（4）；
+4、如果CAS失败，说明有其它线程在尝试获取该锁，这时需要将该锁升级为重量级锁，并释放；
+
+### 重量级锁
+
+重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。
+
+##### 锁膨胀过程
+锁的膨胀过程通过`ObjectSynchronizer::inflate`函数实现
+![](https://upload-images.jianshu.io/upload_images/4685968-64df31b5d4ab16b2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+膨胀过程的实现比较复杂，截图中只是一小部分逻辑，完整的方法可以查看`synchronized.cpp`，大概实现过程如下：
+1、整个膨胀过程在自旋下完成；
+2、`mark->has_monitor()`方法判断当前是否为重量级锁，即Mark Word的锁标识位为 **10**，如果当前状态为重量级锁，执行步骤（3），否则执行步骤（4）；
+3、`mark->monitor()`方法获取指向ObjectMonitor的指针，并返回，说明膨胀过程已经完成；
+4、如果当前锁处于膨胀中，说明该锁正在被其它线程执行膨胀操作，则当前线程就进行自旋等待锁膨胀完成，这里需要注意一点，虽然是自旋操作，但不会一直占用cpu资源，每隔一段时间会通过os::NakedYield方法放弃cpu资源，或通过park方法挂起；如果其他线程完成锁的膨胀操作，则退出自旋并返回；
+5、如果当前是轻量级锁状态，即锁标识位为 **00**，膨胀过程如下：
+![](https://upload-images.jianshu.io/upload_images/4685968-4a2d2a07972348c7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+1、通过omAlloc方法，获取一个可用的ObjectMonitor monitor，并重置monitor数据；
+2、通过CAS尝试将Mark Word设置为markOopDesc:INFLATING，标识当前锁正在膨胀中，如果CAS失败，说明同一时刻其它线程已经将Mark Word设置为markOopDesc:INFLATING，当前线程进行自旋等待膨胀完成；
+3、如果CAS成功，设置monitor的各个字段：_header、_owner和_object等，并返回；
+
+##### monitor竞争
+
+当锁膨胀完成并返回对应的monitor时，并不表示该线程竞争到了锁，真正的锁竞争发生在`ObjectMonitor::enter`方法中。
+
+![](https://upload-images.jianshu.io/upload_images/4685968-d79a0bc4a1bfb748.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+1、通过CAS尝试把monitor的_owner字段设置为当前线程；
+2、如果设置之前的_owner指向当前线程，说明当前线程再次进入monitor，即重入锁，执行_recursions ++ ，记录重入的次数；
+3、如果之前的_owner指向的地址在当前线程中，这种描述有点拗口，换一种说法：之前_owner指向的BasicLock在当前线程栈上，说明当前线程是第一次进入该monitor，设置_recursions为1，_owner为当前线程，该线程成功获得锁并返回；
+4、如果获取锁失败，则等待锁的释放；
+
+##### monitor等待
+
+monitor竞争失败的线程，通过自旋执行`ObjectMonitor::EnterI`方法等待锁的释放，EnterI方法的部分逻辑实现如下：
+
+![](https://upload-images.jianshu.io/upload_images/4685968-75f28ce576503368.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+1、当前线程被封装成ObjectWaiter对象node，状态设置成ObjectWaiter::TS_CXQ；
+2、在for循环中，通过CAS把node节点push到_cxq列表中，同一时刻可能有多个线程把自己的node节点push到_cxq列表中；
+3、node节点push到_cxq列表之后，通过自旋尝试获取锁，如果还是没有获取到锁，则通过park将当前线程挂起，等待被唤醒，实现如下：
+
+![](https://upload-images.jianshu.io/upload_images/4685968-e797fdcdc32a2f8e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+4、当该线程被唤醒时，会从挂起的点继续执行，通过`ObjectMonitor::TryLock`尝试获取锁，TryLock方法实现如下：
+
+![](https://upload-images.jianshu.io/upload_images/4685968-17d10b24c3369844.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+其本质就是通过CAS设置monitor的_owner字段为当前线程，如果CAS成功，则表示该线程获取了锁，跳出自旋操作，执行同步代码，否则继续被挂起；
+
+##### monitor释放
+
+当某个持有锁的线程执行完同步代码块时，会进行锁的释放，给其它线程机会执行同步代码，在HotSpot中，通过退出monitor的方式实现锁的释放，并通知被阻塞的线程，具体实现位于`ObjectMonitor::exit`方法中。
+
+![](https://upload-images.jianshu.io/upload_images/4685968-e0e92ecdc7a34fbc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+1、如果是重量级锁的释放，monitor中的_owner指向当前线程，即THREAD == _owner；
+2、根据不同的策略（由QMode指定），从cxq或EntryList中获取头节点，通过`ObjectMonitor::ExitEpilog`方法唤醒该节点封装的线程，唤醒操作最终由unpark完成，实现如下：
+
+![](https://upload-images.jianshu.io/upload_images/4685968-3924af3785f6072b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+3、被唤醒的线程，继续执行monitor的竞争；
diff --git "a/Java/Java-Fork-Join-\346\241\206\346\236\266.md" "b/Java/Java-Fork-Join-\346\241\206\346\236\266.md"
new file mode 100644
index 0000000000..4eaff63355
--- /dev/null
+++ "b/Java/Java-Fork-Join-\346\241\206\346\236\266.md"
@@ -0,0 +1,135 @@
+#Doug Lea 关于Java 7引入的他写的Fork/Join框架的论文
+
+# 0\. 摘要
+这个框架通过（递归的）把问题划分为子任务，然后并行的执行这些子任务，等所有的子任务都结束的时候，再合并最终结果的这种方式来支持并行计算编程。就设计层面来说主要是围绕如何高效的去构建和管理任务队列以及工作线程来展开的。
+# 1\. 简介
+`Fork/Join`并行方式是获取良好的并行计算性能的一种最简单同时也是最有效的设计技术。
+`Fork/Join`并行算法是我们所熟悉的分治算法的并行版本，典型的用法如下：
+![](https://upload-images.jianshu.io/upload_images/4685968-15712a0db6dbdb99.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`fork`将会启动一个新的并行`Fork/Join`子任务
+`join`会一直等待直到所有的子任务都结束。
+`Fork/Join`算法，如同其他分治算法一样，总是会递归的、反复的划分子任务，直到这些子任务可以用足够简单的、短小的顺序方法来执行。
+# 2\. 设计
+`Fork/Join`程序可以在任何支持以下特性的框架之上运行：框架能够让构建的子任务并行执行，并且拥有一种等待子任务运行结束的机制。
+然而，`java.lang.Thread`类（同时也包括`POSIX pthread`，这些也是`Java`线程所基于的基础）对`Fork/Join`程序来说并不是最优的选择：
+*   `Fork/Join`任务对同步和管理有简单的和常规的需求。相对于常规的线程来说，`Fork/Join`任务所展示的计算布局将会带来更加灵活的调度策略。例如，`Fork/Join`任务除了等待子任务外，其他情况下是不需要阻塞的。因此传统的用于跟踪记录阻塞线程的代价在这种情况下实际上是一种浪费。
+*   对于一个合理的基础任务粒度来说，构建和管理一个线程的代价甚至可以比任务执行本身所花费的代价更大。尽管粒度是应该随着应用程序在不同特定平台上运行而做出相应调整的。但是超过线程开销的极端粗粒度会限制并行的发挥。
+
+简而言之，`Java`标准的线程框架对`Fork/Join`程序而言太笨重了。但是既然线程构成了很多其他的并发和并行编程的基础，完全消除这种代价或者为了这种方式而调整线程调度是不可能（或者说不切实际的）。
+
+尽管这种思想已经存在了很长时间了，但是第一个发布的能系统解决这些问题的框架是`Cilk`<sup>[5]</sup>。`Cilk`和其他轻量级的框架是基于操作系统的基本的线程和进程机制来支持特殊用途的`Fork/Join`程序。这种策略同样适用于`Java`，尽管`Java`线程是基于低级别的操作系统的能力来实现的。创造这样一个轻量级的执行框架的主要优势是能够让`Fork/Join`程序以一种更直观的方式编写，进而能够在各种支持`JVM`的系统上运行。
+![](https://upload-images.jianshu.io/upload_images/4685968-b588beda5de35d5c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`FJTask`框架是基于`Cilk`设计的一种演变。框架采用和操作系统把线程映射到`CPU`上相同的方式来把任务映射到线程上。只是他们会使用`Fork/Join`程序的简单性、常规性以及一致性来执行这种映射。尽管这些框架都能适应不能形式的并行程序，他们优化了`Fork/Join`的设计：
+
+*   一组工作者线程池是准备好的。每个工作线程都是标准的（『重量级』）处理存放在队列中任务的线程（这地方指的是`Thread`类的子类`FJTaskRunner`的实例对象）。通常情况下，工作线程应该与系统的处理器数量一致。在`Java`中，虚拟机和操作系统需要相互结合来完成线程到处理器的映射。然后对于计算密集型的运算来说，这种映射对于操作系统来说是一种相对简单的任务。任何合理的映射策略都会导致线程映射到不同的处理器。
+*   所有的`Fork/Join`任务都是轻量级执行类的实例，而不是线程实例。在`Java`中，独立的可执行任务必须要实现`Runnable`接口并重写`run`方法。在`FJTask`框架中，这些任务将作为子类继承`FJTask`而不是`Thread`，它们都实现了`Runnable`接口。（对于上面两种情况来说，一个类也可以选择实现`Runnable`接口，类的实例对象既可以在任务中执行也可以在线程中执行。因为任务执行受到来自`FJTask`方法严厉规则的制约，子类化`FJTask`相对来说更加方便，也能够直接调用它们。）
+*   我们将采用一个特殊的队列和调度原则来管理任务并通过工作线程来执行任务。这些机制是由任务类中提供的相关方式实现的：主要是由`fork`、`join`、`isDone`（一个结束状态的标示符），和一些其他方便的方法，例如调用`coInvoke`来分解合并两个或两个以上的任务。
+*   一个简单的控制和管理类（这里指的是`FJTaskRunnerGroup`）来启动工作线程池，并初始化执行一个由正常的线程调用所触发的`Fork/Join`任务（就类似于`Java`程序中的`main`方法）。
+
+作为一个给程序员演示这个框架如何运行的标准实例，这是一个计算法斐波那契函数的类。
+
+```
+class Fib extends FJTask {
+    static final int threshold = 13;
+    volatile int number; // arg/result
+
+    Fib(int n) {
+        number = n;
+    }
+
+    int getAnswer() {
+        if (!isDone())
+            throw new IllegalStateException();
+        return number;
+    }
+
+    public void run() {
+        int n = number;
+        if (n <= threshold) // granularity ctl
+            number = seqFib(n);
+        else {
+            Fib f1 = new Fib(n - 1);
+            Fib f2 = new Fib(n - 2);
+            coInvoke(f1, f2);
+            number = f1.number + f2.number;
+        }
+    }
+
+    public static void main(String[] args) {
+        try {
+            int groupSize = 2; // for example
+            FJTaskRunnerGroup group = new FJTaskRunnerGroup(groupSize);
+            Fib f = new Fib(35); // for example
+            group.invoke(f);
+            int result = f.getAnswer();
+            System.out.println("Answer: " + result);
+        } catch (InterruptedException ex) {
+        }
+    }
+
+    int seqFib(int n) {
+        if (n <= 1) return n;
+        else return seqFib(n − 1) + seqFib(n − 2);
+    }
+}
+```
+在保持性能的同时这个程序仍然维持着`Java`多线程程序的可移植性。对程序员来说通常有两个参数值的他们关注
+*   对于工作线程的创建数量，通常情况下可以与平台所拥有的处理器数量保持一致（或者更少，用于处理其他相关的任务，或者有些情况下更多，来提升非计算密集型任务的性能）
+*   一个粒度参数代表了创建任务的代价会大于并行化所带来的潜在的性能提升的临界点。这个参数更多的是取决于算法而不是平台。通常在单处理器上运行良好的临界点，在多处理器平台上也会发挥很好的效果。作为一种附带的效益，这种方式能够与`Java`虚拟机的动态编译机制很好的结合，而这种机制在对小块方法的优化方面相对于单块的程序来说要好。这样，加上数据本地化的优势，`Fork/Join`算法的性能即使在单处理器上面的性能都较其他算法要好。
+
+### 2.1 `work−stealing`
+`Fork/Join`框架的核心在于轻量级调度机制。`FJTask`采用了`Cilk`的`work-stealing`所采用的基本调度策略：
+![](https://upload-images.jianshu.io/upload_images/4685968-1bef530ada2d84c3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+*   每一个工作线程维护自己的调度队列中的可运行任务
+*   队列以双端队列的形式被维护，不仅支持后进先出 —— `LIFO`的`push`和`pop`操作，还支持先进先出 —— `FIFO`的`take`操作
+*   对于一个给定的工作线程来说，任务所产生的子任务将会被放入到工作者自己的双端队列中
+*   工作线程使用后进先出 —— `LIFO`（最新的元素优先）的顺序，通过弹出任务来处理队列中的任务
+*   当一个工作线程的本地没有任务去运行的时候，它将使用先进先出 —— `FIFO`的规则尝试随机的从别的工作线程中拿（『窃取』）一个任务去运行
+*   当一个工作线程触及了`join`操作，如果可能的话它将处理其他任务，直到目标任务被告知已经结束（通过`isDone`方法）。所有的任务都会无阻塞的完成。
+*   当一个工作线程无法再从其他线程中获取任务和失败处理的时候，它就会退出（通过`yield`、`sleep`和/或者优先级调整）并经过一段时间之后再度尝试直到所有的工作线程都被告知他们都处于空闲的状态。在这种情况下，他们都会阻塞直到其他的任务再度被上层调用。
+
+使用`LIFO`处理每个工作线程自己的任务，使用`FIFO`获取别的任务，这是一种被广泛使用的进行递归`Fork/Join`设计的一种调优手段。
+
+让窃取任务的线程从队列拥有者相反的方向进行操作会减少线程竞争。同样体现了递归分治算法的`大任务优先策略`。因此，更早期被窃取的任务有可能会提供一个更大的单元任务，从而使得窃取线程能够在将来进行递归分解。
+
+作为上述规则的一个后果，对于一些基础的操作而言，使用相对较小粒度的任务比那些仅仅使用粗粒度划分的任务以及那些没有使用递归分解的任务的运行速度要快。尽管相关的少数任务在大多数的`Fork/Join`框架中会被其他工作线程窃取，但是创建许多组织良好的任务意味着只要有一个工作线程处于可运行的状态，那么这个任务就有可能被执行。
+# 3\. 实现
+主要的类是`FJTaskRunner`，它是`java.lang.Thread`的子类。
+`FJTask`自己仅仅维持一个关于结束状态的布尔值，所有其他的操作都是通过当前的工作线程来代理完成的。
+`JFTaskRunnerGroup`类用于创建工作线程，维护一些共享的状态（例如：所有工作线程的标示符，在窃取操作时需要），同时还要协调启动和关闭。
+
+只着重讨论两类问题以及在实现这个框架的时候所形成的一些解决方案：支持高效的双端列表操作（`push`、`pop`和`take`）， 并且当工作线程在尝试获取新的任务时维持窃取的协议。
+## 3.1 双端队列
+*（校注：双端队列中的元素可以从两端弹出，其限定插入和删除操作在队列的两端进行。）*
+
+为了能够获得高效以及可扩展的执行任务，任务管理需要越快越好。创建、发布、和弹出（或者出现频率很少的获取）任务在顺序编程模式中会引发程序调用开销。更低的开销可以使得程序员能够构建更小粒度的任务，最终也能更好的利用并行所带来的益处。
+
+`Java`虚拟机会负责任务的内存分配。`Java`垃圾回收器使我们不需要再去编写一个特殊的内存分配器去维护任务。相对于其他语言的类似框架，这个原因使我们大大降低了实现`FJTask`的复杂性以及所需要的代码数。
+
+双端队列的基本结构采用了很常规的一个结构 —— 使用一个数组（尽管是可变长的）来表示每个队列，同时附带两个索引：`top`索引就类似于数组中的栈指针，通过`push`和`pop`操作来改变。`base`索引只能通过`take`操作来改变。鉴于`FJTaskRunner`操作都是无缝的绑定到双端队列的细节之中，（例如，`fork`直接调用`push`），所以这个数据结构直接放在类之中，而不是作为一个单独的组件。
+
+但是双端队列的元素会被多线程并发的访问，在缺乏足够同步的情况下，而且单个的`Java`数组元素也不能声明为`volatile`变量（校注：[声明成`volatile`的数组](http://ifeve.com/volatile-array-visiblity/ "volatile是否能保证数组中元素的可见性？")，其元素并不具备`volatile`语意），每个数组元素实际上都是一个固定的引用，这个引用指向了一个维护着单个`volatile`引用的转发对象。一开始做出这个决定主要是考虑到`Java`内存模型的一致性。但是在这个级别它所需要的间接寻址被证明在一些测试过的平台上能够提升性能。可能是因为访问邻近的元素而降低了缓存争用，这样内存里面的间接寻址会更快一点。
+
+实现双端队列的主要挑战来自于同步和他的撤销。尽管在`Java`虚拟机上使用经过优化过的同步工具，对于每个`push`和`pop`操作都需要获取锁还是让这一切成为性能瓶颈。然后根据以下的观察结果我们可以修改`Clik`中的策略，从而为我们提供一种可行的解决方案：
+*   `push`和`pop`操作仅可以被工作线程的拥有者所调用
+*   对`take`的操作很容易会由于窃取任务线程在某一时间对`take`操作加锁而限制。（双端队列在必要的时间也可以禁止`take`操作。）这样，控制冲突将被降低为两个部分同步的层次
+*   `pop`和`take`操作只有在双端队列为空的时候才会发生冲突，否则的话，队列会保证他们在不同的数组元素上面操作。
+
+把`top`和`base`索引定义为`volatile`变量可以保证当队列中元素不止一个时，`pop`和`take`操作可以在不加锁的情况下进行。这是通过一种类似于`Dekker`算法来实现的。当`push`预递减到`top`时：
+`if (–top >= base) ...`
+和`take`预递减到`base`时：
+`if(++base < top) ...`
+在上述每种情况下他们都通过比较两个索引来检查这样是否会导致双端队列变成一个空队列。一个不对称的规则将用于防止潜在的冲突：`pop`会重新检查状态并在获取锁之后继续（对`take`所持有的也一样），直到队列真的为空才退出。而`take`操作会立即退出，特别是当尝试去获得另外一个任务。
+
+使用`volatile`变量索引`push`操作在队列没有满的情况下不需要同步就可以进行。如果队列将要溢出，那么它首先必须要获得队列锁来重新设置队列的长度。其他情况下，只要确保`top`操作排在队列数组槽盛在抑制干涉带之后更新。
+
+在随后的初始化实现中，发现有好几种`JVM`并不符合`Java`内存模型中正确读取写入的`volatile`变量的规则。作为一个工作区，
+`pop`在持有锁的情况下重试的条件已经被调整为：如果有两个或者更少的元素，并且`take`操作加了第二把锁以确保内存屏障效果，那么重试就会被触发。
+只要最多只有一个索引被拥有者线程丢失这就是满足的，并且只会引起轻微的性能损耗。
+## 3.2 抢断和闲置
+
+在抢断式工作框架中，工作线程对于他们所运行的程序对同步的要求一无所知。他们只是构建、发布、弹出、获取、管理状态和执行任务。这种简单的方案使得当所有的线程都拥有很多任务需要去执行的时候，它的效率很高。然而这种方式是有代价的，当没有足够的工作的时候它将依赖于试探法。也就是说，在启动一个主任务，直到它结束，在有些`Fork/Join`算法中都使用了全面停止的同步指针。
+
+主要的问题在于当一个工作线程既无本地任务也不能从别的线程中抢断任务时怎么办。如果程序运行在专业的多核处理器上面，那么可以依赖于硬件的忙等待自旋循环的去尝试抢断一个任务。然而，即使这样，尝试抢断还是会增加竞争，甚至会导致那些不是闲置的工作线程降低效率。除此之外，在一个更适合此框架运行的场景中，操作系统应该能够很自信的去运行那些不相关并可运行的进程和线程。
+
+`Java`中并没有十分健壮的工作来保证这个，但是在实际中它往往是可以让人接受的。一个抢断失败的线程在尝试另外的抢断之前会降低自己的优先级，在尝试抢断之间执行`Thread.yeild`操作，然后将自己的状态在`FJTaskRunnerGroup`中设置为不活跃的。他们会一直阻塞直到有新的主线程。其他情况下，在进行一定的自旋次数之后，线程将进入休眠阶段，他们会休眠而不是放弃抢断。强化的休眠机制会给人造成一种需要花费很长时间去划分任务的假象。但是这似乎是最好的也是通用的折中方案。框架的未来版本也许会支持额外的控制方法，以便于让程序员在感觉性能受到影响时可以重写默认的实现。
diff --git "a/Java/Java-Map\347\232\204containsKey(Object-key)\345\222\214containsValue(Object-value)\346\226\271\346\263\225.md" "b/Java/Java-Map\347\232\204containsKey(Object-key)\345\222\214containsValue(Object-value)\346\226\271\346\263\225.md"
new file mode 100644
index 0000000000..e88df0d4cf
--- /dev/null
+++ "b/Java/Java-Map\347\232\204containsKey(Object-key)\345\222\214containsValue(Object-value)\346\226\271\346\263\225.md"
@@ -0,0 +1,116 @@
+```
+public void testContainsKeyOrValue(){
+
+        Scanner sc = new Scanner(System.in);
+        //Key
+        System.out.println("请输入要查询的学生id：");
+        String id = sc.next();
+        System.out.println("你输入的学生id为："+id+",在学生映射表中是否存在"+
+            students.containsKey(id));
+        if(students.containsKey(id)){
+            System.out.println("对应的学生为："+students.get(id).name);
+        }
+
+        //Value
+        System.out.println("请输入要查询的学生姓名：");
+        String name = sc.next();
+        if(students.containsValue(new Student(null,name))){
+            System.out.println("在学生映射表中，确实包含学生："+name);
+        }
+        else{
+            System.out.println("在学生映射表中不存在这个学生");
+        }
+    }
+
+```
+运行结果： 
+
+```
+请输入学生id: 
+1 
+输入学生姓名以创建学生: 
+小明 
+成功添加学生:小明 
+请输入学生id: 
+2 
+输入学生姓名以创建学生: 
+哈哈 
+成功添加学生:哈哈 
+请输入学生id: 
+3 
+输入学生姓名以创建学生: 
+极客咯 
+成功添加学生:极客咯 
+总共有3个学生 
+学生：小明 
+学生：哈哈 
+学生：极客咯 
+请输入要查询的学生id： 
+2 
+你输入的学生id为：2,在学生映射表中是否存在true 
+对应的学生为：哈哈 
+请输入要查询的学生姓名： 
+小明 
+在学生映射表中不存在这个学生
+```
+
+结果分析： 
+可以看到，通过containsKey(Object key)方法比较的结果返回true，是我们想要的结果。通过containsValue(Object value)方法比较的结果返回是false，但是我们确实是有一个名字叫小明的学生啊。为什么呢？
+
+查看containsKey(Object key)和containsValue(Object value)的API说明：
+
+- containsKey(Object key)：Returns true if this map contains a mapping for the specified key. More formally, returns true if and only if this map contains a mapping for a key k such that (key==null ? k==null : key.equals(k)). (There can be at most one such mapping.)
+- containsValue(Object value)：Returns true if this map maps one or more keys to the specified value. More formally, returns true if and only if this map contains at least one mapping to a value v such that (value==null ? v==null : value.equals(v)). This operation will probably require time linear in the map size for most implementations of the Map interface.
+
+可以看到，都调用了equals()方法进行比较！因此可以回答为什么了，我们的Key是String类型的，String类型的equals()比较的是字符串本身的内容，所以我们根据键去查找学生的结果是true。而Value是Student类型的，equals()是直接用==实现的，==比较的是对象的引用地址，当然返回结果是false（参考equals()与==的区别与实际应用）。所以，要在Map中通过学生的名字判断是否包含该学生，需要重写equals()方法。
+在Student.java中重写equals()方法：
+
+```
+@Override
+    public boolean equals(Object obj) {
+        if (this == obj)
+            return true;
+        if (obj == null)
+            return false;
+        if (getClass() != obj.getClass())
+            return false;
+        Student other = (Student) obj;
+        if (name == null) {
+            if (other.name != null)
+                return false;
+        } else if (!name.equals(other.name))
+            return false;
+        return true;
+    }
+```
+再次运行，得到运行结果： 
+请输入学生id: 
+1 
+输入学生姓名以创建学生: 
+小明 
+成功添加学生:小明 
+请输入学生id: 
+2 
+输入学生姓名以创建学生: 
+哈哈 
+成功添加学生:哈哈 
+请输入学生id: 
+3 
+输入学生姓名以创建学生: 
+极客咯 
+成功添加学生:极客咯 
+总共有3个学生 
+学生：小明 
+学生：哈哈 
+学生：极客咯 
+请输入要查询的学生id： 
+2 
+你输入的学生id为：2,在学生映射表中是否存在true 
+对应的学生为：哈哈 
+请输入要查询的学生姓名： 
+小明 
+
+在学生映射表中，确实包含学生：小明
+
+结果分析： 
+通过重写equals()实现了Map中通过学生姓名查找学生对象（containsValue()方法）。
diff --git "a/Java/Java-\346\263\233\345\236\213\350\247\243\346\203\221\344\271\213---extends-T-\345\222\214---super-T-.md" "b/Java/Java-\346\263\233\345\236\213\350\247\243\346\203\221\344\271\213---extends-T-\345\222\214---super-T-.md"
new file mode 100644
index 0000000000..2c62b4f5bd
--- /dev/null
+++ "b/Java/Java-\346\263\233\345\236\213\350\247\243\346\203\221\344\271\213---extends-T-\345\222\214---super-T-.md"
@@ -0,0 +1,148 @@
+# **1 为什么要用通配符和边界？**
+使用泛型的过程中，经常出现一种很别扭的情况
+比如我们有*Fruit*类，和它的派生类*Apple*
+```
+class Fruit {}
+class Apple extends Fruit {}
+```
+然后有一个最简单的容器：*Plate*类
+盘子里可以放一个泛型的“*东西*”
+我们可以对这个东西做最简单的“*放*”和“*取*”的动作：*set( )*和*get( )*方法
+
+```
+class Plate<T>{
+    private T item;
+    public Plate(T t){item=t;}
+    public void set(T t){item=t;}
+    public T get(){return item;}
+}
+
+```
+现定义一个“*水果盘*”，逻辑上水果盘当然可以装苹果
+```
+Plate<Fruit> p = new Plate<Apple>(new Apple());
+```
+但实际上Java编译器不允许这个操作。会报错，“*装苹果的盘子*”无法转换成“*装水果的盘子*”。
+
+```
+error: incompatible types: Plate<Apple> cannot be converted to Plate<Fruit>
+```
+实际上，编译器认定的逻辑是这样的：
+*   苹果 ***IS-A*** 水果
+*   装苹果的盘子 ***NOT-IS-A*** 装水果的盘子
+
+所以，就算容器里装的东西之间有继承关系，但`容器之间是没有继承关系`
+所以我们不可以把*Plate<Apple>*的引用传递给*Plate<Fruit>*
+
+为了让泛型用起来更舒服，Sun的大师们就想出了<? extends T>和<? super T>的办法，来让”*水果盘子*“和”*苹果盘子*“之间发生正当关系
+# **2 上界**
+下面就是上界通配符（Upper Bounds Wildcards）
+```
+Plate<？ extends Fruit>
+```
+**一个能放水果以及一切是水果派生类的盘子**
+再直白点就是：**啥水果都能放的盘子
+**这和我们人类的逻辑就比较接近了
+Plate<？ extends Fruit>和Plate<Apple>最大的区别就是：**Plate<？ extends Fruit>是Plate<Fruit>及Plate<Apple>的基类
+**直接的好处就是，我们可以用“*苹果盘*”给“*水果盘*”赋值了
+```
+Plate<? extends Fruit> p = new Plate<Apple>(new Apple());
+```
+再扩展一下，食物分成水果和肉类，水果有苹果和香蕉，肉类有猪肉和牛肉，苹果还有两种青苹果和红苹果
+```
+//Lev 1
+class Food{}
+
+//Lev 2
+class Fruit extends Food{}
+class Meat extends Food{}
+
+//Lev 3
+class Apple extends Fruit{}
+class Banana extends Fruit{}
+class Pork extends Meat{}
+class Beef extends Meat{}
+
+//Lev 4
+class RedApple extends Apple{}
+class GreenApple extends Apple{}
+
+```
+在这个体系中，上界通配符`Plate<？ extends Fruit>`覆盖下图中蓝色的区域
+![](https://upload-images.jianshu.io/upload_images/4685968-d81db3fcf40a62bf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# **3 下界**
+相对应的下界通配符（Lower Bounds Wildcards）
+
+```
+Plate<？ super Fruit>
+```
+表达的就是相反的概念：**一个能放水果以及一切是水果基类的盘子**
+Plate<？ super Fruit>是Plate<Fruit>的基类，但不是Plate<Apple>的基类
+对应刚才那个例子，Plate<？ super Fruit>覆盖下图中红色的区域。
+![](https://upload-images.jianshu.io/upload_images/4685968-d58e1ca63eb102fc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#  **4 上下界通配符的副作用**
+边界让Java不同泛型之间的转换更容易了。但不要忘记，这样的转换也有一定的副作用。那就是容器的部分功能可能失效。
+
+还是以刚才的Plate为例。我们可以对盘子做两件事，往盘子里set( )新东西，以及从盘子里get( )东西
+```
+class Plate<T>{
+    private T item;
+    public Plate(T t){item=t;}
+    public void set(T t){item=t;}
+    public T get(){return item;}
+}
+
+```
+## **4.1 上界<? extends T>不能往里存，只能往外取**
+**<? extends Fruit>会使往盘子里放东西的set( )方法失效
+但取东西get( )方法还有效**
+
+比如下面例子里两个set()方法，插入Apple和Fruit都报错
+```
+Plate<? extends Fruit> p = new Plate<Apple>(new Apple());
+
+//不能存入任何元素
+p.set(new Fruit());    //Error
+p.set(new Apple());    //Error
+
+//读取出来的东西只能存放在Fruit或它的基类里。
+Fruit newFruit1=p.get();
+Object newFruit2=p.get();
+Apple newFruit3=p.get();    //Error
+
+```
+编译器只知道容器内是`Fruit或者它的派生类`，但`具体是什么类型不知道`
+可能是Fruit？可能是Apple？也可能是Banana，RedApple，GreenApple？编译器在看到后面用Plate<Apple>赋值以后，盘子里没有被标上有“苹果”。而是标上一个占位符：**capture#1**，来表示捕获一个Fruit或Fruit的子类，具体是什么类不知道，代号capture#1
+然后无论是想往里插入Apple或者Meat或者Fruit编译器都不知道能不能和这个capture#1匹配，所以就都不允许
+
+所以通配符<?>和类型参数<T>的区别就在于，对编译器来说**所有的T都代表同一种类型**
+比如下面这个泛型方法里，三个T都指代同一个类型，要么都是String，要么都是Integer...
+
+```
+public <T> List<T> fill(T... t);
+```
+但通配符<?>没有这种约束，Plate<?>单纯的就表示：**盘子里放了一个东西，是什么我不知道**
+## **4.2 下界<? super T>不影响往里存，但往外取只能放在Object对象里**
+**使用下界<? super Fruit>会使从盘子里取东西的get( )方法部分失效，只能存放到Object对象里。set( )方法正常。**
+
+```
+Plate<? super Fruit> p=new Plate<Fruit>(new Fruit());
+
+//存入元素正常
+p.set(new Fruit());
+p.set(new Apple());
+
+//读取出来的东西只能存放在Object类里。
+Apple newFruit3=p.get();    //Error
+Fruit newFruit1=p.get();    //Error
+Object newFruit2=p.get();
+
+```
+
+因为下界规定了元素的最小粒度的下限，实际上是放松了容器元素的类型控制
+既然元素是Fruit的基类，那往里存粒度比Fruit小的都可以
+但往外读取元素就费劲了，只有所有类的基类Object对象才能装下。但这样的话，`元素的类型信息就全部丢失`
+# **5  PECS原则**
+最后看一下什么是**PECS（Producer Extends Consumer Super）原则**,已经很好理解了
+1.  **频繁往外读取内容的，适合用上界Extends**
+2.  **经常往里插入的，适合用下界Super**
diff --git "a/Java/Java-\346\272\220\347\240\201\350\247\243\346\236\220\345\256\236\346\210\230---ThreadLocal-\345\216\237\347\220\206.md" "b/Java/Java-\346\272\220\347\240\201\350\247\243\346\236\220\345\256\236\346\210\230---ThreadLocal-\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..74b4fb31d4
--- /dev/null
+++ "b/Java/Java-\346\272\220\347\240\201\350\247\243\346\236\220\345\256\236\346\210\230---ThreadLocal-\345\216\237\347\220\206.md"
@@ -0,0 +1,426 @@
+说起CS游戏,应该是每个中二少年的年少回忆了.
+游戏开始时,每个人能够领到一把枪,枪把上有三个数字:子弹数、杀敌数、自己的命数，为其设置的初始值分别为1500、0、10.
+
+设战场上的每个人都是一个线程,那么这三个初始值写在哪里呢?
+如果每个线程都写死这三个值,万一将初始子弹数统一改成 1000发呢?
+如果共享,那么线程之间的并发修改会导致数据不准确.
+能不能构造这样一个对象,将这个对象设置为共享变量,统一设置初始值,但是每个线程对这个值的修改都是互相独立的.这个对象就是ThreadLocal
+>注意不能将其翻译为线程本地化或本地线程
+英语恰当的名称应该叫作:CopyValueIntoEveryThread
+
+示例代码
+![](https://upload-images.jianshu.io/upload_images/4685968-061b67d3b7dd0267.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+该示例中,无 set 操作,那么初始值又是如何进入每个线程成为独立拷贝的呢?
+首先,虽然`ThreadLocal`在定义时重写了`initialValue()` ,但并非是在`BULLET_ NUMBER_ THREADLOCAL`对象加载静态变量的时候执行;
+而是每个线程在`ThreadLocal.get()`时都会执行到;
+其源码如下
+![ThreadLocal # get()](https://upload-images.jianshu.io/upload_images/4685968-7dcbc66c969c5307.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+每个线程都有自己的`ThreadLocalMap`;
+如果`map ==null`,则直接执行`setInitialValue()`;
+如果 map 已创建,就表示 Thread 类的`threadLocals` 属性已初始化完毕;
+如果 `e==null`,依然会执行到`setinitialValue()`
+`setinitialValue() `的源码如下:
+![](https://upload-images.jianshu.io/upload_images/4685968-4837187c5986207a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+这是一个保护方法，CsGameByThreadLocal中初始化ThreadLocal对象时已覆写value = initialValue() ;
+![](https://upload-images.jianshu.io/upload_images/4685968-c4427397d0c04dfc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+` getMap `的源码就是提取线程对象t的ThreadLocalMap属性: t. threadLocals.
+
+> 在`CsGameByThreadLocal`第1处，使用了`ThreadLocalRandom` 生成单独的`Random`实例;
+该类在JDK7中引入,它使得每个线程都可以有自己的随机数生成器;
+我们要避免`Random`实例被多线程使用,虽然共享该实例是线程安全的,但会因竞争同一`seed`而导致性能下降.
+
+我们已经知道了`ThreadLocal`是每一个线程单独持有的;
+因为每一个线程都有独立的变量副本,其他线程不能访问,所以不存在线程安全问题,也不会影响程序的执行性能.
+`ThreadLocal`对象通常是由`private static`修饰的,因为都需要复制到本地线程,所以非`static`作用不大;
+不过,`ThreadLocal`无法解决共享对象的更新问题,下面的实例将证明这点.
+因为`CsGameByThreadLocal`中使用的是`Integer `不可变对象,所以可使用相同的编码方式来操作一下可变对象看看
+![](https://upload-images.jianshu.io/upload_images/4685968-00e4a560000fdbd3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+输出的结果是乱序不可控的,所以使用某个引用来操作共享对象时,依然需要进行线程同步
+![ThreadLocal和Thread的类图](https://upload-images.jianshu.io/upload_images/4685968-171e96321cfdb7f2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+`ThreadLocal` 有个静态内部类`ThreadLocalMap`，它还有一个静态内部类`Entry`;
+在Thread中的`ThreadLocalMap`属性的赋值是在`ThreadLocal`类中的`createMap`.
+
+`ThreadLocal `与`ThreadLocalMap`有三组对应的方法: get()、set()和remove();
+在`ThreadLocal`中对它们只做校验和判断，最终的实现会落在`ThreadLocalMap.`.
+`Entry`继承自`WeakReference`,只有一个value成员变量,它的key是ThreadLocal对象
+
+再从栈与堆的内存角度看看两者的关系
+![ThreadLocal的弱引用路线图](https://upload-images.jianshu.io/upload_images/4685968-8c7c8f9022d5155d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+一个Thread有且仅有一个`ThreadLocalMap`对象
+一个`Entry`对象的 key 弱引用指向一个`ThreadLocal`对象
+一个`ThreadLocalMap `对象存储多个Entry 对象
+一个`ThreadLocal` 对象可被多个线程共享
+`ThreadLocal`对象不持有Value,Value 由线程的Entry 对象持有.
+
+Entry 对象源码如下
+![](https://upload-images.jianshu.io/upload_images/4685968-e599cbc7eed64810.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+所有的`Entry`对象都被`ThreadLocalMap`类实例化对象`threadLocals`持有;
+当线程执行完毕时,线程内的实例属性均会被垃圾回收,弱引用的`ThreadLocal`,即使线程正在执行,只要`ThreadLocal`对象引用被置成`null`,`Entry`的Key就会自动在下一次Y - GC时被垃圾回收;
+而在`ThreadLocal`使用`set()/get()`时,又会自动将那些`key=null`的value 置为`null`,使value能够被GC,避免内存泄漏,现实很骨感, ThreadLocal如源码注释所述:
+![](https://upload-images.jianshu.io/upload_images/4685968-7d5574c9b7be6593.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`ThreadLocal`对象通常作为私有静态变量使用,那么其生命周期至少不会随着线程结束而结束.
+
+### 三个重要方法:
+- set()
+如果没有set操作的`ThreadLocal`, 很容易引起脏数据问题
+- get()
+始终没有get操作的`ThreadLocal`对象是没有意义的
+- remove()
+如果没有remove操作,则容易引起内存泄漏
+
+如果`ThreadLocal`是非静态的,属于某个线程实例,那就失去了线程间共享的本质属性;
+那么`ThreadLocal`到底有什么作用呢?
+我们知道,局部变量在方法内各个代码块间进行传递,而类变量在类内方法间进行传递;
+复杂的线程方法可能需要调用很多方法来实现某个功能,这时候用什么来传递线程内变量呢?
+即`ThreadLocal`,它通常用于同一个线程内,跨类、跨方法传递数据;
+如果没有ThreadLocal,那么相互之间的信息传递,势必要靠返回值和参数,这样无形之中,有些类甚至有些框架会互相耦合;
+通过将Thread构造方法的最后一个参数设置为true,可以把当前线程的变量继续往下传递给它创建的子线程
+```
+public Thread (ThreadGroup group, Runnable target, String name,long stackSize, boolean inheritThreadLocals) [
+   this (group, target, name,  stackSize, null, inheritThreadLocals) ;
+}
+```
+parent为其父线程
+```
+if (inheritThreadLocals && parent. inheritableThreadLocals != null)
+      this. inheritableThreadLocals = ThreadLocal. createInheritedMap (parent. inheritableThreadLocals) ;
+```
+`createlnheritedMap()`其实就是调用`ThreadLocalMap`的私有构造方法来产生一个实例对象,把父线程中不为`null`的线程变量都拷贝过来
+```
+private ThreadLocalMap (ThreadLocalMap parentMap) {
+    // table就是存储
+    Entry[] parentTable = parentMap. table;
+    int len = parentTable. length;
+    setThreshold(len) ;
+    table = new Entry[len];
+
+    for (Entry e : parentTable) {
+      if (e != null) {
+        ThreadLocal<object> key = (ThreadLocal<object>) e.get() ;
+        if (key != null) {
+          object value = key. childValue(e.value) ;
+          Entry c = new Entry(key, value) ;
+          int h = key. threadLocalHashCode & (len - 1) ;
+          while (table[h] != null)
+            h = nextIndex(h, len) ;
+          table[h] = C;
+          size++;
+        }
+    }
+}
+```
+很多场景下可通过`ThreadLocal`来透传全局上下文的;
+比如用`ThreadLocal`来存储监控系统的某个标记位,暂且命名为traceld.
+某次请求下所有的traceld都是一致的,以获得可以统一解析的日志文件;
+但在实际开发过程中,发现子线程里的traceld为null,跟主线程的traceld并不一致,所以这就需要刚才说到的`InheritableThreadLocal`来解决父子线程之间共享线程变量的问题,使整个连接过程中的traceld一致.
+示例代码如下
+```
+import org.apache.commons.lang3.StringUtils;
+
+/**
+ * @author sss
+ * @date 2019/1/17
+ */
+public class RequestProcessTrace {
+
+    private static final InheritableThreadLocal<FullLinkContext> FULL_LINK_CONTEXT_INHERITABLE_THREAD_LOCAL
+            = new InheritableThreadLocal<FullLinkContext>();
+
+    public static FullLinkContext getContext() {
+        FullLinkContext fullLinkContext = FULL_LINK_CONTEXT_INHERITABLE_THREAD_LOCAL.get();
+        if (fullLinkContext == null) {
+            FULL_LINK_CONTEXT_INHERITABLE_THREAD_LOCAL.set(new FullLinkContext());
+            fullLinkContext = FULL_LINK_CONTEXT_INHERITABLE_THREAD_LOCAL.get();
+        }
+        return fullLinkContext;
+    }
+
+    private static class FullLinkContext {
+        private String traceId;
+
+        public String getTraceId() {
+            if (StringUtils.isEmpty(traceId)) {
+                FrameWork.startTrace(null, "JavaEdge");
+                traceId = FrameWork.getTraceId();
+            }
+            return traceId;
+        }
+
+        public void setTraceId(String traceId) {
+            this.traceId = traceId;
+        }
+    }
+
+}
+```
+使用`ThreadLocal`和`InheritableThreadLocal`透传上下文时,需要注意线程间切换、异常传输时的处理,避免在传输过程中因处理不当而导致的上下文丢失.
+
+最后,`SimpleDateFormat` 是非线程安全的类,定义为static,会有数据同步风险.
+通过源码可以看出,`SimpleDateFormat` 内部有一个`Calendar`对象;
+在日期转字符串或字符串转日期的过程中,多线程共享时很可能产生错误;
+推荐使用` ThreadLocal`,让每个线程单独拥有这个对象.
+![](https://upload-images.jianshu.io/upload_images/4685968-ef1c68f4853af05d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+# ThreadLocal的副作用
+为了使线程安全地共享某个变量，JDK给出了`ThreadLocal`.
+但`ThreadLocal`的主要问题是会产生脏数据和内存泄漏;
+这两个问题通常是在线程池的线程中使用ThreadLocal引发的，因为线程池有线程复用和内存常驻两是在线程池的线程中使用ThreadLocal 引发的，因为线程池有线程复用和内存常驻两个特点
+
+## 1 脏数据
+线程复用会产生脏数据;
+由于线程池会重用 `Thread` 对象,与 `Thread` 绑定的静态属性 `ThreadLoca` l变量也会被重用.
+如果在实现的线程run()方法中不显式调用`remove()`清理与线程相关的`ThreadLocal`信息,那么若下一个线程不调用`set()`,就可能`get()` 到重用的线程信息;
+包括`ThreadLocal`所关联的线程对象的**value**值.
+
+脏读问题其实十分常见.
+比如,用户A下单后没有看到订单记录,而用户B却看到了用户A的订单记录.
+通过排查发现是由于 session 优化引发.
+在原来的请求过程中,用户每次请求Server,都需要通过 sessionId 去缓存里查询用户的session信息,这样无疑增加了一次调用.
+因此,工程师决定采用某框架来缓存每个用户对应的`SecurityContext`, 它封装了session 相关信息.
+优化后虽然会为每个用户新建一个 session 相关的上下文,但由于`Threadlocal`没有在线程处理结束时及时`remove()`;
+在高并发场景下,线程池中的线程可能会读取到上一个线程缓存的用户信息.
+- 示例代码
+![](https://upload-images.jianshu.io/upload_images/4685968-3a7b2585dd559c29.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![输出结果](https://upload-images.jianshu.io/upload_images/4685968-29e24506fb7bbcaa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ ##  2 内存泄漏
+在源码注释中提示使用static关键字来修饰`ThreadLocal`.
+在此场景下,寄希望于`ThreadLocal`对象失去引用后,触发弱引用机制来回收`Entry`的`Value`就不现实了.
+在上例中,如果不进行`remove()`,那么当该线程执行完成后,通过`ThreadLocal`对象持有的String对象是不会被释放的.
+
+- **以上两个问题的解决办法很简单
+每次用完ThreadLocal时,及时调用`remove()`清理**
+=========================== 增添内容 ==============================
+
+
+
+#  线程封闭
+**避免并发异常最简单的方法就是线程封闭**
+即 把对象封装到一个线程里,只有该线程能看到此对象;
+那么该对象就算非线程安全,也不会出现任何并发安全问题.
+
+使用`ThreadLocal`是实现线程封闭的最佳实践.
+`ThreadLocal`内部维护了一个Map,Map的key是每个线程的名称,Map的值就是我们要封闭的对象.
+每个线程中的对象都对应着Map中一个值,也就是`ThreadLocal`利用Map实现了对象的线程封闭.
+
+# What is ThreadLocal
+该类提供了线程局部 (thread-local) 变量;
+这些变量不同于它们的普通对应物,因为访问某变量（通过其 get /set 方法）的每个线程都有自己的局部变量,它独立于变量的初始化副本.
+
+`ThreadLocal` 实例通常是类中的 `private static `字段,希望将状态与某一个线程（e.g. 用户 ID 或事务 ID）相关联.
+
+一个以`ThreadLocal`对象为键、任意对象为值的存储结构;
+有点像`HashMap`,可以保存"key : value"键值对,但一个`ThreadLocal`只能保存一个键值对,各个线程的数据互不干扰.
+该结构被附带在线程上,也就是说一个线程可以根据一个`ThreadLocal`对象查询到绑定在这个线程上的一个值.
+```
+ThreadLocal<String> localName = new ThreadLocal();
+localName.set("JavaEdge");
+String name = localName.get();
+```
+在线程A中初始化了一个ThreadLocal对象localName，并set了一个值JavaEdge;
+同时在线程A中通过get可拿到之前设置的值;
+但是如果在线程B中,拿到的将是一个null.
+
+因为`ThreadLocal`保证了各个线程的数据互不干扰
+看看set(T value)和get()方法的源码
+![返回当前线程该线程局部变量副本中的值](https://upload-images.jianshu.io/upload_images/4685968-0a1ec5f852dec48a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![设置此线程局部变量的当前线程的副本到指定的值,大多数的子类都不需要重写此方法](https://upload-images.jianshu.io/upload_images/4685968-49519e5895333564.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-747ceba517cccf11.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![Thread#threadLocals](https://upload-images.jianshu.io/upload_images/4685968-c2229753efdc5ad9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+可见,每个线程中都有一个`ThreadLocalMap`
+- 执行set时,其值是保存在当前线程的`threadLocals`变量
+- 执行get时,从当前线程的`threadLocals`变量获取
+
+所以在线程A中set的值,是线程B永远得不到的
+即使在线程B中重新set,也不会影响A中的值;
+保证了线程之间不会相互干扰.
+
+# 追寻本质 - 结构
+从名字上看猜它类似HashMap,但在`ThreadLocal`中,并无实现Map接口
+
+- 在`ThreadLoalMap`中,也是初始化一个大小为16的Entry数组
+![](https://upload-images.jianshu.io/upload_images/4685968-0acf6011ee449403.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- Entry节点对象用来保存每一个key-value键值对
+![](https://upload-images.jianshu.io/upload_images/4685968-9b21b877b6283ec8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+这里的**key 恒为 ThreadLocal**;
+通过`ThreadLocal`的`set()`,把`ThreadLocal`对象自身当做key,放进`ThreadLoalMap`
+![](http://upload-images.jianshu.io/upload_images/4685968-23eeb08ea0826c82.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`ThreadLoalMap`的`Entry`继承`WeakReference`
+和HashMap很不同,`Entry`中没有`next`字段,所以不存在链表情形.
+
+# hash冲突
+无链表,那发生hash冲突时何解？
+
+先看看`ThreadLoalMap`插入一个 key/value 的实现
+![](https://upload-images.jianshu.io/upload_images/4685968-3f745e3f2d5c22d2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 每个`ThreadLocal`对象都有一个hash值 - `threadLocalHashCode`
+![](https://upload-images.jianshu.io/upload_images/4685968-973391eefcdad035.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 每初始化一个`ThreadLocal`对象,hash值就增加一个固定大小
+![](https://upload-images.jianshu.io/upload_images/4685968-53f33e581c3f7520.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+在插入过程中,根据`ThreadLocal`对象的hash值,定位至table中的位置i.
+过程如下
+- 若当前位置为空,就初始化一个Entry对象置于i;
+- 位置i已有对象
+    - 若该`Entry`对象的key正是将设置的key,覆盖其value(和HashMap 处理相同);
+    - 若和即将设置的key 无关,则寻找下一个空位
+
+如此,在`get`时,也会根据`ThreadLocal`对象的hash值,定位到table中的位置.然后判断该位置Entry对象中的key是否和get的key一致,如果不一致,就判断下一个位置.
+
+可见,set和get如果冲突严重的话,效率很低,因为`ThreadLoalMap`是Thread的一个属性，所以即使在自己的代码中控制了设置的元素个数，但还是不能控制其它代码的行为
+
+# 内存泄露
+ThreadLocal可能导致内存泄漏，为什么？
+先看看Entry的实现： 
+```
+static class Entry extends WeakReference<ThreadLocal<?>> {
+    /** The value associated with this ThreadLocal. */
+    Object value;
+
+    Entry(ThreadLocal<?> k, Object v) {
+        super(k);
+        value = v;
+    }
+}
+```
+
+通过之前的分析已经知道，当使用ThreadLocal保存一个value时，会在ThreadLocalMap中的数组插入一个Entry对象，按理说key-value都应该以强引用保存在Entry对象中，但在ThreadLocalMap的实现中，key被保存到了WeakReference对象中
+
+这就导致了一个问题，ThreadLocal在没有外部强引用时，发生GC时会被回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。
+
+##  避免内存泄露
+既然发现有内存泄露的隐患，自然有应对策略，在调用ThreadLocal的get()、set()可能会清除ThreadLocalMap中key为null的Entry对象，这样对应的value就没有GC Roots可达了，下次GC的时候就可以被回收，当然如果调用remove方法，肯定会删除对应的Entry对象。
+
+如果使用ThreadLocal的set方法之后，没有显示的调用remove方法，就有可能发生内存泄露，所以养成良好的编程习惯十分重要，使用完ThreadLocal之后，记得调用remove方法。
+```
+    ThreadLocal<String> localName = new ThreadLocal();
+    try {
+        localName.set("JavaEdge");
+        // 其它业务逻辑
+    } finally {
+        localName.remove();
+    }
+```
+
+# 题外小话
+首先，ThreadLocal 不是用来解决共享对象的多线程访问问题的.
+一般情况下，通过set() 到线程中的对象是该线程自己使用的对象,其他线程是不需要访问的,也访问不到的;
+各个线程中访问的是不同的对象.
+
+**另外，说ThreadLocal使得各线程能够保持各自独立的一个对象;
+并不是通过set()实现的,而是通过每个线程中的new 对象的操作来创建的对象,每个线程创建一个，不是什么对象的拷贝或副本。**
+通过set()将这个新创建的对象的引用保存到各线程的自己的一个map中,每个线程都有这样一个map;
+执行get()时,各线程从自己的map中取出放进去的对象,因此取出来的是各自线程中的对象.
+ThreadLocal实例是作为map的key来使用的.
+
+如果set()进去的东西本来就是多个线程共享的同一个对象;
+那么多个线程的get()取得的还是这个共享对象本身，还是有并发访问问题。
+
+# Hibernate中典型的 ThreadLocal 应用
+```
+private static final ThreadLocal threadSession = new ThreadLocal();  
+  
+public static Session getSession() throws InfrastructureException {  
+    Session s = (Session) threadSession.get();  
+    try {  
+        if (s == null) {  
+            s = getSessionFactory().openSession();  
+            threadSession.set(s);  
+        }  
+    } catch (HibernateException ex) {  
+        throw new InfrastructureException(ex);  
+    }  
+    return s;  
+}  
+```
+首先判断当前线程中有没有放入 session,如果还没有,那么通过`sessionFactory().openSession()`来创建一个session;
+再将session `set()`到线程中,实际是放到当前线程的`ThreadLocalMap`;
+这时,对于该 session 的唯一引用就是当前线程中的那个ThreadLocalMap;
+threadSession 作为这个值的key，要取得这个 session 可以通过threadSession.get();
+里面执行的操作实际是先取得当前线程中的ThreadLocalMap;
+然后将threadSession作为key将对应的值取出.
+这个 session 相当于线程的私有变量,而不是public的.
+
+显然，其他线程中是取不到这个session的，他们也只能取到自己的ThreadLocalMap中的东西。要是session是多个线程共享使用的，那还不乱套了.
+
+## 如果不用ThreadLocal怎么实现呢？
+可能就要在action中创建session，然后把session一个个传到service和dao中，这可够麻烦的;
+或者可以自己定义一个静态的map，将当前thread作为key，创建的session作为值，put到map中，应该也行，这也是一般人的想法.
+但事实上，ThreadLocal的实现刚好相反，它是在每个线程中有一个map，而将ThreadLocal实例作为key，这样每个map中的项数很少，而且当线程销毁时相应的东西也一起销毁了
+
+总之，`ThreadLocal`不是用来解决对象共享访问问题的;
+而主要是提供了保持对象的方法和避免参数传递的方便的对象访问方式
+
+- 每个线程中都有一个自己的`ThreadLocalMap`类对象;
+可以将线程自己的对象保持到其中,各管各的,线程可以正确的访问到自己的对象.
+- 将一个共用的`ThreadLocal`静态实例作为key,将不同对象的引用保存到不同线程的ThreadLocalMap中,然后在线程执行的各处通过这个静态ThreadLocal实例的get()方法取得自己线程保存的那个对象,避免了将这个对象作为参数传递的麻烦.
+
+当然如果要把本来线程共享的对象通过set()放到线程中也可以，可以实现避免参数传递的访问方式;
+但是要注意get()到的是那同一个共享对象，并发访问问题要靠其他手段来解决;
+但一般来说线程共享的对象通过设置为某类的静态变量就可以实现方便的访问了，似乎没必要放到线程中 
+
+# **ThreadLocal的应用场合**
+我觉得最适合的是按线程多实例（每个线程对应一个实例）的对象的访问，并且这个对象很多地方都要用到。
+
+可以看到ThreadLocal类中的变量只有这3个int型：
+
+```
+private final int threadLocalHashCode = nextHashCode();  
+private static AtomicInteger nextHashCode =
+        new AtomicInteger();
+private static final int HASH_INCREMENT = 0x61c88647; 
+```
+而作为ThreadLocal实例的变量只有 **threadLocalHashCode** 
+**nextHashCode** 和**HASH_INCREMENT** 是ThreadLocal类的静态变量
+实际上
+- HASH_INCREMENT是一个常量，表示了连续分配的两个ThreadLocal实例的threadLocalHashCode值的增量
+- nextHashCode 表示了即将分配的下一个ThreadLocal实例的threadLocalHashCode 的值
+
+看一下创建一个ThreadLocal实例即new ThreadLocal()时做了哪些操作，构造方法`ThreadLocal()`里什么操作都没有，唯一的操作是这句
+```
+private final int threadLocalHashCode = nextHashCode();  
+```
+那么nextHashCode()做了什么呢
+```
+private static int nextHashCode() {
+        return nextHashCode.getAndAdd(HASH_INCREMENT);
+    }
+```
+就是将ThreadLocal类的下一个hashCode值即nextHashCode的值赋给实例的threadLocalHashCode，然后nextHashCode的值增加HASH_INCREMENT这个值。.
+
+因此ThreadLocal实例的变量只有这个threadLocalHashCode，而且是final的，用来区分不同的ThreadLocal实例;
+ThreadLocal类主要是作为工具类来使用，那么set()进去的对象是放在哪儿的呢？
+
+看一下上面的set()方法，两句合并一下成为 
+```
+ThreadLocalMap map = Thread.currentThread().threadLocals;  
+```
+这个ThreadLocalMap 类是ThreadLocal中定义的内部类，但是它的实例却用在Thread类中： 
+
+```
+public class Thread implements Runnable {  
+    ......  
+  
+    /* ThreadLocal values pertaining to this thread. This map is maintained 
+     * by the ThreadLocal class. */  
+    ThreadLocal.ThreadLocalMap threadLocals = null;    
+    ......  
+} 
+```
+再看这句：
+
+```
+if (map != null)  
+    map.set(this, value);  
+```
+也就是将该ThreadLocal实例作为key，要保持的对象作为值，设置到当前线程的ThreadLocalMap 中，get()方法同样看了代码也就明白了.
+
+# 参考
+《码出高效：Java开发手册》
diff --git "a/Java/Java-\347\232\204\346\263\250\350\247\243.md" "b/Java/Java-\347\232\204\346\263\250\350\247\243.md"
new file mode 100644
index 0000000000..8b13789179
--- /dev/null
+++ "b/Java/Java-\347\232\204\346\263\250\350\247\243.md"
@@ -0,0 +1 @@
+
diff --git "a/Java/Java-\347\261\273\345\212\240\350\275\275\345\231\250.md" "b/Java/Java-\347\261\273\345\212\240\350\275\275\345\231\250.md"
new file mode 100644
index 0000000000..ee094320a7
--- /dev/null
+++ "b/Java/Java-\347\261\273\345\212\240\350\275\275\345\231\250.md"
@@ -0,0 +1,205 @@
+把类加载阶段的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作交给虚拟机之外的类加载器来完成
+这样的好处在于，我们可以自行实现类加载器来加载其他格式的类，只要是二进制字节流就行，这就大大增强了加载器灵活性
+
+通常系统自带的类加载器分为三种：
+> **启动类加载器**(Bootstrap ClassLoader):由C/C++实现,负责加载`<JAVA_HOME>\jre\lib`目录下或者是-Xbootclasspath所指定路径下目录以及系统属性sun.boot.class.path制定的目录中特定名称的jar包到虚拟机内存中。在JVM启动时,通过Bootstrap ClassLoader加载rt.jar,并初始化sun.misc.Launcher从而创建Extension ClassLoader和Application ClassLoader的实例. 
+> **需要注意的是**,Bootstrap ClassLoader智慧加载特定名称的类库,比如rt.jar.这意味我们自定义的jar扔到`<JAVA_HOME>\jre\lib`也不会被加载. 
+> 我们可以通过以下代码,查看Bootstrap ClassLoader到底初始化了那些类库:
+> 
+> ```
+>  URL[] urLs = Launcher.getBootstrapClassPath().getURLs();
+>         for (URL urL : urLs) {
+>             System.out.println(urL.toExternalForm());
+>         }
+> ```
+> 
+> **扩展类加载器**（Extension Classloader）：只有一个实例,由sun.misc.Launcher$ExtClassLoader实现,负责加载`<JAVA_HOME>\lib\ext`目录下或是被系统属性java.ext.dirs所指定路径目录下的所有类库。
+> 
+> **应用程序类加载器**(Application ClassLoader):只有一个实例,由sun.misc.Launcher$AppClassLoader实现,负责加载系统环境变量ClassPath或者系统属性java.class.path制定目录下的所有类库，如果应用程序中没有定义自己的加载器，则该加载器也就是默认的类加载器.该加载器可以通过java.lang.ClassLoader.getSystemClassLoader获取.
+
+以上三种是我们经常认识最多,除此之外还包括**线程上下文类加载器**(Thread Context ClassLoader)和**自定义类加载器**.
+
+下来解释一下线程上下文加载器: 
+每个线程都有一个类加载器(jdk 1.2后引入),称之为Thread Context ClassLoader,如果线程创建时没有设置,则默认从父线程中继承一个,如果在应用全局内都没有设置,则所有Thread Context ClassLoader为Application ClassLoader.可通过Thread.currentThread().setContextClassLoader(ClassLoader)来设置,通过Thread.currentThread().getContextClassLoader()来获取. 
+我们来想想线程上下文加载器有什么用的?该类加载器容许父类加载器通过子类加载器加载所需要的类库,也就是打破了我们下文所说的双亲委派模型. 
+这有什么好处呢?利用线程上下文加载器,我们能够实现所有的代码热替换,热部署,Android中的热更新原理也是借鉴如此的.
+
+至于自定义加载器就更简单了,JVM运行我们通过自定义的ClassLoader加载相关的类库.
+
+## 3.1 类加载器的双亲委派模型
+
+当一个类加载器收到一个类加载的请求，它首先会将该请求委派给父类加载器去加载，每一个层次的类加载器都是如此，因此所有的类加载请求最终都应该被传入到顶层的启动类加载器(Bootstrap ClassLoader)中，只有当父类加载器反馈无法完成这个列的加载请求时（它的搜索范围内不存在这个类），子类加载器才尝试加载。其层次结构示意图如下： 
+![双亲委派模型示意图](http://upload-images.jianshu.io/upload_images/4685968-73c4e96204d512c2?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+不难发现,该种加载流程的好处在于：
+
+1.  可以避免重复加载，父类已经加载了，子类就不需要再次加载
+2.  更加安全，很好的解决了各个类加载器的基础类的统一问题，如果不使用该种方式，那么用户可以随意定义类加载器来加载核心api，会带来相关隐患。
+
+接下来,我们看看双亲委派模型是如何实现的：
+
+```
+ protected Class<?> loadClass(String name, boolean resolve)
+        throws ClassNotFoundException
+    {
+        synchronized (getClassLoadingLock(name)) {
+            // 首先先检查该类已经被加载过了
+            Class c = findLoadedClass(name);
+            if (c == null) {//该类没有加载过，交给父类加载
+                long t0 = System.nanoTime();
+                try {
+                    if (parent != null) {//交给父类加载
+                        c = parent.loadClass(name, false);
+                    } else {//父类不存在，则交给启动类加载器加载
+                        c = findBootstrapClassOrNull(name);
+                    }
+                } catch (ClassNotFoundException e) {
+                   //父类加载器抛出异常，无法完成类加载请求
+                }
+
+                if (c == null) {//
+                    long t1 = System.nanoTime();
+                    //父类加载器无法完成类加载请求时，调用自身的findClass方法来完成类加载
+                    c = findClass(name);
+                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
+                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
+                    sun.misc.PerfCounter.getFindClasses().increment();
+                }
+            }
+            if (resolve) {
+                resolveClass(c);
+            }
+            return c;
+        }
+    }
+
+```
+
+这里有些童鞋会问,JVM怎么知道一个某个类加载器的父加载器呢?如果你有此疑问,请重新再看一遍.
+
+## 3.2 类加载器的特点
+
+1.  运行任何一个程序时，总是由Application Loader开始加载指定的类。
+2.  一个类在收到加载类请求时，总是先交给其父类尝试加载。
+3.  Bootstrap Loader是最顶级的类加载器，其父加载器为null。
+
+## 3.3 类加载的三种方式
+
+1.  通过命令行启动应用时由JVM初始化加载含有main()方法的主类。
+2.  通过Class.forName()方法动态加载，会默认执行初始化块（static{}），但是Class.forName(name,initialize,loader)中的initialze可指定是否要执行初始化块。
+3.  通过ClassLoader.loadClass()方法动态加载，不会执行初始化块。
+
+## 3.4 自定义类加载器的两种方式
+
+1、遵守双亲委派模型：继承ClassLoader，重写findClass()方法。 
+2、破坏双亲委派模型：继承ClassLoader,重写loadClass()方法。 
+通常我们推荐采用第一种方法自定义类加载器，最大程度上的遵守双亲委派模型。 
+自定义类加载的目的是想要手动控制类的加载,那除了通过自定义的类加载器来手动加载类这种方式,还有其他的方式么?
+
+> 利用现成的类加载器进行加载:
+> 
+> ```
+> 1. 利用当前类加载器
+> Class.forName();
+> 
+> 2. 通过系统类加载器
+> Classloader.getSystemClassLoader().loadClass();
+> 
+> 3. 通过上下文类加载器
+> Thread.currentThread().getContextClassLoader().loadClass();
+> ```
+> 
+> l 
+> 利用URLClassLoader进行加载:
+> 
+> ```
+> URLClassLoader loader=new URLClassLoader();
+> loader.loadClass();
+> ```
+
+* * *
+
+**类加载实例演示：** 
+命令行下执行HelloWorld.java
+
+```
+public class HelloWorld{
+    public static void main(String[] args){
+        System.out.println("Hello world");
+    }
+}
+```
+
+该段代码大体经过了一下步骤:
+
+1.  寻找jre目录，寻找jvm.dll，并初始化JVM.
+2.  产生一个Bootstrap ClassLoader；
+3.  Bootstrap ClassLoader加载器会加载他指定路径下的java核心api，并且生成Extended ClassLoader加载器的实例，然后Extended ClassLoader会加载指定路径下的扩展java api，并将其父设置为Bootstrap ClassLoader。
+4.  Bootstrap ClassLoader生成Application ClassLoader，并将其父Loader设置为Extended ClassLoader。
+5.  最后由AppClass ClassLoader加载classpath目录下定义的类——HelloWorld类。
+
+我们上面谈到 Extended ClassLoader和Application ClassLoader是通过Launcher来创建,现在我们再看看源代码:
+
+```
+ public Launcher() {
+        Launcher.ExtClassLoader var1;
+        try {
+            //实例化ExtClassLoader
+            var1 = Launcher.ExtClassLoader.getExtClassLoader();
+        } catch (IOException var10) {
+            throw new InternalError("Could not create extension class loader", var10);
+        }
+
+        try {
+            //实例化AppClassLoader
+            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
+        } catch (IOException var9) {
+            throw new InternalError("Could not create application class loader", var9);
+        }
+        //主线程设置默认的Context ClassLoader为AppClassLoader.
+        //因此在主线程中创建的子线程的Context ClassLoader 也是AppClassLoader
+        Thread.currentThread().setContextClassLoader(this.loader);
+        String var2 = System.getProperty("java.security.manager");
+        if(var2 != null) {
+            SecurityManager var3 = null;
+            if(!"".equals(var2) && !"default".equals(var2)) {
+                try {
+                    var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();
+                } catch (IllegalAccessException var5) {
+                    ;
+                } catch (InstantiationException var6) {
+                    ;
+                } catch (ClassNotFoundException var7) {
+                    ;
+                } catch (ClassCastException var8) {
+                    ;
+                }
+            } else {
+                var3 = new SecurityManager();
+            }
+
+            if(var3 == null) {
+                throw new InternalError("Could not create SecurityManager: " + var2);
+            }
+
+            System.setSecurityManager(var3);
+        }
+
+    }
+```
+
+## 3.5 非常重要
+
+双亲委派模型好处：eg，object 类。它存放在 rt.jar 中，无论哪个类加载器要加载这个类，最终都是委派给处于模型顶端的启动类加载器加载，因此 object 类在程序的各种加载环境中都是同一个类。 
+
+在这里呢我们需要注意几个问题: 
+1\. 我们知道ClassLoader通过一个类的全限定名来获取二进制流,那么如果我们需要通过自定义类加载其来加载一个Jar包的时候,难道要自己遍历jar中的类,然后依次通过ClassLoader进行加载吗?或者说我们怎么来加载一个jar包呢? 
+2\. 如果一个类引用的其他的类,那么这个其他的类由谁来加载? 
+3\. 既然类可以由不同的加载器加载,那么如何确定两个类如何是同一个类?
+
+我们来依次解答这两个问题: 
+对于动态加载jar而言,JVM默认会使用第一次加载该jar中指定类的类加载器作为默认的ClassLoader.假设我们现在存在名为sbbic的jar包,该包中存在ClassA和ClassB这两个类(ClassA中没有引用ClassB).现在我们通过自定义的ClassLoaderA来加载在ClassA这个类,那么此时此时ClassLoaderA就成为sbbic.jar中其他类的默认类加载器.也就是,ClassB也默认会通过ClassLoaderA去加载.
+
+那么如果ClassA中引用了ClassB呢?当类加载器在加载ClassA的时候,发现引用了ClassB,此时类加载如果检测到ClassB还没有被加载,则先回去加载.当ClassB加载完成后,继续回来加载ClassA.换句话说,类会通过自身对应的来加载其加载其他引用的类.
+
+JVM规定,对于任何一个类,都需要由加载它的类加载器和这个类本身一同确立在java虚拟机中的唯一性,通俗点就是说,在jvm中判断两个类是否是同一个类取决于类加载和类本身,也就是同一个类加载器加载的同一份Class文件生成的Class对象才是相同的,类加载器不同,那么这两个类一定不相同.
diff --git "a/Java/Java8-\345\216\237\345\255\220\345\274\271\347\261\273\344\271\213LongAdder\346\272\220\347\240\201\345\210\206\346\236\220.md" "b/Java/Java8-\345\216\237\345\255\220\345\274\271\347\261\273\344\271\213LongAdder\346\272\220\347\240\201\345\210\206\346\236\220.md"
new file mode 100644
index 0000000000..67f49329e5
--- /dev/null
+++ "b/Java/Java8-\345\216\237\345\255\220\345\274\271\347\261\273\344\271\213LongAdder\346\272\220\347\240\201\345\210\206\346\236\220.md"
@@ -0,0 +1,133 @@
+简单来说，这个类用于在多线程情况下的求和。
+![官方文档的说明](https://upload-images.jianshu.io/upload_images/4685968-06c72cfbe4dc4230.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+从关键方法
+#add
+![](https://upload-images.jianshu.io/upload_images/4685968-bad92d53219ce616.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+包含了一个Cell数组，`Striped64`的一个内部类
+![](https://upload-images.jianshu.io/upload_images/4685968-d2d7d1ed29af4dc0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`Padded variant of AtomicLong supporting only raw accesses plus CAS`
+即`AtomicLong`的填充变体且只支持原始访问和CAS
+有一个value变量，并且提供了一个cas方法更新value值
+
+接下来看第一个if语句，这句首先判断cells是否还没被初始化，并且尝试对value值进行cas操作。如果cells已经初始化并且cas操作失败，则运行if内部的语句。在进入第一个if语句之后紧接着是另外一个if，这个if有4个判断：cell[]数组是否初始化；cell[]数组虽然初始化了但是数组长度是否为0；该线程所对应的cell是否为null；尝试对该线程对应的cell单元进行cas更新是否失败，如果这些条件有一条为true，则运行最为核心的方法longAccumulate，下面列出这个方法，为了便于理解，直接将对其的分析写为注释。
+![JavaDoc](https://upload-images.jianshu.io/upload_images/4685968-9d6da5cb49142c38.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+/**
+  * 处理涉及初始化，调整大小，创建新Cell，和/或争用的更新案例
+  *
+  * @param x 值
+  * @param fn 更新方法
+  * @param wasUncontended 调用
+  */
+ final void longAccumulate(long x, LongBinaryOperator fn, boolean wasUncontended) {
+     int h;
+     // 获取线程probe的值
+     if ((h = getProbe()) == 0) {
+         // 值为0则初始化
+         ThreadLocalRandom.current(); //强制初始化
+         h = getProbe();
+         wasUncontended = true;
+     }
+     boolean collide = false;                // True if last slot nonempt
+     for (;;) {
+         Cell[] as; Cell a; int n; long v;
+         // 这个if分支处理上述四个条件中的前两个相似，此时cells数组已经初始化了并且长度大于0
+         if ((as = cells) != null && (n = as.length) > 0) {
+             // 线程对应的cell为null
+             if ((a = as[(n - 1) & h]) == null) {
+                 // 如果busy锁未被占有
+                 if (cellsBusy == 0) {       // Try to attach new Cell
+                     // 新建一个cell
+                     Cell r = new Cell(x);   // Optimistically create
+                     // 检测busy是否为0,并且尝试锁busy
+                     if (cellsBusy == 0 && casCellsBusy()) {
+                         boolean created = false;
+                         try {               // Recheck under lock
+                             Cell[] rs; int m, j;
+                             //再次确认线程probe所对应的cell为null，将新建的cell赋值
+                             if ((rs = cells) != null &&
+                                 (m = rs.length) > 0 &&
+                                 rs[j = (m - 1) & h] == null) {
+                                 rs[j] = r;
+                                 created = true;
+                             }
+                         } finally {
+                             // 解锁
+                             cellsBusy = 0;
+                         }
+                         if (created)
+                             break;
+                         //如果失败，再次尝试
+                         continue;           // Slot is now non-empty
+                     }
+                 }
+                 collide = false;
+             }
+             //置为true后交给循环重试
+             else if (!wasUncontended)       // CAS already known to fail
+                 wasUncontended = true;      // Continue after rehash
+             //尝试给线程对应的cell update
+             else if (a.cas(v = a.value, ((fn == null) ? v + x :
+                                          fn.applyAsLong(v, x))))
+                 break;
+             else if (n >= NCPU || cells != as)
+                 collide = false;            // At max size or stale
+             else if (!collide)
+                 collide = true;
+             //在以上条件都无法解决的情况下尝试扩展cell
+             else if (cellsBusy == 0 && casCellsBusy()) {
+                 try {
+                     if (cells == as) {      // Expand table unless stale
+                         Cell[] rs = new Cell[n << 1];
+                         for (int i = 0; i < n; ++i)
+                             rs[i] = as[i];
+                         cells = rs;
+                     }
+                 } finally {
+                     cellsBusy = 0;
+                 }
+                 collide = false;
+                 continue;                   // Retry with expanded table
+             }
+             h = advanceProbe(h);
+         }
+         //此时cells还未进行第一次初始化，进行初始化
+         else if (cellsBusy == 0 && cells == as && casCellsBusy()) {
+             boolean init = false;
+             try {                           // Initialize table
+                 if (cells == as) {
+                     Cell[] rs = new Cell[2];
+                     rs[h & 1] = new Cell(x);
+                     cells = rs;
+                     init = true;
+                 }
+             } finally {
+                 cellsBusy = 0;
+             }
+             if (init)
+                 break;
+         }
+         //busy锁不成功或者忙，则再重试一次casBase对value直接累加
+         else if (casBase(v = base, ((fn == null) ? v + x :
+                                     fn.applyAsLong(v, x))))
+             break;                          // Fall back on using base
+     }
+ }
+  /**
+   * Spinlock (locked via CAS) used when resizing and/or creating Cells.
+   * 通过cas实现的自旋锁，用于扩大或者初始化cells
+   */
+  transient volatile int cellsBusy;
+```
+从以上分析来看，`longAccumulate`就是为了尽量减少多个线程更新同一个value，实在不行则扩大cell
+
+`LongAdder`减少冲突的方法以及在求和场景下比`AtomicLong`更高效。
+因为`LongAdder`在更新数值时并非对一个数进行更新，而是分散到多个cell，这样在多线程的情况下可以有效的嫌少冲突和压力，使得更加高效。
+# 使用场景
+适用于统计求和计数的场景，因为它提供了`add`、`sum`方法
+# [](http://blog.jerkybible.com/2018/01/11/Java%E5%B9%B6%E5%8F%91%E6%BA%90%E7%A0%81%E4%B9%8BLongAdder/#LongAdder%E6%98%AF%E5%90%A6%E8%83%BD%E5%A4%9F%E6%9B%BF%E6%8D%A2AtomicLong "LongAdder是否能够替换AtomicLong")LongAdder是否能够替换AtomicLong
+
+从上面的分析来看是不行的，因为`AtomicLong`提供了很多cas方法，例如`getAndIncrement`、`getAndDecrement`等，使用起来非常的灵活，而`LongAdder`只有`add`和`sum`，使用起来比较受限。
+优点:由于 JVM 会将 64位的double,long 型变量的读操作分为两次32位的读操作,所以低并发保持了 AtomicLong性能,高并发下热点数据被 hash 到多个 Cell,有限分离,通过分散提升了并行度
+但统计时有数据更新,也可能会出现数据误差,但高并发场景有限使用此类,低时还是可以继续 AtomicLong
diff --git "a/Java/Java8\346\265\201\347\274\226Stream-DistinctOps,-SliceOps.md" "b/Java/Java8\346\265\201\347\274\226Stream-DistinctOps,-SliceOps.md"
new file mode 100644
index 0000000000..8b13789179
--- /dev/null
+++ "b/Java/Java8\346\265\201\347\274\226Stream-DistinctOps,-SliceOps.md"
@@ -0,0 +1 @@
+
diff --git "a/Java/Java8\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220-Hashtable\346\272\220\347\240\201\345\211\226\346\236\220.md" "b/Java/Java8\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220-Hashtable\346\272\220\347\240\201\345\211\226\346\236\220.md"
new file mode 100644
index 0000000000..47eb49416a
--- /dev/null
+++ "b/Java/Java8\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220-Hashtable\346\272\220\347\240\201\345\211\226\346\236\220.md"
@@ -0,0 +1,348 @@
+# 1 概述
+本文将介绍Map集合的另一个常用类,Hashtable.Hashtable出来的比HashMap早,HashMap1.2才有,而Hashtable在1.0就已经出现了.HashMap和Hashtable实现原理基本一样,都是通过哈希表实现.而且两者处理冲突的方式也一样,都是通过链表法.下面就详细学习下这个类.
+
+#2 源码解析
+##类总览
+```
+public class Hashtable<K,V>
+    extends Dictionary<K,V>
+    implements Map<K,V>, Cloneable, java.io.Serializable
+```
+Hashtable并没有去继承AbstractMap，而是选择继承了Dictionary类，Dictionary是个被废弃的抽象类，文档已经说得很清楚了：
+
+```
+NOTE: This class is obsolete.  New implementations should  
+ * implement the Map interface, rather than extending this class.  
+```
+这个类的方法如下（全是抽象方法）：
+
+```
+public abstract  
+class Dictionary<K,V> {  
+    
+    public Dictionary() {  
+    }  
+    abstract public int size();  
+    abstract public boolean isEmpty();  
+    abstract public Enumeration<K> keys();  
+    abstract public Enumeration<V> elements();  
+    abstract public V get(Object key);  
+    abstract public V put(K key, V value);  
+    abstract public V remove(Object key);  
+}  
+```
+##成员变量
+
+```
+   //存储键值对的桶数组  
+   private transient Entry<K,V>[] table;
+
+   //键值对总数 
+   private transient int count;  
+  
+   //容量的阈值，超过此容量将会导致扩容。值为容量*负载因子    
+   private int threshold;  
+   
+   //负载因子    
+   private float loadFactor;  
+   
+   //hashtable被改变的次数，用于快速失败机制 
+   private transient int modCount = 0;  
+```
+成员变量跟HashMap基本类似，但是HashMap更加规范，HashMap内部还定义了一些常量，比如默认的负载因子，默认的容量，最大容量等等。
+##构造方法
+
+```
+//可指定初始容量和加载因子  
+public Hashtable(int initialCapacity, float loadFactor) {
+        if (initialCapacity < 0)  
+            throw new IllegalArgumentException("Illegal Capacity: "+  
+                                               initialCapacity);  
+        if (loadFactor <= 0 || Float.isNaN(loadFactor))  
+            throw new IllegalArgumentException("Illegal Load: "+loadFactor);  
+        if (initialCapacity==0) 
+            //初始容量最小值为1  
+            initialCapacity = 1; 
+        this.loadFactor = loadFactor;  
+        //创建桶数组
+        table = new Entry[initialCapacity];  
+        //初始化容量阈值  
+        threshold = (int)Math.min(initialCapacity * loadFactor, MAX_ARRAY_SIZE + 1);
+        useAltHashing = sun.misc.VM.isBooted() &&  
+                (initialCapacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD);  
+    }  
+    
+    public Hashtable(int initialCapacity) { 
+        //默认负载因子为0.75   
+        this(initialCapacity, 0.75f);
+    }  
+    public Hashtable() {  
+        this(11, 0.75f);//默认容量为11，负载因子为0.75  
+    }  
+   
+    public Hashtable(Map<? extends K, ? extends V> t) {  
+        this(Math.max(2*t.size(), 11), 0.75f);  
+        putAll(t);  
+    }  
+```
+
+ 1. Hashtable的默认容量为11，默认负载因子为0.75.(HashMap默认容量为16，默认负载因子也是0.75)
+ 2. Hashtable的容量可以为任意整数，最小值为1，而HashMap的容量始终为2的n次方
+ 3. 为避免扩容带来的性能问题，建议指定合理容量。
+
+另外我们看到，Hashtable的编码相比较HashMap不是很规范，构造器中出现了硬编码，而HashMap中定义了常量。
+
+跟HashMap一样，Hashtable内部也有一个静态类叫Entry，其实是个键值对对象，保存了键和值的引用。也可以理解为一个单链表的结点，因为其持有下一个Entry对象的引用：
+##Entry类
+
+```
+private static class Entry<K,V> implements Map.Entry<K,V> {//键值对对象  
+        int hash;  
+        final K key;  
+        V value;  
+        Entry<K,V> next;  
+        protected Entry(int hash, K key, V value, Entry<K,V> next) {  
+            this.hash = hash;  
+            this.key =  key;  
+            this.value = value;  
+            this.next = next;  
+        }  
+        protected Object clone() {  
+            return new Entry<>(hash, key, value,  
+                                  (next==null ? null : (Entry<K,V>) next.clone()));  
+        }  
+        // Map.Entry Ops  
+        public K getKey() {  
+            return key;  
+        }  
+        public V getValue() {  
+            return value;  
+        }  
+        public V setValue(V value) {  
+            if (value == null)  
+                throw new NullPointerException();  
+            V oldValue = this.value;  
+            this.value = value;  
+            return oldValue;  
+        }  
+        public boolean equals(Object o) {  
+            if (!(o instanceof Map.Entry))  
+                return false;  
+            Map.Entry<?,?> e = (Map.Entry)o;  
+            return key.equals(e.getKey()) && value.equals(e.getValue());  
+        }  
+        public int hashCode() {  
+            return hash ^ value.hashCode();  
+        }  
+        public String toString() {  
+            return key.toString()+"="+value.toString();  
+        }  
+    }  
+```
+再次强调：HashMap和Hashtable存储的是键值对对象，而不是单独的键或值。
+明确了存储方式后，再看put和get方法：
+##put方法
+
+```
+//向哈希表中添加键值对
+public synchronized V put(K key, V value) {  
+        //确保值不为空 
+        if (value == null) {  
+            throw new NullPointerException();  
+        }  
+        // Makes sure the key is not already in the hashtable.  
+        Entry tab[] = table; 
+        //生成键的hash值,若key为null，此方法会抛异常   
+        int hash = hash(key);
+        //通过hash值找到其存储位置  
+        int index = (hash & 0x7FFFFFFF) % tab.length;
+        //遍历链表  
+        for (Entry<K,V> e = tab[index] ; e != null ; e = e.next) {
+            //若键相同，则直接覆盖旧值  
+            if ((e.hash == hash) && e.key.equals(key)) {
+                V old = e.value;  
+                e.value = value;  
+                return old;  
+            }  
+        }  
+        modCount++;  
+        //当前容量超过阈值,需要扩容 
+        if (count >= threshold) { 
+            //重新构建桶数组，并对数组中所有键值对重哈希，耗时！        
+            rehash();  
+            tab = table;  
+            hash = hash(key);  
+            index = (hash & 0x7FFFFFFF) % tab.length;  
+        }   
+        Entry<K,V> e = tab[index];  
+        //将新结点插到链表首部  
+        tab[index] = new Entry<>(hash, key, value, e);//生成一个新结点  
+        count++;  
+        return null;  
+    }
+```
+Hasbtable并不允许值和键为空（null），若为空，会抛空指针.大家可能奇怪，put方法在开始处仅对value进行判断，并未对key判断，可能是设计者的疏忽。当然，这并不影响使用，因为当调用hash方法时，若key为空，依然会抛出空指针异常：
+
+```
+private int hash(Object k) {  
+        if (useAltHashing) {  
+            if (k.getClass() == String.class) {  
+                return sun.misc.Hashing.stringHash32((String) k);  
+            } else {  
+                int h = hashSeed ^ k.hashCode();  
+                h ^= (h >>> 20) ^ (h >>> 12);  
+                return h ^ (h >>> 7) ^ (h >>> 4);  
+             }  
+        } else  {  
+            return k.hashCode();//此处可能抛空指针异常  
+        }  
+    }  
+```
+
+ - HashMap计算索引的方式是h&(length-1),而Hashtable用的是模运算，效率上是低于HashMap的
+ - Hashtable计算索引时将hash值先与上0x7FFFFFFF,这是为了保证hash值始终为正数
+ - 特别需要注意的是这个方法包括下面要讲的若干方法都加了synchronized关键字，也就意味着这个Hashtable是个线程安全的类，这也是它和HashMap最大的不同点
+ 
+#rehash方法
+
+```
+protected void rehash() { 
+        //记录旧容量  
+        int oldCapacity = table.length; 
+        //记录旧的桶数组   
+        Entry<K,V>[] oldMap = table;
+        //可能会溢出 
+        //扩容为原容量的2倍加1
+        int newCapacity = (oldCapacity << 1) + 1;  
+        if (newCapacity - MAX_ARRAY_SIZE > 0) {  
+            if (oldCapacity == MAX_ARRAY_SIZE)
+                return; 
+            //容量不得超过约定的最大值,若超过依旧保持为约定的最大值     
+            newCapacity = MAX_ARRAY_SIZE;  
+        }  
+        //创建新的数组  
+        Entry<K,V>[] newMap = new Entry[newCapacity];
+        //结构改变计数器加一
+        modCount++;  
+        threshold = (int)Math.min(newCapacity * loadFactor, MAX_ARRAY_SIZE + 1);  
+        boolean currentAltHashing = useAltHashing;  
+        useAltHashing = sun.misc.VM.isBooted() &&  
+                (newCapacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD);  
+        boolean rehash = currentAltHashing ^ useAltHashing;  
+        table = newMap;  
+        //转移键值对到新数组 
+        for (int i = oldCapacity ; i-- > 0 ;) { 
+            for (Entry<K,V> old = oldMap[i] ; old != null ; ) {  
+                Entry<K,V> e = old;  
+                old = old.next;  
+                if (rehash) {  
+                    e.hash = hash(e.key);  
+                }  
+                int index = (e.hash & 0x7FFFFFFF) % newCapacity;  
+                e.next = newMap[index];  
+                newMap[index] = e;  
+            }  
+        }  
+    } 
+```
+Hashtable每次扩容,容量都为原来的2倍加1,而HashMap为原来的2倍.
+##get方法
+
+```
+public synchronized V get(Object key) {//根据键取出对应索引  
+      Entry tab[] = table;  
+      int hash = hash(key);//先根据key计算hash值  
+      int index = (hash & 0x7FFFFFFF) % tab.length;//再根据hash值找到索引  
+      for (Entry<K,V> e = tab[index] ; e != null ; e = e.next) {//遍历entry链  
+          if ((e.hash == hash) && e.key.equals(key)) {//若找到该键  
+              return e.value;//返回对应的值  
+          }  
+      }  
+      return null;//否则返回null  
+  } 
+```
+##remove方法
+
+```
+public synchronized V remove(Object key) {//删除指定键值对  
+       Entry tab[] = table;  
+       int hash = hash(key);//计算hash值  
+       int index = (hash & 0x7FFFFFFF) % tab.length;//计算索引  
+       for (Entry<K,V> e = tab[index], prev = null ; e != null ; prev = e, e = e.next) {//遍历entry链  
+           if ((e.hash == hash) && e.key.equals(key)) {//找到指定键  
+               modCount++;  
+               if (prev != null) {//修改相关指针  
+                   prev.next = e.next;  
+               } else {  
+                   tab[index] = e.next;  
+               }  
+               count--;  
+               V oldValue = e.value;  
+               e.value = null;  
+               return oldValue;  
+           }  
+       }  
+       return null;  
+   } 
+```
+##clear方法
+
+```
+//清空桶数组  
+public synchronized void clear() {
+       Entry tab[] = table;  
+       modCount++;  
+       for (int index = tab.length; --index >= 0; )  
+           tab[index] = null;//直接置空  
+       count = 0;  
+   }  
+```
+##获取键集(keySet)和键值集(entrySet)的方法
+
+```
+public Set<K> keySet() {  
+        if (keySet == null)//通过Collections的包装，返回的是线程安全的键集  
+            keySet = Collections.synchronizedSet(new KeySet(), this);  
+        return keySet;  
+    }  
+ public Set<Map.Entry<K,V>> entrySet() {  
+        if (entrySet==null)//通过Collections的包装，返回的是线程安全的键值集  
+            entrySet = Collections.synchronizedSet(new EntrySet(), this);  
+        return entrySet;  
+    }  
+```
+这个KeySet和EntrySet是Hashtable的两个内部类:
+
+```
+private class KeySet extends AbstractSet<K> {  
+       public Iterator<K> iterator() {  
+           return getIterator(KEYS);  
+       }  
+       public int size() {  
+           return count;  
+       }  
+       public boolean contains(Object o) {  
+           return containsKey(o);  
+       }  
+       public boolean remove(Object o) {  
+           return Hashtable.this.remove(o) != null;  
+       }  
+       public void clear() {  
+           Hashtable.this.clear();  
+       }  
+   }  
+```
+#3 总结
+
+ 1. Hashtable是线程安全的类（HashMap非线程安全）
+ 2. HashTable不允许null值(key和value都不可以) ；HashMap允许null值(key和value都可以)
+ 3. HashTable有一个contains(Object value)功能和containsValue(Object
+value)功能一样
+ 3. Hashtable不允许键重复，若键重复，则新插入的值会覆盖旧值（同HashMap）
+ 4. HashTable使用Enumeration进行遍历；HashMap使用Iterator进行遍历
+ 4. Hashtable同样是通过链表法解决冲突
+ 5. 哈希值的使用不同，HashTable直接使用对象的hashCode； HashMap重新计算hash值，而且用与代替求模
+ 5. Hashtable根据hashCode()计算索引时将hash值先与上0x7FFFFFFF,这是为了保证hash值始终为正数
+ 6. Hashtable的容量为任意正数（最小为1），而HashMap的容量始终为2的n次方.Hashtable默认容量为 11，HashMap默认容量为16
+ 7. Hashtable每次扩容,新容量为旧容量的2倍加1，而HashMap为旧容量的2倍
+ 8. Hashtable和HashMap默认负载因子都为0.75
diff --git "a/Java/Java\344\270\216\347\272\277\347\250\213.md" "b/Java/Java\344\270\216\347\272\277\347\250\213.md"
new file mode 100644
index 0000000000..eb873095d4
--- /dev/null
+++ "b/Java/Java\344\270\216\347\272\277\347\250\213.md"
@@ -0,0 +1,61 @@
+并发不一定要依赖多线程（如PHP的多进程并发），但在Java中谈论并发，大多数都与线程脱不开关系
+# 线程的实现
+线程是CPU调度的基本单位。
+
+Thread类与大部分的Java API有显著的差别，它的所有关键方法都是声明为Native的。
+意味着这个方法没有使用或无法使用平台无关的手段来实现。
+# 内核线程(Kernel-Lever Thread,KLT)
+直接由操作系统内核(Kermel,下称内核)支持的线程
+由内核来完成线程切换，内核通过操纵调度器(Sheduler) 对线程进行调度，并负责将线程的任务映射到各个处理器上。
+每个内核线程可以视为内核的一个分身,这样OS就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核(Multi-Threads Kernel )。
+
+程序一般不会直接去使用KLT，而使用KLT的一种高级接口即轻量级进程(Light Weight Process,LWP)，即我们通常意义上所讲的线程，由于每个LWP都由一个KLT支持，因此只有先支持KLT，才能有LWP。这1：1的关系称为`一对一的线程模型`。
+![KLT与LWP之间1：1的关系](https://upload-images.jianshu.io/upload_images/4685968-497d1cfc86f6b084.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 局限性
+由于是基于KLT实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态和内核态中来回切换
+其次，每个LWP都需要有一个KLT的支持，因此LWP要消耗一定的内核资源（如KLT的栈空间），因此一个系统支持LWP的数量是有限的
+#用户线程
+创建，切换和调度各种细节都需要考虑，实现及其困难，已被java、ruby等语言放弃
+# 用户线程混合轻量级进程
+
+# Java线程的实现
+用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并
+且可以支持大规模的用户线程并发
+操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级线程来完成，大大降低了整个进程被完全阻塞的风险。
+在这种混合模式中，用户线程与轻量级进程的数量比是不定的，即为N :M 的关系
+![用户线程与轮量级进程之间N :M 的关系](https://upload-images.jianshu.io/upload_images/4685968-b64e81020899c37e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+许多UN1X 系列的操作系统，如Solaris、HP-UX 等都提供了N: M 的线程模型实现。
+#.Java 线程
+JDK 1.2 之前是基于称为“绿色线程”(Green-Threads )的用户线程实现
+在JDK 1.2 中替换为基于操作系统原生线程模型来实现
+因此，在目前的JDK 版本中，操作系统支持怎样的线程模型，在很大程度上决定了Java 虚拟机的线程是怎样映射的，这点在不同的平台上没有办法达成一致，虚拟机规范中也并未限定Java 线程需要使用哪种线程模型来实现。
+线程模型只对线程的并发规模和操作成本产生影响，对Java 程序的编码和运行过程来说，这些差异都是透明的。
+对于Siun JDK 来说，它的Windows 版与Linux版都是使用一对一的线程模型实现的，一条Java线程就映射到一条轻量级进程之中，因为Windows 和Linux系统提供的线程模型就是一对一的
+而在Solaris 平台中，由于操作系统的线程特性可以同时支持一对一(通过Bound
+Threaids或Alternate Libthread实现)及多对多( 通过LWP/Thread Based Synchronization
+实现) 的线程模型，因此在Solaris 版的JDK 中也对应提供了两个平台专有的虚拟桃参数:
+-XX:+UseLWPSynchronization （默认值) 和-XX:+UseBoyndThreads 来明确指定虚拟
+机使用哪种线程模型。
+# Java线程调度
+- 线程调度
+系统为线程分配处理器使用权的过程，主要调度方式有两种
+  - 协同式线程调度(Cooperative Threads-Scheduling）
+  - 抢占式线程调度(Preemptive Threads-Scheduling )
+
+使用协同式调度的多线程系统，线程执行时间由线程本身控制，线程把自己工作执行完后，要主动通知系统切换到另外一个线程上。
+协同式多线程
+- 最大好处
+实现简单，而且由于线程要把自己的事情干完后才进行线程切换,切换操作对线程白己是可知的，所以没有什么线程同步的问题
+- 坏处也很明显
+ 线程执行时间不可控制
+
+使用抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切换不由线程本身决定，在这种实现线程调度的方式下，线程执行时间系统可控的
+Java使用的线程调度方式就是抢占式调度
+
+虽然Java线程调度是系统自动完成的，但是我们还是可“建议”系统给某些线程多分配一点执行时间，可以通过设置线程优先级来完成。Java 语言一共设置了10个级别的线程优先级(Thread.MIN_PRIORITY 至Thread.MAX_PRIORITY )，在两个线程同时处于Ready 状态时，优先级越高的线程越容易被系统选择执行。
+
+Java 的线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于OS，虽然现在很多OS都提供线程优先级的概念，但是并不见得能与Java线程的优先级对应，如Solaris中有2147483648 (232 )种优先级，但Windows中就只有7种，比Java 线程优先级多的系统还好说，中间留下一点空位就可以了,但比Java线程优先级少的系统，就不得不出现几个优先级相同的情况了
+
+不仅仅是说在一些平台上不同的优先级实际会变得相同这一点，还有其他情况让我们不能太依赖优先级:优先级可能会被系统自行改变。
+例如，在Windows 系统中存在一个称为“优先级推进器”(Priority Boosting，当然它可以被
+关闭掉) 的功能，它的大致作用就是当系统发现一个线程执行得特别“勤奋努力”的话，可能会越过线程优先级去为它分配执行时间。因此，我们不能在程序中通过优先级完全准确地判断一组状态都为Ready 的线程将会先执行哪一个
diff --git "a/Java/Java\344\270\255Collections-sort()\346\226\271\346\263\225\347\232\204\346\274\224\345\217\230.md" "b/Java/Java\344\270\255Collections-sort()\346\226\271\346\263\225\347\232\204\346\274\224\345\217\230.md"
new file mode 100644
index 0000000000..7f82c72a90
--- /dev/null
+++ "b/Java/Java\344\270\255Collections-sort()\346\226\271\346\263\225\347\232\204\346\274\224\345\217\230.md"
@@ -0,0 +1,74 @@
+先看一段代码
+```java
+
+  List<Integer> list = new ArrayList<Integer>();
+  list.add(1);
+  list.add(2);
+  list.add(3);
+
+  Iterator<Integer> it = list.iterator();
+
+  Collections.sort(list);
+
+  while (it.hasNext()) {
+   System.out.println(it.next());
+  }
+```
+Java7 运行效果
+```java
+1
+2
+3
+```
+Java8 运行效果 
+![](http://upload-images.jianshu.io/upload_images/4685968-dd0b824ef1f2c8e4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+#结果分析
+在上面的代码中，我们先得到list的iterator，然后对list进行排序，最后遍历iterator。
+从Java8的错误信息中可以看出it.next( )方法中检查list是否已经被修改，由于在遍历之前进行了一次排序，所以checkForComodification方法抛出异常ConcurrentModificationException。
+这个可以理解，因为排序,肯定会修改list
+但是为啥Java7中没问题呢？
+
+#源码分析
+首先看checkForComodification方法是如何判断的，如下所示：
+```java
+final void checkForComodification() {
+  if (modCount != expectedModCount)
+    throw new ConcurrentModificationException();
+}
+```
+可以看出，有两个内部成员变量用来判断是否发生了修改: modCount 和 expectedModCount。
+
+Iterator中记录了expectedModCount
+List中记录了modCount
+checkForComodification方法通过比较modCount 和 expectedModCount来判断是否发生了修改。
+
+在Java7中，Collections.sort( list )调用的是Collections自身的sort方法，如下所示：
+```java
+public static <T extends Comparable<? super T>> void sort(List<T> list) {
+   Object[] a = list.toArray();
+   Arrays.sort(a);
+   ListIterator<T> i = list.listIterator();
+   for (int j=0; j<a.length; j++) {
+     i.next();
+     i.set((T)a[j]);
+   }
+}
+```
+可以看出，该排序算法只是改变了List中元素的值（i.set((T)a[j]);），并没有修改modCount字段。所以checkForComodification方法不会抛出异常。
+
+而在Java8中，Collections.sort( list )调用的是ArrayList自身的sort方法，如下所示：
+
+public static <T extends Comparable<? super T>> void sort(List<T> list) {
+  list.sort(null);
+}
+ArrayList的sort方法实现如下：
+![](http://upload-images.jianshu.io/upload_images/4685968-cba099d83fb00e29.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+可以看出最后一行，modCount++修改了modCount字段
+所以checkForComodification方法会抛出异常
+
+#关于Java8中Collections.sort方法的修改
+之前，Collection.sort复制list中的元素以排序到数组中，对数组进行排序，然后使用数组中的元素更新列表，并将默认方法List.sort委托给Collection.sort。这不是一个最佳的设计
+从8u20发布起，Collection.sort将被委托给List.sort,这意味着，例如，现有的以ArrayList实例调用Collection.sort的代码将使用由ArrayList实现的最佳排序
+ 
diff --git "a/Java/Java\344\270\255\346\255\243\345\210\231\350\241\250\350\276\276\345\274\217.md" "b/Java/Java\344\270\255\346\255\243\345\210\231\350\241\250\350\276\276\345\274\217.md"
new file mode 100644
index 0000000000..57f0a9bfce
--- /dev/null
+++ "b/Java/Java\344\270\255\346\255\243\345\210\231\350\241\250\350\276\276\345\274\217.md"
@@ -0,0 +1,197 @@
+主要用到的是这两个类
+- java.util.regex.Pattern
+- java.util.regex.Matcher。
+
+Pattern对应正则表达式，一个Pattern与一个String对象关联，生成一个Matcher，它对应Pattern在String中的一次匹配； 
+调用Matcher对象的find()方法，Matcher对象就会更新为下一次匹配的匹配信息。示例：
+```java
+Pattern pattern = Pattern.compile("\\d{4}-\\d{2}-]]d{2}");
+String string = "2010-12-20 2011-02-14";
+Matcher matcher = pattern.matcher(string);
+while(matcher.find()) {
+    System.out.println(matcher.group(0));
+}
+```
+#Pattern
+Pattern是Java语言中的正则表达式对象。
+要使用正则表达式，首先必须从字符串“编译”出Pattern对象，这需要用到`Pattern.compile(String regex)`
+e.g
+`Pattern pattern = Pattern.compile("a.b+");`
+
+如果要指定匹配模式，可以在表达式中使用(?modifier)修饰符指定，也可以使用预定义常量。
+下面的两个Pattern对象的生成方法不同，结果却是等价的。
+```java
+Pattern pattern = Pattern.compile("(?i)a.b+");
+Pattern pattern = Pattern.compile("a.b+",Pattern.CASE_INSENSITIVE);
+```
+如果要同时指定多种模式，可以连写模式修饰符，也可以直接用|运算符将预定义常量连接起来，以下两个Pattern对象也是等价的。
+```java
+Pattern pattern = Pattern.compile("(?is)a.b+");
+Pattern pattern = Pattern.compile("a.b+",Pattern.CASE_INSENSITIVE | Pattern.DOTALL);
+```
+##Pattern的主要方法
+![](https://upload-images.jianshu.io/upload_images/4685968-2d16306314c523f7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+可检验字符串`input`能否由正则表达式`regex`匹配
+因为是静态方法，所以不需要编译生成各个对象，方便随手使用。
+要注意的是，它检验的是“整个字符串能否由表达式匹配”，而不是“表达式能否在字符串中找到匹配”。
+可以认为`regex`的首尾自动加上了匹配字符串起始和结束位置的锚点 \A和\z 。
+```
+Pattern.matches("\\d{6}","a123456");   //false
+Pattern.matches("\\d{6}","123456");     //true
+```
+![](https://upload-images.jianshu.io/upload_images/4685968-1b2adbbaecc536c1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+通常，Pattern对象需要配合下面将要介绍的Matcher一起完成正则操作。如果只用正则表达式来切分字符串，只用Pattern的这个方法也可以。
+
+这个方法接收的参数类型是`CharSequence`它可能有点陌生
+![](https://upload-images.jianshu.io/upload_images/4685968-595ead2c2e84e926.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+它是String的父类m因而可以应对常见的各种表示“字符串”的类。下面的代码仅以String为例：
+```
+String s = "2018-3-26";
+Pattern pattern = Pattern.compile("\\s+");
+for(String part : pattern.split(s)){
+    System.out.println(part);
+}
+```
+这个方法与上面的方法很相似，只是多了一个参数limit，它用来限定返回的String数组的最大长度。
+也就是说，它规定了字符串至多只能“切”limit-1次。如果不需要对字符串比较大，进行尽可能多的切分，使用这个方法。
+```
+String s = " 2010-12-20  ";
+Pattern pattern = Pattern.compile("\\s+");
+for(String part : Pattern.split(s,2)){
+    System.out.println(part);
+}
+```
+既然limit是一个int类型，那么它自然可以设定为各种值，下表总结了limit在各个取值区间对结果的影响（未指定limit时，最终返回包含n个元素的数组，实际能切分的次数是 n-1 ）：
+                                                                                
+- limit < 0
+等于未设定limit时，保留末尾的空字符串
+- limit = 0 
+等于未设定limit时，切分n-1次，忽略末尾的空字符串
+- 0 < limit < n
+返回数组包含limit个元素，切分limit-1次，最后一个元素是第limit-1次切分后，右侧剩下的所有文本
+- limit >= n
+等于未指定limit时
+![](https://upload-images.jianshu.io/upload_images/4685968-fa810753f0963f0a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+用来取消字符串text中所有转义字符的特殊含义，实质就是在字符串首尾添加 \Q 和 \E。
+通常，如果需要把某个字符串作为没有任何特殊意义的正则表达式（比如从外界读入的字符串，用在某个复杂的正则表达式中），就可以使用这个方法：
+```
+"aacb".matches("a*.b");            //true
+"a*.b".matches("a*.b");             //false
+"a*.b".matches("a*.b");             //false
+"a*.b".matches(Pattern.quote("a*.b"));        //true
+```
+#Matcher
+Matcher可以理解为“某次具体匹配的结果对象”
+把编译好的Pattern对象“应用”到某个String对象上，就获得了作为“本次匹配结果”的Matcher对象。
+之后，就可以通过它获得关于匹配的信息。
+```java
+Pattern pattern = Pattern.compile("\\d{4}-\\d{2}-\\d{2}");
+Matcher matcher = pattern.matcher("2010-12-20 2011-02-14");
+while(matcher.find()){
+    System.out.println(matcher.group());
+}
+```
+对编译好的Pattern对象调用matcher(String text)方法，传入要匹配的字符串text，就得到了Matcher对象，每次调用一次find()方法，如果返回true，就表示“找到一个匹配”，此时可以通过下面的若干方法获得关于本次匹配的信息。
+
+1. String group(int n)
+
+返回当前匹配中第n对捕获括号捕获的文本，如果n为0，则取匹配的全部内容；如果n小于0或者大于最大分组编号数，则报错。
+
+2. String group()
+
+返回当前匹配的全部文本，相当于group(0)。
+
+3. int groupCount()
+
+返回此Matcher对应Pattern对象中包含的捕获分组数目，编号为0的默认分组不计在内。
+
+4. int start(n)
+
+返回当前匹配中第n对捕获括号匹配的文本在原字符串中的起始位置。
+
+5. int start()
+
+返回当前匹配的文本在原字符串中的起始位置，相当于start(0)。
+
+6. int end(n)
+
+返回当前匹配中第n对捕获括号匹配的文本在原字符串中的结束位置。
+
+7. int end()
+
+返回当前匹配的文本在原字符串中的结果位置，相当于end(0)。
+
+8. String replaceAll(String replacement)
+
+如果进行正则表达式替换，一般用到的是Matcher的replaceAll()方法，它会将原有文本中正则表达式能匹配的所有文本替换为replaceement字符串。
+
+#String
+许多时候只需要临时使用某个正则表达式，而不需要重复使用，这时候每次都生成Pattern对象和Matcher对象再操作显得很烦琐。所以，Java的String类提供了正则表达式操作的静态成员方法，只需要String对象就可以执行正则表达式操作。
+![](https://upload-images.jianshu.io/upload_images/4685968-0cf5b4ba1db44cc8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+这个方法判断当前的String对象能否由正则表达式`regex`匹配。
+请注意，这里的“匹配”指的并不是`regex`能否在`String`内找到匹配，而是指`regex`匹配整个`String`对象，因此非常适合用来做数据校验。
+```
+"123456".matches("\\d{6}");            //true
+"a123456".matches("\\d{6}");          //true
+2. String replaceFirst(String regex,String replacement)
+```
+用来替换正则表达式regex在字符串中第一次能匹配的文本，可以在replacement字符串中用$num引用regex中对应捕获分组匹配的文本。
+`"2010-12-20 2011-02-14".replaceFirst("(\\d{4})-(\\d{2})-(\\d{2})","$2/$3/$1");`
+![](https://upload-images.jianshu.io/upload_images/4685968-f1582726822b7e82.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+用来进行所有的替换，它的结果等同于Matcher类的`replaceAll()`，replacement字符串中也可以用$num的表示法引用regex中对应捕获分组匹配的文本。
+`"2010-12-20 2011-02-14".replaceAll("(\\d{4})-(\\d{2})-(\\d{2})","$2/$3/$1");`
+![image.png](https://upload-images.jianshu.io/upload_images/4685968-5fd716b8e540d5e2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+等价于Pattern中对应的split()方法
+# [Java String.split()用法小结](http://www.cnblogs.com/mingforyou/p/3299569.html)
+
+在java.lang包中有String.split()方法,返回是一个数组
+
+我在应用中用到一些,给大家总结一下,仅供大家参考:
+
+1、如果用“.”作为分隔的话,必须是如下写法,String.split("\\."),这样才能正确的分隔开,不能用String.split(".");
+
+2、如果用“|”作为分隔的话,必须是如下写法,String.split("\\|"),这样才能正确的分隔开,不能用String.split("|");
+
+“.”和“|”都是转义字符,必须得加"\\";
+
+3、如果在一个字符串中有多个分隔符,可以用“|”作为连字符,比如,“acount=? and uu =? or n=?”,把三个都分隔出来,可以用String.split("and|or");
+
+使用String.split方法分隔字符串时,分隔符如果用到一些特殊字符,可能会得不到我们预期的结果。 
+
+我们看jdk doc中说明  
+
+public String[] split(String regex)
+
+ Splits this string around matches of the given regular expression. 
+
+参数regex是一个 regular-expression的匹配模式而不是一个简单的String,他对一些特殊的字符可能会出现你预想不到的结果,比如测试下面的代码用竖线 | 分隔字符串,你将得不到预期的结果
+```
+String[] aa = "aaa|bbb|ccc".split("|");
+
+    //String[] aa = "aaa|bbb|ccc".split("\\|"); 这样才能得到正确的结果
+
+    for (int i = 0 ; i <aa.length ; i++ ) {
+
+      System.out.println("--"+aa[i]); 
+
+    }
+```
+用竖 * 分隔字符串运行将抛出java.util.regex.PatternSyntaxException异常,用加号 + 也是如此。
+```
+String[] aa = "aaa*bbb*ccc".split("*");
+
+    //String[] aa = "aaa|bbb|ccc".split("\\*"); 这样才能得到正确的结果    
+
+    for (int i = 0 ; i <aa.length ; i++ ) {
+
+      System.out.println("--"+aa[i]); 
+
+    }
+```
+显然, + * 不是有效的模式匹配规则表达式,用"\\*" "\\+"转义后即可得到正确的结果。
+
+"|" 分隔串时虽然能够执行,但是却不是预期的目的,"\\|"转义后即可得到正确的结果。
+
+还有如果想在串中使用"\"字符,则也需要转义.首先要表达"aaaa\bbbb"这个串就应该用"aaaa\\bbbb",如果要分隔就应该这样才能得到正确结果,
+`String[] aa = "aaa\\bbb\\bccc".split("\\\\");`
diff --git "a/Java/Java\344\270\255\347\232\204BlockingQueue.md" "b/Java/Java\344\270\255\347\232\204BlockingQueue.md"
new file mode 100644
index 0000000000..e5dad5a55a
--- /dev/null
+++ "b/Java/Java\344\270\255\347\232\204BlockingQueue.md"
@@ -0,0 +1,795 @@
+#1 Java中的阻塞队列
+![](https://upload-images.jianshu.io/upload_images/4685968-cbf23e2eb43aceed.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##1.1 简介
+一种支持两个附加操作的队列,是一系列阻塞队列类的接口
+当存取条件不满足时,阻塞在操作处
+
+ - 队列满时,阻塞存储元素的线程,直到队列可用
+ - 队列空时,获取元素的线程会等待队列非空
+ 
+阻塞队列常用于生产者/消费者场景,生产者是向队列里存元素的线程,消费者是从队列里取元素的线程.阻塞队列就是生产者存储元素、消费者获取元素的容器
+![BlockingQueue继承体系](http://upload-images.jianshu.io/upload_images/4685968-9e7f1b6c305819cc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![阻塞队列不可用时,两个附加操作提供了4种处理方式](http://upload-images.jianshu.io/upload_images/4685968-a29ee4f281eb03ad?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ - ***抛出异常***
+    -  当队列满时,如果再往队列里插入元素,会抛出IllegalStateException("Queuefull")异常
+   - 当队列空时，从队列里获取元素会抛出NoSuchElementException异常
+ - ***返回特殊值***
+   - 当往队列插入元素时,会返回元素是否插入成功,成功则返回true
+   - 若是移除方法,则是从队列里取出一个元素,若没有则返回null
+ - ***一直阻塞***
+   - 当阻塞队列满时,如果生产者线程往队列里put元素,队列会一直阻塞生产者线程,直到队列有可用空间或响应中断退出
+   - 当队列空时,若消费者线程从队列里take元素,队列会阻塞住消费者线程,直到队列非空 
+ - ***超时退出***
+   - 当阻塞队列满时,若生产者线程往队列里插入元素,队列会阻塞生产者线程
+一段时间,若超过指定的时间,生产者线程就会退出
+
+>若是无界阻塞队列,队列不会出现满的情况,所以使用put或offer方法永远不会被阻塞,使用offer方法时,永远返回true
+> 
+> BlockingQueue 不接受 null 元素,抛 NullPointerException
+null 被用作指示 poll 操作失败的警戒值(无法通过编译)
+> 
+> 
+BlockingQueue 实现主要用于生产者/使用者队列，但它另外还支持 Collection 接口。
+因此，举例来说，使用 remove(x) 从队列中移除任意一个元素是有可能的。
+然而，这种操作通常表现并不高效，只能有计划地偶尔使用，比如在取消排队信息时。
+
+> BlockingQueue 的实现是线程安全的
+所有排队方法都可使用内置锁或其他形式的并发控制来自动达到它们的目的
+然而，大量的Collection 操作（addAll、containsAll、retainAll 和 removeAll）没有必要自动执行，除非在实现中特别说明
+因此，举例来说，在只添加 c 中的一些元素后，addAll(c) 有可能失败（抛出一个异常）
+
+> BlockingQueue 实质上不支持使用任何一种“close”或“shutdown”操作来指示不再添加任何项
+这种功能的需求和使用有依赖于实现的倾向
+例如，一种常用的策略是：对于生产者，插入特殊的 end-of-stream 或 poison 对象，并根据使用者获取这些对象的时间来对它们进行解释 
+
+#2 生产者和消费者例子
+在介绍具体的阻塞类之前，先来看看阻塞队列最常应用的场景，即生产者和消费者例子
+一般而言，有n个生产者，各自生产产品，并放入队列
+同时有m个消费者，各自从队列中取出产品消费
+当队列已满时（队列可以在初始化时设置Capacity容量），生产者会在放入队列时阻塞；当队列空时，消费者会在取出产品时阻塞。代码如下：
+```
+public class BlockingQueueExam {
+    public static void main(String[] args) throws InterruptedException {
+        BlockingQueue<String> blockingQueue = new LinkedBlockingQueue<>(3);
+        ExecutorService service = Executors.newCachedThreadPool();
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Producer("Producer" + i, blockingQueue));
+        }
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Consumer("Consumer" + i, blockingQueue));
+        }
+        service.shutdown();
+    }
+}
+
+class Producer implements Runnable {
+    private final String name;
+    private final BlockingQueue<String> blockingQueue;
+    private static Random rand = new Random(47);
+    private static AtomicInteger productID = new AtomicInteger(0);
+
+    Producer(String name, BlockingQueue<String> blockingQueue) {
+        this.name = name;
+        this.blockingQueue = blockingQueue;
+    }
+
+    @Override
+    public void run() {
+        try {
+            for (int i = 0; i < 10; i++) {
+                SECONDS.sleep(rand.nextInt(5));
+                String str = "Product" + productID.getAndIncrement();
+                blockingQueue.add(str);
+                //注意，这里得到的size()有可能是错误的
+                System.out.println(name + " product " + str + ", queue size = " + blockingQueue.size());
+            }
+            System.out.println(name + " is over");
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+    }
+}
+
+class Consumer implements Runnable {
+    private final String name;
+    private final BlockingQueue<String> blockingQueue;
+    private static Random rand = new Random(47);
+
+    Consumer(String name, BlockingQueue<String> blockingQueue) {
+        this.name = name;
+        this.blockingQueue = blockingQueue;
+    }
+
+    @Override
+    public void run() {
+        try {
+            for (int i = 0; i < 10; i++) {
+                SECONDS.sleep(rand.nextInt(5));
+                String str = blockingQueue.take();
+                //注意，这里得到的size()有可能是错误的
+                System.out.println(name + " consume " + str + ", queue size = " + blockingQueue.size());
+            }
+            System.out.println(name + " is over");
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+    }
+}
+```
+以上代码中的阻塞队列是LinkedBlockingQueue，初始化容量为3
+生产者5个，每个生产者间隔随机时间后生产一个产品put放入队列，每个生产者生产10个产品
+消费者也是5个，每个消费者间隔随机时间后take取出一个产品进行消费，每个消费者消费10个产品
+可以看到，当队列满时，所有生产者被阻塞
+当队列空时，所有消费者被阻塞
+代码中还用到了AtomicInteger原子整数，用来确保产品的编号不会混乱
+
+# 2 **Java里的阻塞队列**
+![BlockingQueue的实现类](http://upload-images.jianshu.io/upload_images/4685968-d05fd46243a9bf6f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+至JDK8,Java提供了7个阻塞队列
+- ArrayBlockingQueue：数组结构组成的有界阻塞队列
+- LinkedBlockingQueue：链表结构组成的有界(默认MAX_VALUE容量)阻塞队列
+- PriorityBlockingQueue：支持优先级调度的无界阻塞队列,排序基于compareTo或Comparator完成
+- DelayQueue：支持延迟获取元素,在OS调用中较多或者应用于某些条件变量达到要求后需要做的事情
+- SynchronousQueue：一个不存储元素的阻塞队列。
+- LinkedTransferQueue：链表结构的TransferQueue,无界阻塞队列
+- LinkedBlockingDeque：链表结构的双向阻塞队列
+## 2.1 LinkedBlockingQueue和ArrayBlockingQueue
+![](https://upload-images.jianshu.io/upload_images/4685968-469fae51c96576fd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a8d5673e8779077b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+基于数组的阻塞队列实现，在`ArrayBlockingQueue`内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。
+
+　　ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。Doug Lea之所以没这样去做，也许是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧，以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。 ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。
+都是FIFO队列
+正如其他Java集合一样，链表形式的队列，其存取效率要比数组形式的队列高
+但是在一些并发程序中，数组形式的队列由于具有一定的可预测性，因此可以在某些场景中获得更好的效率
+ 
+另一个不同点在于，ArrayBlockingQueue支持“公平”策略
+若在构造函数中指定了“公平”策略为true,可以有效避免一些线程被“饿死”,公平性通常会降低吞吐量,但也减少了可变性和避免了“不平衡性" 
+`BlockingQueue queue = new ArrayBlockingQueue<>(3, true); `
+总体而言，LinkedBlockingQueue是阻塞队列的最经典实现，在不需要“公平”策略时，基本上使用它就够了
+> 所谓公平访问队列是指阻塞的线程,可以按照阻塞的先后顺序访问队列,即先阻塞的线程先访问队列
+> 非公平性是对先等待的线程是非公平的,当队列有可用空间时,阻塞的线程都可以争夺访问队列的资格,有可能先阻塞的线程最后才访问队列
+
+为保证公平性,通常会降低吞吐量.我们可以使用以下代码创建一个公平的阻塞队列
+```
+ArrayBlockingQueue fairQueue = new ArrayBlockingQueue(1000,true);
+```
+![访问者的公平性是使用可重入锁实现的](http://upload-images.jianshu.io/upload_images/4685968-1e4244e433e8c991.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##2.2  SynchronousQueue同步队列
+![](https://upload-images.jianshu.io/upload_images/4685968-37f19ec95f4dbe98.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+比较特殊的阻塞队列，它具有以下几个特点： 
+1. 一个插入方法的线程必须等待另一个线程调用取出 
+2. 队列没有容量Capacity（或者说容量为0），事实上队列中并不存储元素，它只是提供两个线程进行信息交换的场所 
+3. 由于以上原因，队列在很多场合表现的像一个空队列。不能对元素进行迭代，不能peek元素，poll会返回null 
+4. 队列中不允许存入null元素 
+5. SynchronousQueue如同ArrayedBlockingQueue一样，支持“公平”策略 
+
+下面是一个例子，5个Producer产生产品，存入队列
+5个Consumer从队列中取出产品，进行消费。
+
+```
+public class SynchronizeQueueExam {
+    public static void main(String[] args) {
+        SynchronousQueue<String> queue = new SynchronousQueue<>(false);
+        ExecutorService service = Executors.newCachedThreadPool();
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Producer(queue, "Producer" + i));
+        }
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Consumer(queue, "Consumer" + i));
+        }
+        service.shutdown();
+    }
+
+    static class Producer implements Runnable {
+        private final SynchronousQueue<String> queue;
+        private final String name;
+        private static Random rand = new Random(47);
+        private static AtomicInteger productID = new AtomicInteger(0);
+
+        Producer(SynchronousQueue<String> queue, String name) {
+            this.queue = queue;
+            this.name = name;
+        }
+
+        @Override
+        public void run() {
+            try {
+                for (int i = 0; i < 5; i++) {
+                    TimeUnit.SECONDS.sleep(rand.nextInt(5));
+                    String str = "Product" + productID.incrementAndGet();
+                    queue.put(str);
+                    System.out.println(name + " put " + str);
+                }
+                System.out.println(name + " is over.");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+        }
+    }
+
+
+    static class Consumer implements Runnable {
+        private final SynchronousQueue<String> queue;
+        private final String name;
+
+        Consumer(SynchronousQueue<String> queue, String name) {
+            this.queue = queue;
+            this.name = name;
+        }
+
+        @Override
+        public void run() {
+            try {
+                for (int i = 0; i < 5; i++) {
+                    String str = queue.take();
+                    System.out.println(name + " take " + str);
+                }
+                System.out.println(name + " is over.");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+        }
+    }
+}
+```
+##2.3  PriorityBlockingQueue优先级阻塞队列 
+![](https://upload-images.jianshu.io/upload_images/4685968-1873eb6013d54379.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+1. 队列中的元素总是按照“自然顺序”排序，或者根据构造函数中给定的Comparator进行排序
+2. 队列中不允许存在null，也不允许存在不能排序的元素 
+3. 对于排序值相同的元素，其序列是不保证的，当然你可以自己扩展这个功能 
+4. 队列容量是没有上限的，但是如果插入的元素超过负载，有可能会引起OOM
+5. 使用迭代子iterator()对队列进行轮询，其顺序不能保证
+6. 具有BlockingQueue的put和take方法，但是由于队列容量没有上线，所以put方法是不会被阻塞的，但是take方法是会被阻塞的
+7. 可以给定初始容量，这个容量会按照一定的算法自动扩充 
+
+下面是一个PriorityBlockingQueue的例子，例子中定义了一个按照字符串倒序排列的队列
+5个生产者不断产生随机字符串放入队列
+5个消费者不断从队列中取出随机字符串
+同一个线程取出的字符串基本上是倒序的（因为不同线程同时存元素，因此取的字符串打印到屏幕上往往不是倒序的了）                  
+```
+public class PriorityBlockingQueueExam {
+    public static void main(String[] args) {
+        //创建一个初始容量为3，排序为字符串排序相反的队列
+        PriorityBlockingQueue<String> queue = new PriorityBlockingQueue<>(3, (o1, o2) -> {
+            if (o1.compareTo(o2) < 0) {
+                return 1;
+            } else if (o1.compareTo(o2) > 0) {
+                return -1;
+            } else {
+                return 0;
+            }
+        });
+
+        ExecutorService service = Executors.newCachedThreadPool();
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Producer("Producer" + i, queue));
+        }
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Consumer("Consumer" + i, queue));
+        }
+        service.shutdown();
+    } 
+
+    static class Producer implements Runnable {
+        private final String name;
+        private final PriorityBlockingQueue<String> queue;
+        private static Random rand = new Random(System.currentTimeMillis());
+
+        Producer(String name, PriorityBlockingQueue<String> queue) {
+            this.name = name;
+            this.queue = queue;
+        }
+
+        @Override
+        public void run() {
+            for (int i = 0; i < 10; i++) {
+                String str = "Product" + rand.nextInt(1000);
+                queue.put(str);
+                System.out.println("->" + name + " put " + str);
+                try {
+                    TimeUnit.SECONDS.sleep(rand.nextInt(5));
+                } catch (InterruptedException e) {
+                    e.printStackTrace();
+                }
+            }
+            System.out.println(name + " is over");
+        }
+    }
+
+
+    static class Consumer implements Runnable {
+        private final String name;
+        private final PriorityBlockingQueue<String> queue;
+        private static Random rand = new Random(System.currentTimeMillis());
+
+        Consumer(String name, PriorityBlockingQueue<String> queue) {
+            this.name = name;
+            this.queue = queue;
+        }
+
+        @Override
+        public void run() {
+            try {
+                for (int i = 0; i < 10; i++) {
+                    String str = queue.take();
+                    System.out.println("<-" + name + " take " + str);
+                    TimeUnit.SECONDS.sleep(rand.nextInt(5));
+                }
+                System.out.println(name + " is over");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+        }
+    }
+}
+```
+##2.4  DelayQueue
+队列中只能存入Delayed接口实现的对象
+![DelayQueue](http://upload-images.jianshu.io/upload_images/4685968-66f774931c2df19a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![](http://upload-images.jianshu.io/upload_images/4685968-e9e3297ac26ca792.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-57058c0b0980efe6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+DelayQueue中存入的对象要同时实现getDelay和compareTo
+- getDelay方法是用来检测队列中的元素是否到期
+- compareTo方法是用来给队列中的元素进行排序
+![DelayQueue持有一个PriorityBlockingQueue](http://upload-images.jianshu.io/upload_images/4685968-9d79acebc32249fb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+每个Delayed对象实际上都放入了这个队列，并按照compareTo方法进行排序
+
+当队列中对象的getDelay方法返回的值<=0（即对象已经超时）时，才可以将对象从队列中取出
+若使用take方法，则方法会一直阻塞，直到队列头部的对象超时被取出
+若使用poll方法，则当没有超时对象时，直接返回null 
+
+总结来说，有如下几个特点： 
+1. 队列中的对象都是Delayed对象，它实现了getDelay和compareTo
+2. 队列中的对象按照优先级（按照compareTo）进行了排序，队列头部是最先超时的对象 
+3. take方法会在没有超时对象时一直阻塞，直到有对象超时；poll方法会在没有超时对象时返回null。 
+4. 队列中不允许存储null，且iterator方法返回的值不能确保按顺序排列
+ 
+下面是一个列子，特别需要注意getDelay和compareTo方法的实现：
+
+```
+public class DelayQueueExam {
+    public static void main(String[] args) throws InterruptedException {
+        DelayQueue<DelayElement> queue = new DelayQueue<>();
+        for (int i = 0; i < 10; i++) {
+            queue.put(new DelayElement(1000 * i, "DelayElement" + i));
+        }
+        while (!queue.isEmpty()) {
+            DelayElement delayElement = queue.take();
+            System.out.println(delayElement.getName());
+        }
+    }
+
+    static class DelayElement implements Delayed {
+        private final long delay;
+        private long expired;
+        private final String name;
+
+        DelayElement(int delay, String name) {
+            this.delay = delay;
+            this.name = name;
+            expired = System.currentTimeMillis() + delay;
+        }
+
+        public String getName() {
+            return name;
+        }
+
+        @Override
+        public long getDelay(TimeUnit unit) {
+            return unit.convert(expired - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
+        }
+
+        @Override
+        public int compareTo(Delayed o) {
+            long d = (getDelay(TimeUnit.MILLISECONDS) - o.getDelay(TimeUnit.MILLISECONDS));
+            return (d == 0) ? 0 : ((d < 0) ? -1 : 1);
+        }
+    }
+}
+```
+DelayQueue通过PriorityQueue，使得超时的对象最先被处理，将take对象的操作阻塞住，避免了遍历方式的轮询，提高了性能。在很多需要回收超时对象的场景都能用上
+###  BlockingDeque阻塞双向队列
+BlockingDeque中各种特性上都非常类似于BlockingQueue，事实上它也继承自BlockingQueue，它们的不同点主要在于BlockingDeque可以同时从队列头部和尾部增删元素。 
+因此，总结一下BlockingDeque的四组增删元素的方法： 
+第一组，抛异常的方法，包括addFirst(e)，addLast(e)，removeFirst()，removeLast()，getFirst()和getLast()； 
+第二组，返回特殊值的方法，包括offerFirst(e) ，offerLast(e) ，pollFirst()，pollLast()，peekFirst()和peekLast()； 
+第三组，阻塞的方法，包括putFirst(e)，putLast(e)，takeFirst()和takeLast()； 
+第四组，超时的方法，包括offerFirst(e, time, unit)，offerLast(e, time, unit)，pollFirst(time, unit)和pollLast(time, unit)。 
+BlockingDeque目前只有一个实现类LinkedBlockingDeque，其用法与LinkedBlockingQueue非常类似，这里就不给出实例了。
+### TransferQueue传输队列
+TransferQueue继承自BlockingQueue，之所以将它独立成章，是因为它是一个非常重要的队列，且提供了一些阻塞队列所不具有的特性。 
+简单来说，TransferQueue提供了一个场所，生产者线程使用transfer方法传入一些对象并阻塞，直至这些对象被消费者线程全部取出。前面介绍的SynchronousQueue很像一个容量为0的TransferQueue。 
+下面是一个例子，一个生产者使用transfer方法传输10个字符串，两个消费者线程则各取出5个字符串，可以看到生产者在transfer时会一直阻塞直到所有字符串被取出：
+
+```
+public class TransferQueueExam {
+    public static void main(String[] args) {
+        TransferQueue<String> queue = new LinkedTransferQueue<>();
+        ExecutorService service = Executors.newCachedThreadPool();
+        service.submit(new Producer("Producer1", queue));
+        service.submit(new Consumer("Consumer1", queue));
+        service.submit(new Consumer("Consumer2", queue));
+        service.shutdown();
+    }
+
+    static class Producer implements Runnable {
+        private final String name;
+        private final TransferQueue<String> queue;
+
+        Producer(String name, TransferQueue<String> queue) {
+            this.name = name;
+            this.queue = queue;
+        }
+        @Override
+        public void run() {
+            System.out.println("begin transfer objects");
+
+            try {
+                for (int i = 0; i < 10; i++) {
+                    queue.transfer("Product" + i);
+                    System.out.println(name + " transfer "+"Product"+i);
+                }
+                System.out.println("after transformation");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+            System.out.println(name + " is over");
+        }
+    }
+
+    static class Consumer implements Runnable {
+        private final String name;
+        private final TransferQueue<String> queue;
+        private static Random rand = new Random(System.currentTimeMillis());
+
+        Consumer(String name, TransferQueue<String> queue) {
+            this.name = name;
+            this.queue = queue;
+        }
+
+        @Override
+        public void run() {
+            try {
+                for (int i = 0; i < 5; i++) {
+                    String str = queue.take();
+                    System.out.println(name + " take " + str);
+                    TimeUnit.SECONDS.sleep(rand.nextInt(5));
+                }
+                System.out.println(name + " is over");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+        }
+    }
+}
+```
+上面的代码中只使用了transfer方法，TransferQueue共包括以下方法： 
+1. transfer(E e)，若当前存在一个正在等待获取的消费者线程，即立刻移交之；否则会将元素e插入到队列尾部，并进入阻塞状态，直到有消费者线程取走该元素。 
+2. tryTransfer(E e)，若当前存在一个正在等待获取的消费者线程（使用take()或者poll()函数），即立刻移交之； 否则返回false，并且不进入队列，这是一个非阻塞的操作。 
+3. tryTransfer(E e, long timeout, TimeUnit unit) 若当前存在一个正在等待获取的消费者线程，即立刻移交之；否则会将元素e插入到队列尾部，并且等待被消费者线程获取消费掉，若在指定的时间内元素e无法被消费者线程获取，则返回false，同时该元素被移除。 
+4. hasWaitingConsumer() 判断是否存在消费者线程。 
+5. getWaitingConsumerCount() 获取所有等待获取元素的消费线程数量。 
+再来看两个生产者和两个消费者的例子：
+
+```
+public class TransferQueueExam2 {
+    public static void main(String[] args) {
+        TransferQueue<String> queue = new LinkedTransferQueue<>();
+        ExecutorService service = Executors.newCachedThreadPool();
+        service.submit(new Producer("Producer1", queue));
+        service.submit(new Producer("Producer2", queue));
+        service.submit(new Consumer("Consumer1", queue));
+        service.submit(new Consumer("Consumer2", queue));
+        service.shutdown();
+    }
+
+    static class Producer implements Runnable {
+        private final String name;
+        private final TransferQueue<String> queue;
+
+        Producer(String name, TransferQueue<String> queue) {
+            this.name = name;
+            this.queue = queue;
+        }
+
+        @Override
+        public void run() {
+            System.out.println(name + " begin transfer objects");
+
+            try {
+                for (int i = 0; i < 5; i++) {
+                    queue.transfer(name + "_Product" + i);
+                    System.out.println(name + " transfer " + name + "_Product" + i);
+                }
+                System.out.println(name + " after transformation");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+            System.out.println(name + " is over");
+        }
+    }
+
+    static class Consumer implements Runnable {
+        private final String name;
+        private final TransferQueue<String> queue;
+        private static Random rand = new Random(System.currentTimeMillis());
+
+        Consumer(String name, TransferQueue<String> queue) {
+            this.name = name;
+            this.queue = queue;
+        }
+
+        @Override
+        public void run() {
+            try {
+                for (int i = 0; i < 5; i++) {
+                    String str = queue.take();
+                    System.out.println(name + " take " + str);
+                    TimeUnit.SECONDS.sleep(rand.nextInt(5));
+                }
+                System.out.println(name + " is over");
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }
+        }
+    }
+}
+```
+它的作者Doug Lea 这样评价它：TransferQueue是一个聪明的队列，它是ConcurrentLinkedQueue, SynchronousQueue (在公平模式下), 无界的LinkedBlockingQueues等的超集。 
+所以，在合适的场景中，请尽量使用TransferQueue，目前它只有一个实现类LinkedTransferQueue。
+
+### ConcurrentLinkedQueue并发链接队列
+#### 1 并发与并行
+写到此处时，应该认真梳理一下关于多线程编程中的一些名词了，具体包括多线程（MultiThread）、并发（Concurrency）和并行（Parrellism）。多线程的概念应该是比较清晰的，是指计算机和编程语言都提供线程的概念，多个线程可以同时在一台计算机中运行。 
+而并发和并行则是两个非常容易混淆的概念，第一种区分方法是以程序在计算机中的执行方式来区分。我称之为“并发执行”和“并行执行”的区分： 
+并发执行是指多个线程（例如n个）在一台计算机中宏观上“同时”运行，它们有可能是一个CPU轮换的处理n个线程，也有可能是m个CPU以各种调度策略来轮换处理n个线程； 
+并行执行是指多个线程（n个）在一台计算机的多个CPU（m个，m>=n）上微观上同时运行，并行执行时操作系统不需要调度这n个线程，每个线程都独享一个CPU持续运行直至结束。 
+第二种区分方法则是“并发编程”和“并行编程”的区别： 
+并发编程可以理解为多线程编程，并发编程的代码必定以“并发执行”的方式运行； 
+并行编程则是一种更加特殊的编程方法，它需要使用特殊的编程语言（例如Cilk语言），或者特殊的编程框架（例如Parallel Java 2 Library）。另外，我在本系列的第一篇中提到的Fork-Join框架也是一种并行编程框架。
+#### 2 并发的基础
+理解了并发的概念，我们再来看首次遇到的带有并发字眼（Concurrent）的类ConcurrentLinkedQueue，并发链接队列。 
+目前看来，可以这么认为，在java.util.concurrency包内，凡是带有Concurrent字眼的类，都是以CAS为基础的非阻塞工具类。例如ConcurrentLinkedQueue、ConcurrentLinkedDeque、ConcurrentHashMap、ConcurrentSkipListMap、ConcurrentSkipListSet。 
+好了，那么什么是CAS呢？CAS即CompareAndSwap“比较并交换”，具体的细节将会在后续的关于原子变量（Atomic）章节中介绍。简而言之，当代的很多CPU提供了一种CAS指令，由于指令运行不会被打断，因此依赖这种指令就可以设计出一种不需要锁的非阻塞并发算法，依赖这种算法，就可以设计出各种并发类。 
+#### 3 各类队列的例子
+下面的例子中，我们使用参数控制，分别测试了四种队列在多个线程同时存储变量时的表现：
+
+```
+public class ConcurrentLinkedQueueExam {
+    private static final int TEST_INT = 10000000;
+
+    public static void main(String[] args) throws InterruptedException {
+        long start = System.currentTimeMillis();
+        Queue<Integer> queue = null;
+        if (args.length < 1) {
+            System.out.println("Usage: input 1~4 ");
+            System.exit(1);
+        }
+        int param = Integer.parseInt(args[0]);
+        switch (param) {
+            case 1:
+                queue = new LinkedList<>();
+                break;
+            case 2:
+                queue = new LinkedBlockingQueue<>();
+                break;
+            case 3:
+                queue = new ArrayBlockingQueue<Integer>(TEST_INT * 5);
+                break;
+            case 4:
+                queue = new ConcurrentLinkedQueue<>();
+                break;
+            default:
+                System.out.println("Usage: input 1~4 ");
+                System.exit(2);
+        }
+        System.out.println("Using " + queue.getClass().getSimpleName());
+
+        ExecutorService service = Executors.newCachedThreadPool();
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Putter(queue, "Putter" + i));
+        }
+        TimeUnit.SECONDS.sleep(2);
+        for (int i = 0; i < 5; i++) {
+            service.submit(new Getter(queue, "Getter" + i));
+        }
+        service.shutdown();
+        service.awaitTermination(1, TimeUnit.DAYS);
+        long end = System.currentTimeMillis();
+        System.out.println("Time span = " + (end - start));
+        System.out.println("queue size = " + queue.size());
+    }
+
+    static class Putter implements Runnable {
+        private final Queue<Integer> queue;
+        private final String name;
+
+        Putter(Queue<Integer> queue, String name) {
+            this.queue = queue;
+            this.name = name;
+        }
+
+
+        @Override
+        public void run() {
+            for (int i = 0; i < TEST_INT; i++) {
+                queue.offer(1);
+            }
+            System.out.println(name + " is over");
+        }
+    }
+
+    static class Getter implements Runnable {
+        private final Queue<Integer> queue;
+        private final String name;
+
+        Getter(Queue<Integer> queue, String name) {
+            this.queue = queue;
+            this.name = name;
+        }
+
+        @Override
+        public void run() {
+            int i = 0;
+            while (i < TEST_INT) {
+                synchronized (Getter.class) {
+                    if (!queue.isEmpty()) {
+                        queue.poll();
+                        i++;
+                    }
+                }
+            }
+            System.out.println(name + " is over");
+        }
+    }
+}
+```
+
+```
+输入1，结果如下：
+
+Using LinkedList
+…
+Time span = 16613
+queue size = 10296577
+输入2，结果如下：
+
+Using LinkedBlockingQueue
+…
+Time span = 16847
+queue size = 0
+输入3，结果如下：
+
+Using ArrayBlockingQueue
+…
+Time span = 6815
+queue size = 0
+输入4，结果如下：
+
+Using ConcurrentLinkedQueue
+…
+Time span = 22802
+queue size = 0
+```
+分析运行的结果，有如下结论： 
+第一，非并发类例如LinkedList在多线程环境下运行是会出错的，结果的最后一行输出了队列的size值，只有它的size值不等于0，这说明在多线程运行时许多poll操作并没有弹出元素，甚至很多offer操作也没有能够正确插入元素。其他三种并发类都能够在多线程环境下正确运行； 
+第二，并发类也不是完全不需要注意加锁，例如这一段代码：
+
+```
+while (i < TEST_INT) {
+    synchronized (Getter.class) {
+        if (!queue.isEmpty()) {
+            queue.poll();
+            i++;
+        }
+    }
+}
+```
+如果不加锁，那么isEmpty和poll之间有可能被其他线程打断，造成结果的不确定性。 
+第三，本例中LinkedBlockingQueue和ArrayBlockingQueue并没有因为生产-消费关系阻塞，因为容量设置得足够大。它们的元素插入和弹出操作是加锁的，而ConcurrentLinkedQueue的元素插入和弹出操作是不加锁的，而观察性能其实并没有数量级上的差异（有待进一步测试）。 
+第四，ArrayBlockingQueue性能明显好于LinkedBlockingQueue，甚至也好于ConcurrentLinkedQueue，这是因为它的内部存储结构是原生数组，而其他两个是链表，需要new一个Node。同时，链表也会造成更多的GC。
+###  ConcurrentLinkedDeque并发链接双向队列
+ConcurrentLinkedDeque与ConcurrentLinkedQueue非常类似，不同之处仅在于它是一个双向队列。
+
+##3 **阻塞队列的实现原理**
+
+> Java的并发队列，具体包括BlockingQueue阻塞队列、BlockingDeque阻塞双向队列、TransferQueue传输队列、ConcurrentLinkedQueue并发链接队列和ConcurrentLinkedDeque并发链接双向队列。BlockingQueue和BlockingDeque的内部使用锁来保护元素的插入弹出操作，同时它们还提供了生产者-消费者场景的阻塞方法；TransferQueue被用来在多个线程之间优雅的传递对象；ConcurrentLinkedQueue和ConcurrentLinkedDeque依靠CAS指令，来实现非阻塞的并发算法。
+
+
+若队列为空，消费者会一直等待，当生产者添加元素时，消费者是如何知道当前队列有元素的呢？让我们看看JDK是如何实现的。
+***使用通知模式实现***。所谓通知模式，就是当生产者往满的队列里添加元素时会阻塞住生产者，当消费者消费了一个队列中的元素后，会通知生产者当前队列可用。通过查看源码发现ArrayBlockingQueue使用了Condition来实现，代码如下。
+
+```
+    private final Condition notFull;
+    private final Condition notEmpty;
+    
+    public ArrayBlockingQueue(int capacity, boolean fair) {
+        // 省略其他代码
+        notEmpty = lock.newCondition();
+        notFull = lock.newCondition();
+
+    public void put(E e) throws InterruptedException {
+        checkNotNull(e);
+        final ReentrantLock lock = this.lock;
+        lock.lockInterruptibly();
+        try {
+            while (count == items.length)
+                notFull.await();
+            enqueue(e);
+        } finally {
+            lock.unlock();
+        }
+    }
+    
+    public E take() throws InterruptedException {
+        final ReentrantLock lock = this.lock;
+        lock.lockInterruptibly();
+        try {
+            while (count == 0)
+                notEmpty.await();
+            return dequeue();
+        } finally {
+            lock.unlock();
+        }
+    }
+    
+     private void enqueue(E x) {
+        // assert lock.getHoldCount() == 1;
+        // assert items[putIndex] == null;
+        final Object[] items = this.items;
+        items[putIndex] = x;
+        if (++putIndex == items.length)
+            putIndex = 0;
+        count++;
+        notEmpty.signal();
+    }
+
+```
+当往队列里插入一个元素时，如果队列不可用，那么阻塞生产者主要通过
+LockSupport.park（this）来实现。
+
+```
+    public final void await() throws InterruptedException {
+        if (Thread.interrupted())
+            throw new InterruptedException();
+        Node node = addConditionWaiter();
+        int savedState = fullyRelease(node);
+        int interruptMode = 0;
+        while (!isOnSyncQueue(node)) {
+            LockSupport.park(this);
+            if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
+                break;
+        }
+        if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
+            interruptMode = REINTERRUPT;
+        if (node.nextWaiter != null) // clean up if cancelled
+            unlinkCancelledWaiters();
+        if (interruptMode != 0)
+            reportInterruptAfterWait(interruptMode);
+    }
+```
+
+继续进入源码，发现调用setBlocker先保存一下将要阻塞的线程，然后调用unsafe.park阻塞当前线程。
+
+```
+ public static void park(Object blocker) {
+        Thread t = Thread.currentThread();
+        setBlocker(t, blocker);
+        unsafe.park(false, 0L);
+        setBlocker(t, null);
+    }
+```
+unsafe.park是个native方法，代码如下。
+
+```
+public native void park(boolean isAbsolute, long time);
+```
+park这个方法会阻塞当前线程，只有以下4种情况中的一种发生时，该方法才会返回。
+
+ - 与park对应的unpark执行或已经执行时。“已经执行”是指unpark先执行，然后再执行park的情况。
+ - 线程被中断时。
+ - 等待完time参数指定的毫秒数时。
+ - 异常现象发生时，这个异常现象没有任何原因。
diff --git "a/Java/Java\344\270\255\347\232\204VO,PO\347\255\211.md" "b/Java/Java\344\270\255\347\232\204VO,PO\347\255\211.md"
new file mode 100644
index 0000000000..df7182aae0
--- /dev/null
+++ "b/Java/Java\344\270\255\347\232\204VO,PO\347\255\211.md"
@@ -0,0 +1,156 @@
+O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。
+通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。
+在O/R Mapping的世界里，有两个基本的也是重要的需要了解，即VO，PO。
+
+VO，值对象(Value Object)
+PO，持久对象(Persisent Object)
+它们是由一组属性及其get/set组成。从结构上看，它们并没有什么不同的地方。但从其意义和本质上来看是完全不同的。
+
+# １．
+- VO
+new关键字创建，由GC回收
+- PO
+向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。
+
+#２．
+- VO是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。
+- PO则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。
+
+# ３．
+- VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。
+- PO的属性是跟数据库表的字段一一对应的。
+
+## PO对象需要实现序列化接口。
+
+**PO是持久化对象**，它只是将物理数据实体的一种对象表示，为什么需要它？因为它可以简化我们对于物理实体的了解和耦合，简单地讲，可以简化对象的数据转换为物理数据的编程。VO是什么？它是值对象，准确地讲，它是业务对象，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，它是概念模型转换得到的。
+
+首先说PO和VO吧，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！不过，另外一点，如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。
+
+* * *
+
+### PO(persistant object) 持久对象
+
+在o/r映射的时候出现的概念，如果没有o/r映射，没有这个概念存在了。通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。
+
+# VO(value object) 值对象
+通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。
+但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.
+个人觉得同DTO(数据传输对象),在web上传递。
+
+### TO(Transfer Object)，数据传输对象
+
+在应用程序不同tie(关系)之间传输的对象
+
+### BO(business object) 业务对象
+
+从业务模型的角度看,见UML元件领域模型中的领域对象。封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作。
+
+### POJO(plain ordinary java object) 简单无规则java对象
+
+纯的传统意义的java对象。就是说在一些Object/Relation Mapping工具中，能够做到维护数据库表记录的persisent object完全是一个符合Java Bean规范的纯Java对象，没有增加别的属性和方法。我的理解就是最基本的Java Bean，只有属性字段及setter和getter方法！。
+
+### DAO(data access object) 数据访问对象
+
+是一个sun的一个标准j2ee设计模式，这个模式中有个接口就是DAO，它负持久层的操作。为业务层提供接口。此对象用于访问数据库。通常和PO结合使用，DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作。夹在业务逻辑与数据库资源中间。配合VO, 提供数据库的CRUD操作...
+
+### O/R Mapper 对象/关系 映射
+
+定义好所有的mapping之后，这个O/R Mapper可以帮我们做很多的工作。通过这些mappings,这个O/R Mapper可以生成所有的关于对象保存，删除，读取的SQL语句，我们不再需要写那么多行的DAL代码了。
+* * *
+
+> **_PO_**
+> 
+> ### persistant object 持久对象
+> 
+> 最形象的理解就是一个PO就是数据库中的一条记录。
+> 
+> 好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
+> **_BO_**
+> 
+> ### business object 业务对象
+> 
+> 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
+> 
+> 比如一个简历，有教育经历、工作经历、社会关系等等。
+> 
+> 我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
+> 
+> 建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
+> 
+> 这样处理业务逻辑时，我们就可以针对BO去处理。
+> **_VO_** ：
+> 
+> ### value object 值对象
+> 
+> ViewObject表现层对象
+> 
+> 主要对应界面显示的数据对象。对于一个WEB页面，用一个VO对象对应整个界面的值。
+> **_DTO_** ：
+> 
+> ### Data Transfer Object数据传输对象
+> 
+> 主要用于远程调用等需要大量传输对象的地方。
+> 
+> 比如我们一张表有100个字段，那么对应的PO就有100个属性。
+> 
+> 但是我们界面上只要显示10个字段，
+> 
+> 客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
+> 
+> 这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服&gt;务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就&gt;转为VO
+> **_POJO_** ：
+> 
+> ### plain ordinary java object 简单java对象
+> 
+> 个人感觉POJO是最常见最多变的对象，是一个中间对象，也是我们最常打交道的对象。
+> 
+> 一个POJO持久化以后就是PO
+> 
+> 直接用它传递、传递过程中就是DTO
+> 
+> 直接用来对应表示层就是VO
+> **_DAO_**：
+> 
+> ### data access object数据访问对象
+> 
+> 这个大家最熟悉，和上面几个O区别最大，基本没有互相转化的可能性和必要.
+> 
+> 主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO
+
+
+
+**_VO：值对象、视图对象_**
+
+**_PO：持久对象_**
+
+**_QO：查询对象_**
+
+**_DAO：数据访问对象_**
+
+**_DTO：数据传输对象_**
+
+* * *
+
+**_struts 里的 ActionForm 就是个VO;_**
+
+**_hibernate里的 实体bean就是个PO,也叫POJO;_**
+
+**_hibernate里的Criteria 就相当于一个QO;_**
+
+**_在使用hibernate的时候我们会定义一些查询的方法,这些方法写在接口里,可以有不同的实现类.而这个接口就可以说是个DAO._**
+
+**_个人认为QO和DTO差不多._**
+
+* * *
+
+PO或叫BO，与数据库最接近的一层，是ORM中的O，基本上是数据库字段对应BO中的一个属性，为了同步与安全性考虑，最好只给DAO或者Service调用，而不要用packcode,backingBean,或者BO调。
+
+**_DAO，数据访问层，把VO，backingBean中的对象可以放入。。。。
+
+DTO，很少用，基本放入到DAO中，只是起到过渡的作用。
+
+QO，是把一些与持久性查询操作与语句放入。。
+
+VO，V层中用到的基本元素与方法等放其中。如果要其调用BO，则要做BO转换VO，VO转换BO操作。VO的好处是其页面的元素属性多于BO，可起到很好的作用。。。。_**
+
+
diff --git "a/Java/Java\344\270\255\347\232\204\351\224\201\344\274\230\345\214\226.md" "b/Java/Java\344\270\255\347\232\204\351\224\201\344\274\230\345\214\226.md"
new file mode 100644
index 0000000000..46b849f712
--- /dev/null
+++ "b/Java/Java\344\270\255\347\232\204\351\224\201\344\274\230\345\214\226.md"
@@ -0,0 +1,125 @@
+我们知道synchronized是重量级锁，效率不怎么样，不过在JDK6中对synchronize的实现进行了各种优化，使得它显得不是那么重了，那么JVM采用了那些优化手段呢
+# 锁优化
+如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。 
+锁主要存在四种状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态
+他们会随着竞争的激烈而逐渐升级。
+注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率
+## 自旋锁
+线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。
+同时我们发现在许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。
+ 
+所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。
+
+怎么等待呢？执行一段无意义的循环即可（自旋）。
+ 
+自旋等待不能替代阻塞，先不说对处理器数量的要求，虽然它可以避免线程切换带来的开销，但是它占用了处理器的时间。
+如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。
+所以说，自旋等待的时间（自旋的次数）必须要有一个限度，如果自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。 
+
+自旋锁在JDK 1.4.2中引入，默认关闭，但是可以使用-XX:+UseSpinning开启，在JDK1.6中默认开启。同时自旋的默认次数为10次，可以通过参数-XX:PreBlockSpin来调整； 
+如果通过参数-XX:preBlockSpin来调整自旋锁的自旋次数，会带来诸多不便。假如我将参数调整为10，但是系统很多线程都是等你刚刚退出的时候就释放了锁（假如你多自旋一两次就可以获取锁），你是不是很尴尬。于是JDK1.6引入自适应的自旋锁，让虚拟机会变得越来越聪明。
+## 适应自旋锁
+JDK 1.6引入了更加聪明的自旋锁，即自适应自旋锁。
+所谓自适应就意味着自旋的次数不再是固定的，它由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。
+
+它怎么做呢？
+线程如果自旋成功了，那么下次自旋的次数会更多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。 
+
+有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。
+## 锁消除
+为了保证数据的完整性，我们在进行操作时需要对这部分操作进行同步控制，但是在有些情况下，JVM检测到不可能存在共享数据竞争，这时JVM会对这些同步锁进行锁消除。
+
+锁消除的依据是逃逸分析的数据支持。
+ 
+如果不存在竞争，为什么还需要加锁呢？所以锁消除可以节省毫无意义的请求锁的时间。
+变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是对于我们程序员来说这还不清楚么？但有时候程序并不是我们所想的那样,我们虽然没有显示使用锁，但是我们在使用一些JDK的内置API时，如StringBuffer、Vector、HashTable等，这时候会存在隐形的加锁操作。比如StringBuffer的append()方法，Vector的add()方法
+
+```
+    public void vectorTest(){
+        Vector<String> vector = new Vector<String>();
+        for(int i = 0 ; i < 10 ; i++){
+            vector.add(i + "");
+        }
+
+        System.out.println(vector);
+    }
+```
+在运行这段代码时，JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外，所以JVM可以大胆地将vector内部的加锁操作消除。
+## 锁粗化
+我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小,即仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁 
+
+在大多数的情况下，上述观点是正确的，本人也一直坚持着这个观点。但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗化的概念:
+就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁
+
+如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环外
+
+## 轻量级锁
+主要目的是在没有多线程竞争的前提下，减少传统的重量级锁使用OS的互斥量(mutex)产生的性能消耗。
+当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁，则会尝试获取轻量级锁，其步骤如下： 
+###**获取锁** 
+1. 判断当前对象是否处于无锁状态（hashcode、0、01）
+   - 是
+JVM将首先在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word）
+   - 否
+执行3 
+2. JVM利用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指正
+   - 成功(表示竞争到锁)
+将锁标志位变成00（表示此对象处于轻量级锁状态），执行同步操作
+   - 失败
+执行3 
+3. 判断当前对象的Mark Word是否指向当前线程的栈帧
+   - 是(表示当前线程已经持有当前对象的锁)
+直接执行同步代码块
+   - 否(只能说明该锁对象已经被其他线程抢占)
+轻量级锁需要膨胀为重量级锁，锁标志位变成10，后面等待的线程将会进入阻塞状态
+###**释放锁** 
+轻量级锁的释放也是通过CAS操作来进行的，主要步骤如下： 
+1. 取出获取轻量级锁时保存在Displaced Mark Word中的数据 
+2. 用CAS操作将取出的数据替换到当前对象的Mark Word中
+   - 成功
+说明释放锁成功
+   - 失败
+执行3 
+3. CAS操作替换失败，说明有其他线程尝试获取该锁，则需要在释放锁的同时需要唤醒被挂起的线程
+
+对于轻量级锁，其性能提升的依据是
+"对于绝大部分的锁，在整个生命周期内都是不会存在竞争的"
+如果打破这个依据则除了互斥的开销外，还有额外的CAS操作，因此在有多线程竞争的情况下，轻量级锁比重量级锁更慢
+
+* * *
+
+下图是轻量级锁的获取和释放过程 
+![](http://upload-images.jianshu.io/upload_images/4685968-835dc27a4cab0094.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 偏向锁
+目的：在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径。
+上面提到了轻量级锁的加锁解锁操作是需要依赖多次CAS原子指令的。
+那么偏向锁是如何来减少不必要的CAS操作呢？
+我们可以查看Mark work的结构就明白了。
+只需要检查是否为偏向锁、锁标识为以及ThreadID即可，处理流程如下： 
+###**获取锁** 
+1. 检测Mark Word是否为可偏向状态，即是否为偏向锁1，锁标识位为01 
+2. 若为可偏向状态，则测试线程ID是否为当前线程ID
+   - 是
+执行5
+   - 否
+执行3 
+3. 如果线程ID不为当前线程ID，则通过CAS操作竞争锁,竞争
+   - 成功
+将Mark Word的线程ID替换为当前线程ID，
+   - 失败
+执行4 
+4. CAS竞争锁失败，证明当前存在多线程竞争情况，当到达全局安全点，获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码块
+5. 执行同步代码块
+###**释放锁** 
+偏向锁的释放采用了一种只有竞争才会释放锁的机制，线程是不会主动去释放偏向锁，需要等待其他线程来竞争。
+偏向锁的撤销需要等待全局安全点（这个时间点是上没有正在执行的代码）。其步骤如下： 
+1. 暂停拥有偏向锁的线程，判断锁对象石是否还处于被锁定状态
+2. 撤销偏向锁，恢复到无锁状态（01）或者轻量级锁的状态
+
+* * *
+
+下图是偏向锁的获取和释放流程 
+![](http://upload-images.jianshu.io/upload_images/4685968-15051bba71218318?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 重量级锁
+重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高
diff --git "a/Java/Java\344\270\255\347\261\273\345\236\213\345\217\202\346\225\260\342\200\234-T-\342\200\235\345\222\214\346\227\240\347\225\214\351\200\232\351\205\215\347\254\246\342\200\234---\342\200\235\347\232\204\345\214\272\345\210\253.md" "b/Java/Java\344\270\255\347\261\273\345\236\213\345\217\202\346\225\260\342\200\234-T-\342\200\235\345\222\214\346\227\240\347\225\214\351\200\232\351\205\215\347\254\246\342\200\234---\342\200\235\347\232\204\345\214\272\345\210\253.md"
new file mode 100644
index 0000000000..7bdb763e2b
--- /dev/null
+++ "b/Java/Java\344\270\255\347\261\273\345\236\213\345\217\202\346\225\260\342\200\234-T-\342\200\235\345\222\214\346\227\240\347\225\214\351\200\232\351\205\215\347\254\246\342\200\234---\342\200\235\347\232\204\345\214\272\345\210\253.md"
@@ -0,0 +1,72 @@
+首先要区分开两种不同的场景：
+- 声明一个泛型类或泛型方法
+类型参数“<T>”主要用于第一种，声明泛型类或泛型方法
+- 使用泛型类或泛型方法
+无界通配符“<?>”主要用于第二种，使用泛型类或泛型方法
+
+# 1  <T>声明泛型类的类型参数
+List<T>最应该出现的地方，应该是定义一个泛型List容器
+但List是库里自带的容器，看看ArrayList的源码头一行：
+![](https://upload-images.jianshu.io/upload_images/4685968-84ea03662073cea7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ArrayList<E>中的“E”也是类型参数。只是表示容器中元素Element的时候，习惯用“E”
+换一个简单的例子，我们自己定义一个新泛型容器叫Box<T>。
+```
+class Box<T>{
+    private T item1;
+    private T item2;
+}
+```
+为什么这里要用类型参数？因为这是一种”约束“，为了保证Box里的item1, item2都是同一个类型T。Box<String>，代表两个item都是String。Box<Integer>里两个item都是Integer。
+
+List容器库里都帮我们写好了，所以我们是不会去定义List<T>的
+
+那什么时候会出现List<T>
+要么是作为泛型类的成员字段或成员方法的参数间接出现。还是刚才Box<T>的例子，
+```
+class Box<T>{
+    private List<T> item;
+    public List<T> get(){return item;}
+    public void set(List<T> t){item=t;}
+}
+```
+现在Box类里有三个地方出现了List<T>：
+- 成员字段item的类型
+- get( )方法的返回值
+- set( )方法的参数
+
+这里写成List<T>为了表示和Box<T>类型参数保持一致
+# 2 <T>声明泛型方法
+另外一种会出现List<T>的地方是泛型方法
+比如Function类的reduce是个静态泛型方法，负责对列表里的所有元素求和
+这里的List<T>出现在参数，函数返回值和函数内部，也是为了保持泛型类型的一致性
+```
+class Fuction{
+    public static <T> List<T> reduce(List<T> list){
+        //...do something
+    }
+}
+```
+# 3  声明泛型类不能用无界通配符<?>
+反观List<?>，首先要明确`通配符不能拿来声明泛型`
+像下面这样用通配符"?"来表示类型参数的约束是不行的
+![Error Example](https://upload-images.jianshu.io/upload_images/4685968-ffe6bcebda2d1168.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+通配符是拿来使用定义好的泛型的
+比如用<?>声明List容器的变量类型，然后用一个实例对象给它赋值的时候就比较灵活。
+![](https://upload-images.jianshu.io/upload_images/4685968-b0642daae444a300.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 4 <?>的坑
+List<?>这个写法非常坑。因为，这时候通配符会捕获具体的String类型，但编译器不叫它String，而是起个临时的代号，比如”capture#1“
+所以以后再也不能往list里存任何元素，包括String,唯一能存的就是null
+![](https://upload-images.jianshu.io/upload_images/4685968-7f914a83dbef3b07.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-973e44c8d7a90e88.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+另外如果拿List<?>做参数，也会有奇妙的事情发生。还是刚才Box<T>的例子，有get()和set()两个方法，一个存，一个取。
+![](https://upload-images.jianshu.io/upload_images/4685968-1ae09c9e4b5cfdb0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+新的getSet()方法，只是把item先用get()方法读出来，然后再用set()方法存回去。按理说不可能有问题。实际运行却会报错。
+```
+error: incompatible types: Object cannot be converted to capture#1
+```
+原因和前面一样，通配符box<?>.set()的参数类型被编译器捕获，命名为capture#1，和box<?>.get()返回的Object对象无法匹配
+
+解决方法，是要给getSet()方法写一个辅助函数
+![](https://upload-images.jianshu.io/upload_images/4685968-7e4ad9a8b84347bc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 5. 有界通配符<? extends XXX>，<? super XXX>
+实际更常用的是<? extends XXX>或者<? super XXX>两种，带有上下界的通配符
diff --git "a/Java/Java\345\206\205\345\255\230\346\250\241\345\236\213\344\270\216volatile\345\205\263\351\224\256\345\255\227.md" "b/Java/Java\345\206\205\345\255\230\346\250\241\345\236\213\344\270\216volatile\345\205\263\351\224\256\345\255\227.md"
new file mode 100644
index 0000000000..fa277f0abb
--- /dev/null
+++ "b/Java/Java\345\206\205\345\255\230\346\250\241\345\236\213\344\270\216volatile\345\205\263\351\224\256\345\255\227.md"
@@ -0,0 +1,371 @@
+# 1 Java内存模型(JMM)的意义
+![](https://upload-images.jianshu.io/upload_images/4685968-92a1fdf48be19e06.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-23e5e9a49adeb5a1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![JMM 与硬件内存架构对应关系](https://upload-images.jianshu.io/upload_images/4685968-5e1374a0abf9c929.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![JMM抽象结构图](https://upload-images.jianshu.io/upload_images/4685968-d4ea8843a88a940d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+Java虚拟机规范中试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，规定
+- 线程如何,何时能看到其他线程修改过的共享变量的值
+- 在必要时如何同步地访问共享变量
+
+以实现让Java程序在各种平台下都能达到一致性的内存访问效果。
+# 2 主内存与工作内存
+- Java内存模型的主要目标是定义`各个变量的访问规则`
+即在虚拟机中将变量存储到内存和从内存中取出变量值这样的底层细节
+
+此处的`变量`包括了实例域，静态域和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不存在竞争
+
+为了获得比较好的执行效率，JMM并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器调整代码执行顺序这类权限。
+
+JMM`规定`
+- 所有的变量都存储在主内存(Main Memory)
+- 每条线程有自己的工作内存(Working Memory)
+保存了该线程使用到的`变量的主内存副本拷贝`(线程所访问对象的引用或者对象中某个在线程访问到的字段,不会是整个对象的拷贝!)
+线程对变量的所有操作(读，赋值等)都必须在工作内存中进行，不能直接读写主内存中的变量
+volatile变量依然有工作内存的拷贝,只是他特殊的操作顺序性规定,看起来如同直接在主内存读写
+不同线程之间无法直接访问对方工作内存中的变量，线程间变量值的传递均要通过主内存
+![线程、主内存、工作内存三者的交互关系](https://upload-images.jianshu.io/upload_images/4685968-12209b12d578a2ed.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-bb3d37c155cd82d8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+JVM模型与JMM不是同一层次的内存划分，基本是没有关系的，硬要对应起来，从变量，内存，工作内存的定义来看
+  - 主内存 === Java堆中的对象实例数据部分
+  - 工作内存 === 虚拟机栈中的部分区域
+ 
+从更底层的层次来说
+- 主内存直接对应于物理硬件的内存
+- 为了更好的运行速度，虚拟机（甚至硬件系统的本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存器中，因为程序运行时主要访问读写的是工作内存
+# 3 内存间同步操作
+一个变量如何从主内存拷贝到工作内存,从工作内存同步回主内存的实现细节
+JMM定义了以下8种操作来完成，都具备`原子性`
+- lock(锁定)
+作用于主内存变量，把一个变量标识为一条线程独占的状态
+- unlock(解锁)
+作用于主内存变量，把一个处于锁定状态的变量释放,释放后的变量才可以被其它线程锁定
+unlock之前必须将变量值同步回主内存
+- read(读取)
+作用于主内存变量，把一个变量的值从主内存传输到工作内存，以便随后的load
+- load(载入)
+作用于工作内存变量，把read从主内存中得到的变量值放入工作内存的变量副本
+- use(使用)
+作用于工作内存变量，把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到的变量的值得字节码指令时将会执行这个操作
+- assign(赋值)
+作用于工作内存变量，把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作
+- store(存储)
+作用于工作内存变量，把工作内存中一个变量的值传送到主内存，以便随后的write操作使用
+- write(写入)
+作用于主内存变量，把store操作从工作内存中得到的值放入主内存的变量中
+![JMM 同步操作](https://upload-images.jianshu.io/upload_images/4685968-9dd14e316ab68184.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 把一个变量从主内存`复制`到工作内存
+就要顺序执行read和load
+
+- 把变量从工作内存`同步`回主内存
+就要顺序地执行store和write操作
+
+JMM只要求上述两个操作必须`按序执行`，而没有保证连续执行
+也就是说read/load之间、store/write之间可以插入其它指令
+如对主内存中的变量a,b访问时，一种可能出现的顺序是read a->readb->loadb->load a
+
+JMM规定执行上述八种基础操作时必须满足如下
+## 3.1 同步规则
+- 不允许read/load、store/write操作之一单独出现
+不允许一个变量从主内存读取了但工作内存不接收，或从工作内存发起回写但主内存不接收
+- 不允许一个线程丢弃它的最近的assign
+即变量在工作内存中改变(为工作内存变量赋值)后必须把该变化同步回主内存
+- 新变量只能在主内存“诞生”，不允许在工作内存直接使用一个未被初始化(load或assign)的变量
+换话说就是一个变量在实施use，store之前，必须先执行过assign和load
+- 如果一个变量事先没有被load锁定，则不允许对它执行unlock，也不允许去unlock一个被其它线程锁定的变量
+- 对一个变量执行unloack前，必须把此变量同步回主内存中(执行store，write)
+
+**`volatile`**变量可以被看作是一种 **"轻量的 `synchronized`**
+可以说是JVM提供的最轻量级的同步机制
+
+当一个变量定义为volatile后
+- 保证此变量对所有线程的可见性
+# 4 原子性(Atomicity)
+一次只允许一个线程持有某锁，一次只有一个线程能使用共享数据
+
+由JMM直接保证的原子性变量操作包括read、load、use、assign、store和write六个，大致可以认为基础数据类型的访问读写是原子性的
+
+如果应用场景需要一个更大范围的原子性保证，JMM还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock与unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐匿地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块synchronized关键字，因此在synchronized块之间的操作也具备原子性
+#5  可见性(Visibility)
+当一个线程修改了线程共享变量的值，其它线程能够立即得知这个修改
+
+由于现代可共享内存的多处理器架构可能导致一个线程无法马上（甚至永远）看到另一个线程操作产生的结果。所以 Java 内存模型规定了 JVM 的一种最小保证：什么时候写入一个变量对其他线程可见。
+
+在现代可共享内存的多处理器体系结构中每个处理器都有自己的缓存，并周期性的与主内存协调一致。假设线程 A 写入一个变量值 V，随后另一个线程 B 读取变量 V 的值
+在下列情况下，线程 B 读取的值可能不是线程 A 写入的最新值：
+- 执行线程 A 的处理器把变量 V 缓存到寄存器中。
+- 执行线程 A 的处理器把变量 V 缓存到自己的缓存中，但还没有同步刷新到主内存中去。
+- 执行线程 B 的处理器的缓存中有变量 V 的旧值。
+
+JMM通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性,无论是普通变量还是volatile变量都是如此
+
+普通变量与volatile变量的区别是
+`volatile的特殊规则保证了新值能立即同步到主内存，以及每使用前立即从内存刷新`
+因此volatile保证了线程操作时变量的可见性，而普通变量则不能保证
+
+除了volatile，Java还有两个关键字能实现可见性
+- synchronized
+由“对一个变量执行`unlock`前，必须先把此变量同步回主内存中(执行`store`和`write`)”这条规则获得的
+- final
+被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把"this"的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那在其他线程中就能看见final字段的值
+
+必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程可见,对域中的值做赋值和返回的操作通常是原子性的,但递增/减并不是
+
+volatile对所有线程是立即可见的，对volatile变量所有的写操作都能立即返回到其它线程之中，换句话说，volatile变量在各个线程中是一致的，但并非基于volatile变量的运算在并发下是安全的
+
+volatile变量在各线程的工作内存中不存在一致性问题(在各个线程的工作内存中volatile变量也可以存在不一致，但由于
+`每次使用之前都要先刷新 ` ，执行引擎看不到不一致的情况,因此可以认为不存在一致性问题)，但Java里的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的
+```java
+public class Atomicity {
+	int i;
+	void f(){
+		i++;
+	}
+	void g(){
+		i += 3;
+	}
+}
+```
+编译后文件
+```java
+void f();
+		0  aload_0 [this]
+		1  dup
+		2  getfield concurrency.Atomicity.i : int [17]
+		5  iconst_1
+		6  iadd
+		7  putfield concurrency.Atomicity.i : int [17]
+ // Method descriptor #8 ()V
+ // Stack: 3, Locals: 1
+ void g();
+		0  aload_0 [this]
+		1  dup
+		2  getfield concurrency.Atomicity.i : int [17]
+		5  iconst_3
+		6  iadd
+		7  putfield concurrency.Atomicity.i : int [17]
+}
+```
+每个操作都产生了一个 get 和 put ，之间还有一些其他的指令
+因此在获取和修改之间，另一个线程可能会修改这个域
+所以，这些操作不是原子性的
+
+再看下面这个例子是否符合上面的描述
+```java
+public class AtomicityTest implements Runnable {
+	  private int i = 0;
+	  public int getValue() {
+		  return i;
+	  }
+
+	  private synchronized void evenIncrement() {
+		  i++;
+		  i++;
+	  }
+
+	  public void run() {
+	    while(true)
+	      evenIncrement();
+	  }
+
+	  public static void main(String[] args) {
+	    ExecutorService exec = Executors.newCachedThreadPool();
+	    AtomicityTest at = new AtomicityTest();
+	    exec.execute(at);
+	    while(true) {
+	      int val = at.getValue();
+	      if(val % 2 != 0) {
+	        System.out.println(val);
+	        System.exit(0);
+	      }
+	    }
+	  }
+}
+output:
+1
+```
+该程序将找到奇数值并终止
+尽管`return i `原子性，但缺少同步使得其数值可以在处于不稳定的中间状态时被读取
+由于 i 不是 volatile ,存在可视性问题
+getValue() 和 evenIncrement() 必须synchronized 
+ 
+
+对于基本类型的读/写操作被认为是安全的原子性操作
+但当对象处于不稳定状态时，仍旧很有可能使用原子性操作来访问他们
+最明智的做法是遵循同步的规则
+
+**volatile 变量只保证可见性**
+在不符合以下条件规则的运算场景中，仍需要通过加锁（使用synchronized或JUC中的原子类）来保证`原子性`
+- 运算结果不依赖变量的当前值，或者能确保只有单一的线程修改变量的值
+- 变量不需要与其它的状态变量共同参与不可变类约束
+
+基本上,若一个域可能会被多个任务同时访问or这些任务中至少有一个是写任务,那就该将此域设为volatile
+当一个域定义为 volatile 后，将具备
+> **1.保证此变量对所有的线程的可见性，当一个线程修改了这个变量的值，volatile 保证了新值能立即同步到主内存，其它线程每次使用前立即从主内存刷新**
+但普通变量做不到这点，普通变量的值在线程间传递均需要通过主内存来完成
+> **2.禁止指令重排序。有volatile修饰的变量，赋值后多执行了一个“load addl $0x0, (%esp)”操作，这个操作相当于一个内存屏障**（指令重排序时不能把后面的指令重排序到内存屏障之前的位置）
+这些操作的目的是用线程中的局部变量维护对该域的精确同步
+#6  指令重排序
+编译器生成指令的次序，可以不同于源代码所暗示的“显然”版本。重排序后的指令，对于优化执行以及成熟的全局寄存器分配算法的使用，都是大有脾益的，它使得程序在计算性能上有了很大的提升。
+
+重排序类型包括：
+- 编译器生成指令的次序，可以不同于源代码所暗示的“显然”版本。
+- 处理器可以乱序或者并行的执行指令。
+- 缓存会改变写入提交到主内存的变量的次序。
+
+有序性：**即程序执行的顺序按照代码的先后顺序执行**
+
+
+使用volatile变量的第二个语义是`禁止指令重排序优化`
+
+普通变量仅保证该方法执行过程所有依赖赋值结果的地方能获取到正确结果,而不保证变量赋值操作的顺序与代码执行顺序一致
+因为在一个线程的方法执行过程中无法感知到这一点，这也就是JMM中描述的所谓的
+`线程内表现为串行的语义(Within-Thread As-If-Serial Sematics)`
+```
+Map configOptions;  
+char[] configText;  
+//此变量必须定义为volatile  
+volatile boolean initialized = false;  
+
+//假设以下代码在线程A中执行  
+
+//模拟读取配置信息，当读取完成后  
+//将initialized设置为true来通知其它线程配置可用  
+configOptions = new HashMap();  
+configText = readConfigFile(fileName);  
+processConfigOptions(configText, configOptions);  
+initialized = true;  
+
+//假设以下代码在线程B中执行  
+
+//等线程A待initialized为true，代表线程A已经把配置信息初始化完成  
+while(!initialized) {  
+    sleep();  
+}  
+//使用线程A中初始化好的配置信息  
+doSomethingWithConfig();
+```
+如果定义`initialized`时没有使用`volatile`，就可能会由于指令重排序优化，导致位于线程A中最后一行的代码`initialized = true`被提前执行，这样在线程B中使用配置信息的代码就可能出现错误，而`volatile`关键字则可以完美避免
+
+volatile变量读操作性能消耗与普通变量几乎无差,但写操作则可能会稍慢，因为它需要在代码中插入许多内存屏障指令来保证处理器不发生乱序执行
+不过即便如此，大多数场景下volatile的总开销仍然要比锁小，我们在volatile与锁之中选择的`唯一依据仅仅是volatile的语义能否满足使用场景的需求`
+![单例模式](https://upload-images.jianshu.io/upload_images/4685968-da1ded2979016345.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![字节码指令](https://upload-images.jianshu.io/upload_images/4685968-c1ddcbde64dfe68d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![汇编指令](https://upload-images.jianshu.io/upload_images/4685968-63333e96dda3f0aa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+`volatile`修饰的变量，赋值后(前面`mov %eax,0x150 (%esi)` 这句便是赋值操作) 多执行了一个`1ock add1 $ 0x0,(%esp)`,这相当于一个内存屏障(Memory Barrier/Fence,指重排序时不能把后面的指令重排序到内存屏障之前的位置),只有一个CPU 访问内存时,并不需要内存屏障
+但如果有两个或更多CPU 访问同一块内存,且其中有一个在观测另一个,就需要内存屏障来保证一致性了
+
+这句指令中的`add1 $0x0, (%esp)`(把ESP 寄存器的值加0) 显然是一个空操作(采用这个空操作而不是空操作指令`nop` 是因为IA32手册规定`lock `前缀不允许配合`nop` 指令使用)，关键在于lock 前缀，查询IA32 手册，它的作用是使得本CPU 的Cache写入内存,该写入动作也会引起别的CPU 或者别的内核无效化(Inivalidate) 其Cache,这种操作相当于对Cache 中的变量做了一次`store和write`。所以通过这样一个空操作，可让前面volatile 变量的修改对其他CPU 立即可见。
+
+那为何说它禁止指令重排序呢?
+ 硬件架构上，指令重排序指CPU 采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。但并不是说指令任意重排，CPU需要能正确处理指令依赖情况以保障程序能得出正确的执行结果
+譬如指令1把地址A中的值加10，指令2把地址A 中的值乘以2,指令3把地址B 中的值减去了，这时指令1和指令2是有依赖的，它们之间的顺序不能重排,(A+10) *2 与A*2+10显然不等，但指令3 可以重排到指令i、2之前或者中间，只要保证CPU 执行后面依赖到A、B值的操作时能获取到正确的A 和B 值即可。所以在本CPU 中，重排序看起来依然是有序的。因此`lock add1 $0x0,(%esp)` 指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这样便形成了“指令重排序无法越过内存屏障”的效果
+
+举个例子
+```
+int i = 0;              
+boolean flag = false;
+i = 1;                //语句1  
+flag = true;          //语句2
+```
+从代码顺序上看，语句1在2前，JVM在真正执行这段代码的时候会保证**语句1一定会在语句2前面执行吗？**不一定，为什么呢？**这里可能会发生指令重排序（Instruction Reorder）**
+比如上面的代码中，语句1/2谁先执行对最终的程序结果并无影响，就有可能在执行过程中，语句2先执行而1后**虽然处理器会对指令进行重排序，但是它会保证程序最终结果会和代码顺序执行结果相同，**靠什么保证？**数据依赖性**
+
+> **编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序**
+
+举例
+```
+double pi  = 3.14;    //A  
+double r   = 1.0;     //B  
+double area = pi * r * r; //C  
+```
+![三个操作的数据依赖关系](http://upload-images.jianshu.io/upload_images/4685968-73d51df8127c3f33?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。
+因此在最终执行的指令序列中，C不能被重排序到A和B的前面（C排到A和B的前面，程序的结果将会被改变）。
+但A和B之间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序
+![该程序的两种执行顺序](http://upload-images.jianshu.io/upload_images/4685968-d3ab423cc91a8857?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+这里所说的数据依赖性仅针对**单个处理器中执行的指令序列和单个线程中执行的操作**，在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果
+但在**多线程程序中，**对存在控制依赖的操作重排序，可能会改变程序的执行结果。这是就需要**内存屏障来保证可见性了**
+
+回头看一下JMM对volatile 变量定义的特殊规则
+假定T 表示一个线程，V 和W 分别表示两个volatile变量，那么在进行read, load, use,assign,store,write时需要满定如下规则
+- 只有当线程T 对变量V 执行的前一个动作是load ,线程T 方能对变量V 执行use;并且，只有当线程T 对变量V 执行的后一个动作是`use`,线程T才能对变量V执行load.线程T 对变量V 的`use `可认为是和线程T对变量V的load,read相关联，必须连续一起出现(这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值语,用于保证能看见其他线程对变量V所做的修改后的值)
+- 只有当线程T 对变量V 执行的前一个动作是  `assign` ，线程T才能对变量V 执行`store` 
+并且，只有当线程T对变量V执行的后一个动作是`store` ,线程T才能对变量V执行`assign `
+线程T对变量V的`assign`可以认为是和线程T对变量V的store,write相关联，必须连续一起出现(这条规则要求在工作内存中，每次修改V 后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改)
+- 假定动作A 是线程T 对变量V实施的`use`或`assign `,假定动作F 是和动作A 相关联的`load `或`store `,假定动作P 是和动作F 相应的对变量V 的`read` 或`write` 
+类似的，假定动作B 是线程T 对变量W 实施的`use `或`assign` 动作，假定动作G是和动作B 相关联的`load `或`store`,假定动作Q 是和动作G 相应的对变量W的`read`或`write`
+如果A 先于B，那么P先于Q (这条规则要求volatile修饰的变量不会被指令重排序优化,保证代码的执行顺序与程序的顺序相同)
+## 6.1 对于Long和double型变量的特殊规则
+对于32位平台，64位的操作需要分两步来进行，与主存的同步。所以可能出现“半个变量”的状态。
+在实际开发中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待，因此我们在编码时一般不需要把用到的long和double变量专门声明为volatile。
+## 6.2 内存屏障
+### 6.2.1 分类
+- Load Barrier 读屏障
+- Store Barrier写屏障
+
+### 6.2.2 有序性(Ordering)
+JMM中程序的天然有序性可以总结为一句话：
+`如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有操作都是无序的。`
+前半句是指“线程内表现为串行语义”
+后半句是指“指令重排序”现象和“工作内存主主内存同步延迟”现象
+
+Java提供了volatile和synchronized保证线程之间操作的有序性
+volatile本身就包含了禁止指令重排序的语义
+synchronized则是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则来获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。
+
+### 6.2.3 先行发生原则
+如果JMM中所有的有序性都只靠volatile和synchronized，那么有一些操作将会变得很繁琐，但我们在编写Java并发代码时并没有感到这一点，这是因为Java语言中有一个`先行发生(Happen-Before)`原则
+这个原则非常重要，它是判断数据是否存在竞争，线程是否安全的主要依赖。
+
+先行发生原则是指JMM中定义的两项操作之间的依序关系
+如果说操作A先行发生于操作B，就是在说发生B前，A产生的影响能被B观察到，“影响”包含了修改内存中共享变量的值、发送了消息、调用了方法等。意味着什么呢？如下例：
+```
+//线程A中执行  
+i = 1;  
+
+//线程B中执行  
+j = i;  
+
+//线程C中执行  
+i = 2;
+```
+下面是JMM下一些”天然的“先行发生关系，无须任何同步器协助就已经存在，可以在编码中直接使用
+如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随意地重排序
+- 程序次序规则(Pragram Order Rule)
+在一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环结构。
+- 监视器锁法则(Monitor Lock Rule )
+一个`unlock`先行发生于后面对同一个锁的`lock`。这里必须强调的是同一个锁，而”后面“是指时间上的先后。
+- volatile变量规则(Volatile Variable Rule)
+对一个volatile变量的写操作先行发生于后面对这个变量的读取操作，这里的”后面“同样指时间上的先后顺序。
+- 线程启动规则(Thread Start Rule)
+Thread对象的start()方法先行发生于此线程的每一个动作。
+- 线程终止规则(Thread Termination Rule)
+线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束，Thread.isAlive()的返回值等作段检测到线程已经终止执行。
+- 线程中断规则(Thread Interruption Rule)
+对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生
+- 对象终结规则(Finalizer Rule)
+一个对象初始化完成(构造方法执行完成)先行发生于它的finalize()方法的开始
+- 传递性(Transitivity)
+如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论
+
+一个操作”时间上的先发生“不代表这个操作会是”先行发生“，那如果一个操作”先行发生“是否就能推导出这个操作必定是”时间上的先发生“呢？也是不成立的，一个典型的例子就是指令重排序
+所以时间上的先后顺序与先行发生原则之间基本没有什么关系，所以衡量并发安全问题一切必须以先行发生原则为准。
+
+### 6.2.4  作用
+> **1.阻止屏障两侧的指令重排序
+> 2.强制把写缓冲区/高速缓存中的脏数据等写回主内存，让缓存中相应的数据失效**
+*   对于Load Barrier来说，在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从新从主内存加载数据
+*   对于Store Barrier来说，在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见
+
+**Java的内存屏障实际上也是上述两种的组合，完成一系列的屏障和数据同步功能**
+> **LoadLoad屏障：**对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
+> **StoreStore屏障：**对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
+> **LoadStore屏障：**对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
+> **StoreLoad屏障：**对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能
+
+`volatile`的内存屏障策略非常严格保守
+> **在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障
+> 在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障**
+
+由于内存屏障的作用，避免了volatile变量和其它指令重排序、线程之间实现了通信，使得volatile表现出了锁的特性
diff --git "a/Java/Java\345\212\250\346\200\201\344\273\243\347\220\206\346\250\241\345\274\217jdk\345\222\214cglib.md" "b/Java/Java\345\212\250\346\200\201\344\273\243\347\220\206\346\250\241\345\274\217jdk\345\222\214cglib.md"
new file mode 100644
index 0000000000..f769405b49
--- /dev/null
+++ "b/Java/Java\345\212\250\346\200\201\344\273\243\347\220\206\346\250\241\345\274\217jdk\345\222\214cglib.md"
@@ -0,0 +1,224 @@
+
+#**jdk动态代理实例**
+jdk动态代理模式里面有个拦截器的概念，在jdk中，只要实现了**InvocationHandler**接口的类就是一个**拦截器类**
+还使用了些反射的相关概念。
+拦截器的概念不了解没关系，假如写了个请求到action，经过拦截器，然后才会到action。然后继续有之后的操作。
+拦截器就像一个过滤网，一层层的过滤，只要满足一定条件，才能继续向后执行。
+**拦截器的作用**：控制目标对象的目标方法的执行。
+
+**拦截器的具体操作步骤：
+1.引入类：目标类和一些扩展方法相关的类。
+2.赋值：调用构造函数给相关对象赋值
+3.合并逻辑处理：在invoke方法中把所有的逻辑结合在一起。最终决定目标方法是否被调用。**
+
+下面看具体的代码实例：
+```java
+目标接口类：
+package com.sss.designPattern.proxy.dynamicProxy.jdkDynamicProxy;  
+  
+/** 
+ * 目标接口： 
+ * 包含目标方法的声明 
+ */  
+public interface TargetInterface {  
+    /** 
+     * 目标方法 
+     */  
+    void business();  
+}  
+
+目标类：
+package com.sss.designPattern.proxy.dynamicProxy.jdkDynamicProxy;  
+  /** 
+ * 被代理的类 
+ * 目标对象类 
+ * 实现目标接口. 
+ * 继而实现目标方法。 
+ */  
+public class TargetObject implements TargetInterface {  
+  
+    /** 
+     * 目标方法(即目标操作) 
+     */  
+    @Override  
+    public void business() {  
+        System.out.println("business");  
+    }  
+  
+}  
+
+拦截器：
+package com.sss.designPattern.proxy.dynamicProxy.jdkDynamicProxy;  
+  
+import java.lang.reflect.InvocationHandler;  
+import java.lang.reflect.Method;  
+  
+/** 
+ * 动态代理-拦截器 
+ */  
+public class MyInterceptor implements InvocationHandler {  
+    private Object target;//目标类  
+  
+    public MyInterceptor(Object target) {  
+        this.target = target;  
+    }  
+  
+    /** 
+     * args 目标方法的参数 
+     * method 目标方法 
+     */  
+    @Override  
+    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {  
+        System.out.println("aaaaa");//切面方法a();  
+        //。。。  
+        method.invoke(this.target, args);//调用目标类的目标方法  
+        //。。。  
+        System.out.println("bbbbb");//切面方法f();  
+        return null;  
+    }  
+}  
+
+具体通过调用代理对象，来调用目标对象的目标方法的具体测试：
+[java] view plain copy
+package com.sss.designPattern.proxy.dynamicProxy.jdkDynamicProxy;  
+  
+import java.lang.reflect.Proxy;  
+  
+public class MainTest {  
+    public static void main(String[] args) {  
+        //目标对象  
+        TargetObject target = new TargetObject();  
+        //拦截器  
+        MyInterceptor myInterceptor = new MyInterceptor(target);  
+  
+        /* 
+         *  Proxy.newProxyInstance参数： 
+         *  1、目标类的类加载器 
+         *  2、目标类的所有的接口 
+         *  3、拦截器 
+         */  
+        //代理对象，调用系统方法自动生成  
+        TargetInterface proxyObj = (TargetInterface) Proxy.newProxyInstance(target.getClass().getClassLoader(), target.getClass().getInterfaces(), myInterceptor);  
+        proxyObj.business();  
+    }  
+}  
+```
+看完代码实例，要**对这个动态代理进一步理解，要考虑到以下的问题。
+1、代理对象是由谁产生的？**
+JVM，不像上次的静态代理，我们自己得new个代理对象出来。
+**2、代理对象实现了什么接口？**
+实现的接口是目标对象实现的接口。
+同静态代理中代理对象实现的接口。那个继承关系图还是相同的。
+代理对象和目标对象都实现一个共同的接口。就是这个接口。
+所以Proxy.newProxyInstance()方法返回的类型就是这个接口类型。
+**3、代理对象的方法体是什么？**
+代理对象的方法体中的内容就是拦截器中invoke方法中的内容。所有代理对象的处理逻辑，控制是否执行目标对象的目标方法。都是在这个方法里面处理的。
+**4、拦截器中的invoke方法中的method参数是在什么时候赋值的？**
+在客户端，代理对象调用目标方法的时候，此实例中为：proxyObj.business()；实际上进入的是拦截器中的invoke方法，这个时候
+，拦截器中的invoke方法中的method参数会被赋值。
+
+**最后，为啥这个方式叫做jdk动态代理呢？**
+因为这个动态代理对象是用jdk的相关代码生成的，所以这个叫**jdk动态代理**。
+后面的cglib动态代理，就是因为要用到cglib的jar包，所以才叫**cglib动态代理**。
+
+了解了一个，那么另一个也就差不多啦。就继续往下看吧。
+
+为什么要使用这个**cglib来实现这个动态代理**呢？因为spring框架要用。
+
+具体的代码实现如下：
+```java
+目标对象类：
+package com.sss.designPattern.proxy.dynamicProxy.cglbDynamicProxy;  
+  
+/** 
+ * 被代理的类 
+ * 目标对象类 
+ */  
+public class TargetObject {  
+  
+    /** 
+     * 目标方法(即目标操作) 
+     */  
+    public void business() {  
+        System.out.println("business");  
+    }  
+  
+}  
+
+拦截器类：
+package com.sss.designPattern.proxy.dynamicProxy.cglbDynamicProxy;  
+  
+import net.sf.cglib.proxy.Enhancer;  
+import net.sf.cglib.proxy.MethodInterceptor;  
+import net.sf.cglib.proxy.MethodProxy;  
+  
+import java.lang.reflect.Method;  
+  
+/** 
+ * 动态代理-拦截器 
+ */  
+public class MyInterceptor implements MethodInterceptor {  
+    private Object target;//目标类  
+  
+    public MyInterceptor(Object target) {  
+        this.target = target;  
+    }  
+  
+    /** 
+     * 返回代理对象 
+     * 具体实现，暂时先不追究。 
+     */  
+    public Object createProxy() {  
+        Enhancer enhancer = new Enhancer();  
+        enhancer.setCallback(this);//回调函数  拦截器  
+        //设置代理对象的父类,可以看到代理对象是目标对象的子类。所以这个接口类就可以省略了。  
+        enhancer.setSuperclass(this.target.getClass());  
+        return enhancer.create();  
+    }  
+  
+    /** 
+     * args 目标方法的参数 
+     * method 目标方法 
+     */  
+    @Override  
+    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {  
+        System.out.println("aaaaa");//切面方法a();  
+        //。。。  
+        method.invoke(this.target, objects);//调用目标类的目标方法  
+        //。。。  
+        System.out.println("bbbbb");//切面方法f();  
+        return null;  
+    }  
+}  
+
+测试类：
+[java] view plain copy
+package com.sss.designPattern.proxy.dynamicProxy.cglbDynamicProxy;  
+  
+public class MainTest {  
+    public static void main(String[] args) {  
+        //目标对象  
+        TargetObject target = new TargetObject();  
+        //拦截器  
+        MyInterceptor myInterceptor = new MyInterceptor(target);  
+        //代理对象，调用cglib系统方法自动生成  
+        //注意：代理类是目标类的子类。  
+        TargetObject proxyObj = (TargetObject) myInterceptor.createProxy();  
+        proxyObj.business();  
+    }  
+}  
+
+区别：
+首先从文件数上来说，cglib比jdk实现的少了个接口类。因为cglib返回的代理对象是目标对象的子类。而jdk产生的代理对象和目标对象都实现了一个公共接口。
+
+
+```
+动态代理分为两种：  
+   *  jdk的动态代理  
+      *  代理对象和目标对象实现了共同的接口  
+      *  拦截器必须实现InvocationHanlder接口  
+  
+   *  cglib的动态代理  
+      *  代理对象是目标对象的子类  
+      *  拦截器必须实现MethodInterceptor接口  
+      *  hibernate中session.load采用的是cglib实现的  
diff --git "a/Java/Java\345\244\232\347\272\277\347\250\213\344\270\255join\346\226\271\346\263\225\347\232\204\347\220\206\350\247\243.md" "b/Java/Java\345\244\232\347\272\277\347\250\213\344\270\255join\346\226\271\346\263\225\347\232\204\347\220\206\350\247\243.md"
new file mode 100644
index 0000000000..a7db05b47a
--- /dev/null
+++ "b/Java/Java\345\244\232\347\272\277\347\250\213\344\270\255join\346\226\271\346\263\225\347\232\204\347\220\206\350\247\243.md"
@@ -0,0 +1,87 @@
+许多同学刚开始学Java 多线程时可能不会关主Join 这个动作，因为不知道它是用来做什么的，而当需要用到类似的场景时却有可能会说Java 没有提供这种功能。
+
+当我们将一个大任务划分为多个小任务，多个小任务由多个线程去完成时，显然它们完成的先后顺序不可能完全一致。在程序中希望各个线程执行完成后，将它们的计算结果最终合并在一起，换句话说，要等待多个线程将子任务执行完成后，才能进行合并结果的操作。
+这时就可以选择使用Join 了，Join 可以帮助我们轻松地搞定这个问题，否则就需要用个循环去不断判定每个线程的状态。
+
+在实际生活中，就像把任务分解给多个人去完成其中的各个板块，但老板需要等待这些人全部都完成后才认为这个阶段的任务结束了，也许每个人的板块内部和别人还有相互的接口依赖，如果对方接口没有写好，自己的这部分也不算完全完成，就会发生类似于合并的动作(到底要将任务细化到什么粒度，完全看实际场景和自己对问题的理解)。下面用段简单的代码米说明Join 的使用。
+
+thread.Join把指定的线程加入到当前线程，可以将两个交替执行的线程合并为顺序执行的线程。比如在线程B中调用了线程A的Join()方法，直到线程A执行完毕后，才会继续执行线程B。
+![](https://upload-images.jianshu.io/upload_images/4685968-f6a1f06c3ef70293.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```java
+package com.sss.test;
+
+import java.util.Random;
+
+/**
+ * @author Shusheng Shi
+ */
+public class ThreadJoinTest {
+    static class Computer extends Thread {
+        private int start;
+        private int end;
+        private int result;
+        private int[] array;
+
+        public Computer(int[] array, int start, int end) {
+            this.array=array;
+            this.start=start;
+            this.end=end;
+        }
+
+        @Override
+        public void run() {
+            for (int i=start; i < end; i++) {
+                result+=array[i];
+            }
+
+            if (result < 0) {
+                result&=Integer.MAX_VALUE;
+            }
+
+        }
+
+        public int getResult() {
+            return result;
+
+        }
+    }
+
+    private final static int COUNTER=10000000;
+
+    public static void main(String[] args) throws InterruptedException {
+        int[] array=new int[COUNTER];
+        Random random=new Random();
+        for (int i=0; i < COUNTER; i++) {
+            array[i]=Math.abs( random.nextInt() );
+        }
+        long start=System.currentTimeMillis();
+        Computer c1=new Computer( array, 0, COUNTER );
+        Computer c2=new Computer( array, COUNTER / 2, COUNTER );
+        c1.start();
+        c2.start();
+        c1.join();
+        c2.join();
+        System.out.println( System.currentTimeMillis() - start );
+        System.out.println( (c1.getResult() + c2.getResult()) & Integer.MAX_VALUE );
+    }
+}
+```
+这个例子或许不太好，只是1000 万个随机数叠加，为了防此CPU计算过快，在计算中增加一些判定操作，最后再将计算完的两个值输出，也输出运算时间。如果在有多个CPU的机器上做测试，就会发现数据量大时，多个线程计算具有优势，但是这个优势非常小，
+而且在数据量较小的情况下,单线程会更快些。为何单线程可能会更快呢?
+最主要的原因是线程在分配时就有开销(每个线程的分配过程本身就高要执行很多条底层代码，这些代码的执行相当于很多条CPU 叠加运算的指令),Join 操作过程还有其他的各种开销。
+如果尝试将每个线程叠加后做一些其他的操作，例如IO读写、字符串处理等操作，多线程的优势就出来了，因为这样总体计算下来后，线程的创建时间是可以被忽略
+
+所以我们在考量系统的综合性能时不能就一一个点或某种测试就轻易得出一一个最终结论，定要考虑更多的变动因素。
+
+那么使用多线程带来更多的是上下文切换的开销，多线程操作的共享对象还会有锁瓶
+否则就是非线程安全的。
+颈,
+综合考量各种开销因素、时间、空间,
+最后利用大量的场景测试来证明推理是有
+指导性的，如果只是一味地为了用多线程而使用多线程，则往往很多事情可能会适得
+其反
+Join5 ?是语法层面的线程合并，其实它更像是当前线程处于BLOCKEN 状态时去等待
+I :他线程结束的事件，而且是逐个去Join。换句话说，Join 的顺序并不一一定是线程真正结
+束的顺序，要保证线程结束的顺J 字性，它还无法实现，即使在本例中它也不是唯一的实现
+方式，本章后面会提到许多基于并发编程工具的方式来实现会更加理想，管理也会更加体
+系化，能适应更多的业务场景需求。
diff --git "a/Java/Java\345\257\271\350\261\241\345\272\217\345\210\227\345\214\226\345\272\225\345\261\202\345\216\237\347\220\206\346\272\220\347\240\201\350\247\243\346\236\220.md" "b/Java/Java\345\257\271\350\261\241\345\272\217\345\210\227\345\214\226\345\272\225\345\261\202\345\216\237\347\220\206\346\272\220\347\240\201\350\247\243\346\236\220.md"
new file mode 100644
index 0000000000..9897731976
--- /dev/null
+++ "b/Java/Java\345\257\271\350\261\241\345\272\217\345\210\227\345\214\226\345\272\225\345\261\202\345\216\237\347\220\206\346\272\220\347\240\201\350\247\243\346\236\220.md"
@@ -0,0 +1,789 @@
+# What
+
+Java序列化是指把Java对象保存为二进制字节码的过程，Java反序列化是指把二进制码重新转换成Java对象的过程。
+
+那么为什么需要序列化呢？
+
+第一种情况是：一般情况下Java对象的声明周期都比Java虚拟机的要短，实际应用中我们希望在JVM停止运行之后能够持久化指定的对象，这时候就需要把对象进行序列化之后保存。
+
+第二种情况是：需要把Java对象通过网络进行传输的时候。因为数据只能够以二进制的形式在网络中进行传输，因此当把对象通过网络发送出去之前需要先序列化成二进制数据，在接收端读到二进制数据之后反序列化成Java对象。
+#How
+本部分以序列化到文件为例讲解Java序列化的基本用法。
+```java
+package test;
+
+import java.io.*;
+
+/**
+ * @author v_shishusheng
+ * @date 2018/2/7
+ */
+public class SerializableTest {
+    public static void main(String[] args) throws Exception {
+        FileOutputStream fos = new FileOutputStream("temp.out");
+        ObjectOutputStream oos = new ObjectOutputStream(fos);
+        TestObject testObject = new TestObject();
+        oos.writeObject(testObject);
+        oos.flush();
+        oos.close();
+
+        FileInputStream fis = new FileInputStream("temp.out");
+        ObjectInputStream ois = new ObjectInputStream(fis);
+        TestObject deTest = (TestObject) ois.readObject();
+        System.out.println(deTest.testValue);
+        System.out.println(deTest.parentValue);
+        System.out.println(deTest.innerObject.innerValue);
+    }
+}
+
+class Parent implements Serializable {
+
+    private static final long serialVersionUID = -4963266899668807475L;
+
+    public int parentValue = 100;
+}
+
+class InnerObject implements Serializable {
+
+    private static final long serialVersionUID = 5704957411985783570L;
+
+    public int innerValue = 200;
+}
+
+class TestObject extends Parent implements Serializable {
+
+    private static final long serialVersionUID = -3186721026267206914L;
+
+    public int testValue = 300;
+
+    public InnerObject innerObject = new InnerObject();
+}
+```
+程序执行完用sublime打开temp.out文件，可以看到
+```java
+aced 0005 7372 0017 636f 6d2e 7373 732e
+7465 7374 2e54 6573 744f 626a 6563 74d3
+c67e 1c4f 132a fe02 0002 4900 0974 6573
+7456 616c 7565 4c00 0b69 6e6e 6572 4f62
+6a65 6374 7400 1a4c 636f 6d2f 7373 732f
+7465 7374 2f49 6e6e 6572 4f62 6a65 6374
+3b78 7200 1363 6f6d 2e73 7373 2e74 6573
+742e 5061 7265 6e74 bb1e ef0d 1fc9 50cd
+0200 0149 000b 7061 7265 6e74 5661 6c75
+6578 7000 0000 6400 0001 2c73 7200 1863
+6f6d 2e73 7373 2e74 6573 742e 496e 6e65
+724f 626a 6563 744f 2c14 8a40 24fb 1202
+0001 4900 0a69 6e6e 6572 5661 6c75 6578
+7000 0000 c8
+```
+# Why
+调用ObjectOutputStream.writeObject()和ObjectInputStream.readObject()之后究竟做了什么？temp.out文件中的二进制分别代表什么意思？
+## 1. ObjectStreamClass类
+
+方文档对这个类的介绍如下
+
+> Serialization’s descriptor for classes. It contains the name and serialVersionUID of the class. The ObjectStreamClass for a specific class loaded in this Java VM can be found/created using the lookup method.
+
+可以看到是类的序列化描述符，这个类可以描述需要被序列化的类的元数据，包括被序列化的类的名字以及序列号。可以通过lookup()方法来查找/创建在这个JVM中加载的特定的ObjectStreamClass对象。
+
+##2.序列化:writeObject()
+调用wroteObject()进行序列化之前会先调用ObjectOutputStream的构造函数生成一个ObjectOutputStream对象，构造函数如下:
+```java
+public ObjectOutputStream(OutputStream out) throws IOException {
+    verifySubclass();
+  // bout表示底层的字节数据容器
+  bout = new BlockDataOutputStream(out);
+  handles = new HandleTable(10, (float) 3.00);
+  subs = new ReplaceTable(10, (float) 3.00);
+  enableOverride = false;
+  writeStreamHeader(); // 写入文件头
+  bout.setBlockDataMode(true); // flush数据
+  if (extendedDebugInfo) {
+        debugInfoStack = new DebugTraceInfoStack();
+  } else {
+        debugInfoStack = null;
+  }
+}
+```
+构造函数中首先会把bout绑定到底层的字节数据容器，接着会调用writeStreamHeader()方法，该方法实现如下:
+```java
+protected void writeStreamHeader() throws IOException {
+    bout.writeShort(STREAM_MAGIC);
+    bout.writeShort(STREAM_VERSION);
+}
+```
+在writeStreamHeader()方法中首先会往底层字节容器中写入表示序列化的Magic Number以及版本号，定义为
+```java
+/**
+ * Magic number that is written to the stream header. 
+ */
+final static short STREAM_MAGIC = (short)0xaced;
+
+/**
+ * Version number that is written to the stream header. 
+ */
+final static short STREAM_VERSION = 5;
+```
+接下来会调用writeObject()方法进行序列化,实现如下:
+```java
+public final void writeObject(Object obj) throws IOException {
+    if (enableOverride) {
+        writeObjectOverride(obj);
+ return;  }
+    try {
+		// 调用writeObject0()方法序列化
+        writeObject0(obj, false);
+  } catch (IOException ex) {
+        if (depth == 0) {
+            writeFatalException(ex);
+  }
+        throw ex;
+  }
+}
+```
+正常情况下会调用writeObject0()进行序列化操作,该方法实现如下:
+```java
+  private void writeObject0(Object obj, boolean unshared)
+        throws IOException
+    {
+        boolean oldMode = bout.setBlockDataMode(false);
+        depth++;
+        try {
+            // handle previously written and non-replaceable objects
+            int h;
+            if ((obj = subs.lookup(obj)) == null) {
+                writeNull();
+                return;
+            } else if (!unshared && (h = handles.lookup(obj)) != -1) {
+                writeHandle(h);
+                return;
+            } else if (obj instanceof Class) {
+                writeClass((Class) obj, unshared);
+                return;
+            } else if (obj instanceof ObjectStreamClass) {
+                writeClassDesc((ObjectStreamClass) obj, unshared);
+                return;
+            }
+
+            // check for replacement object
+            Object orig = obj;
+           //  获取要序列化的对象的Class对象
+            Class<?> cl = obj.getClass();
+            ObjectStreamClass desc;
+            for (;;) {
+                // REMIND: skip this check for strings/arrays?
+                Class<?> repCl;
+                 // 创建描述cl的ObjectStreamClass对象
+                desc = ObjectStreamClass.lookup(cl, true);
+                if (!desc.hasWriteReplaceMethod() ||
+                    (obj = desc.invokeWriteReplace(obj)) == null ||
+                    (repCl = obj.getClass()) == cl)
+                {
+                    break;
+                }
+                cl = repCl;
+            }
+            if (enableReplace) {
+                Object rep = replaceObject(obj);
+                if (rep != obj && rep != null) {
+                    cl = rep.getClass();
+                    desc = ObjectStreamClass.lookup(cl, true);
+                }
+                obj = rep;
+            }
+
+            // if object replaced, run through original checks a second time
+            if (obj != orig) {
+                subs.assign(orig, obj);
+                if (obj == null) {
+                    writeNull();
+                    return;
+                } else if (!unshared && (h = handles.lookup(obj)) != -1) {
+                    writeHandle(h);
+                    return;
+                } else if (obj instanceof Class) {
+                    writeClass((Class) obj, unshared);
+                    return;
+                } else if (obj instanceof ObjectStreamClass) {
+                    writeClassDesc((ObjectStreamClass) obj, unshared);
+                    return;
+                }
+            }
+
+            // 根据实际的类型进行不同的写入操作
+            // remaining cases
+            if (obj instanceof String) {
+                writeString((String) obj, unshared);
+            } else if (cl.isArray()) {
+                writeArray(obj, desc, unshared);
+            } else if (obj instanceof Enum) {
+                writeEnum((Enum<?>) obj, desc, unshared);
+            } else if (obj instanceof Serializable) {
+                // 被序列化对象实现了Serializable接口
+                writeOrdinaryObject(obj, desc, unshared);
+            } else {
+                if (extendedDebugInfo) {
+                    throw new NotSerializableException(
+                        cl.getName() + "\n" + debugInfoStack.toString());
+                } else {
+                    throw new NotSerializableException(cl.getName());
+                }
+            }
+        } finally {
+            depth--;
+            bout.setBlockDataMode(oldMode);
+        }
+    }
+```
+从代码里面可以看到，程序会
+- 生成一个描述被序列化对象类的类元信息的ObjectStreamClass对象
+- 根据传入的需要序列化的对象的实际类型进行不同的序列化操作。从代码里面可以很明显的看到，
+   - 对于String类型、数组类型和Enum可以直接进行序列化
+   - 如果被序列化对象实现了Serializable对象，则会调用writeOrdinaryObject()方法进行序列化
+这里可以解释一个问题:Serializbale接口是个空的接口，并没有定义任何方法，为什么需要序列化的接口只要实现Serializbale接口就能够进行序列化。
+
+答案是:Serializable接口这是一个标识，告诉程序所有实现了”我”的对象都需要进行序列化。
+
+因此，序列化过程接下来会执行到writeOrdinaryObject()这个方法中，该方法实现如下:
+```java
+    private void writeOrdinaryObject(Object obj,
+                                     ObjectStreamClass desc,
+                                     boolean unshared)
+        throws IOException
+    {
+        if (extendedDebugInfo) {
+            debugInfoStack.push(
+                (depth == 1 ? "root " : "") + "object (class \"" +
+                obj.getClass().getName() + "\", " + obj.toString() + ")");
+        }
+        try {
+            desc.checkSerialize();
+
+            // 写入Object标志位
+            bout.writeByte(TC_OBJECT);
+            // 写入类元数据
+            writeClassDesc(desc, false);
+            handles.assign(unshared ? null : obj);
+            if (desc.isExternalizable() && !desc.isProxy()) {
+                writeExternalData((Externalizable) obj);  // 写入被序列化的对象的实例数据
+            } else {
+                writeSerialData(obj, desc);
+            }
+        } finally {
+            if (extendedDebugInfo) {
+                debugInfoStack.pop();
+            }
+        }
+    }
+```
+在这个方法中首先会往底层字节容器中写入TC_OBJECT，表示这是一个新的Object
+```java
+/**
+ * new Object.
+ */
+final static byte TC_OBJECT =       (byte)0x73;
+```
+接下来会调用writeClassDesc()方法写入被序列化对象的类的类元数据，writeClassDesc()方法实现如下:
+```java
+private void writeClassDesc(ObjectStreamClass desc, boolean unshared)
+    throws IOException
+{
+    int handle;
+    if (desc == null) {
+        // 如果desc为null
+        writeNull();
+    } else if (!unshared && (handle = handles.lookup(desc)) != -1) {
+        writeHandle(handle);
+    } else if (desc.isProxy()) {
+        writeProxyDesc(desc, unshared);
+    } else {
+        writeNonProxyDesc(desc, unshared);
+    }
+}
+```
+在这个方法中会先判断传入的desc是否为null，如果为null则调用writeNull()方法
+```java
+private void writeNull() throws IOException {
+    // TC_NULL =         (byte)0x70;
+    // 表示对一个Object引用的描述的结束
+    bout.writeByte(TC_NULL);
+}
+```
+如果不为null，则一般情况下接下来会调用writeNonProxyDesc()方法，该方法实现如下:
+```java
+private void writeNonProxyDesc(ObjectStreamClass desc, boolean unshared)
+    throws IOException
+{
+    // TC_CLASSDESC =    (byte)0x72;
+    // 表示一个新的Class描述符
+    bout.writeByte(TC_CLASSDESC);
+    handles.assign(unshared ? null : desc);
+ 
+    if (protocol == PROTOCOL_VERSION_1) {
+        // do not invoke class descriptor write hook with old protocol
+        desc.writeNonProxy(this);
+    } else {
+        writeClassDescriptor(desc);
+    }
+ 
+    Class cl = desc.forClass();
+    bout.setBlockDataMode(true);
+    if (cl != null && isCustomSubclass()) {
+        ReflectUtil.checkPackageAccess(cl);
+    }
+    annotateClass(cl);
+    bout.setBlockDataMode(false);
+    bout.writeByte(TC_ENDBLOCKDATA);
+ 
+    writeClassDesc(desc.getSuperDesc(), false);
+}
+```
+在这个方法中首先会写入一个字节的TC_CLASSDESC，这个字节表示接下来的数据是一个新的Class描述符，接着会调用writeNonProxy()方法写入实际的类元信息，writeNonProxy()实现如下:
+```java
+void writeNonProxy(ObjectOutputStream out) throws IOException {
+    out.writeUTF(name); // 写入类的名字
+    out.writeLong(getSerialVersionUID()); // 写入类的序列号
+ 
+    byte flags = 0;
+    // 获取类的标识
+    if (externalizable) {
+        flags |= ObjectStreamConstants.SC_EXTERNALIZABLE;
+        int protocol = out.getProtocolVersion();
+        if (protocol != ObjectStreamConstants.PROTOCOL_VERSION_1) {
+            flags |= ObjectStreamConstants.SC_BLOCK_DATA;
+        }
+    } else if (serializable) {
+        flags |= ObjectStreamConstants.SC_SERIALIZABLE;
+    }
+    if (hasWriteObjectData) {
+        flags |= ObjectStreamConstants.SC_WRITE_METHOD;
+    }
+    if (isEnum) {
+        flags |= ObjectStreamConstants.SC_ENUM;
+    }
+    out.writeByte(flags); // 写入类的flag
+ 
+    out.writeShort(fields.length); // 写入对象的字段的个数
+    for (int i = 0; i < fields.length; i++) {
+        ObjectStreamField f = fields[i];
+        out.writeByte(f.getTypeCode());
+        out.writeUTF(f.getName());
+        if (!f.isPrimitive()) {
+            // 如果不是原始类型，即是对象或者Interface
+            // 则会写入表示对象或者类的类型字符串
+            out.writeTypeString(f.getTypeString());
+        }
+    }
+}
+```
+writeNonProxy()方法中会按照以下几个过程来写入数据:
+- 1. 调用writeUTF()方法写入对象所属类的名字，对于本例中name = com.sss.test.对于writeUTF()这个方法，在写入实际的数据之前会先写入name的字节数，代码如下:
+```java
+void writeUTF(String s, long utflen) throws IOException {
+        if (utflen > 0xFFFFL) {
+            throw new UTFDataFormatException();
+        }
+        // 写入两个字节的s的长度
+        writeShort((int) utflen);
+        if (utflen == (long) s.length()) {
+            writeBytes(s);
+        } else {
+            writeUTFBody(s);
+        }
+    }
+```
+- 2. 接下来会调用writeLong()方法写入类的序列号UID,UID是通过getSerialVersionUID()方法来获取。
+- 3. 接着会判断被序列化的对象所属类的flag，并写入底层字节容器中(占用两个字节)。类的flag分为以下几类:
+    - final static byte SC_EXTERNALIZABLE = 0×04;表示该类为Externalizable类，即实现了Externalizable接口。
+    - final static byte SC_SERIALIZABLE = 0×02;表示该类实现了Serializable接口。
+    - final static byte SC_WRITE_METHOD = 0×01;表示该类实现了Serializable接口且自定义了writeObject()方法。
+    - final static byte SC_ENUM = 0×10;表示该类是个Enum类型。
+对于本例中flag = 0×02表示只是Serializable类型。
+- 4. 依次写入被序列化对象的字段的元数据。
+<1> 首先会写入被序列化对象的字段的个数，占用两个字节。本例中为2，因为TestObject类中只有两个字段，一个是int类型的testValue，一个是InnerObject类型的innerValue。
+<2> 依次写入每个字段的元数据。每个单独的字段由ObjectStreamField类来表示。
+
+1.写入字段的类型码，占一个字节。 类型码的映射关系如下
+![ 类型码的映射关系](http://upload-images.jianshu.io/upload_images/4685968-e7b2078da0bee13c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+2.调用writeUTF()方法写入每个字段的名字。注意，writeUTF()方法会先写入名字占用的字节数。
+3.如果被写入的字段不是基本类型，则会接着调用writeTypeString()方法写入代表对象或者类的类型字符串，该方法需要一个参数，表示对应的类或者接口的字符串，最终调用的还是writeString()方法，实现如下
+```java
+private void writeString(String str, boolean unshared) throws IOException {
+    handles.assign(unshared ? null : str);
+    long utflen = bout.getUTFLength(str);
+    if (utflen <= 0xFFFF) {
+        // final static byte TC_STRING = (byte)0x74;
+        // 表示接下来的字节表示一个字符串
+        bout.writeByte(TC_STRING);
+        bout.writeUTF(str, utflen);
+    } else {
+        bout.writeByte(TC_LONGSTRING);
+        bout.writeLongUTF(str, utflen);
+    }
+}
+```
+在这个方法中会先写入一个标志位TC_STRING表示接下来的数据是一个字符串，接着会调用writeUTF()写入字符串。
+
+执行完上面的过程之后，程序流程重新回到writeNonProxyDesc()方法中
+```java
+private void writeNonProxyDesc(ObjectStreamClass desc, boolean unshared)
+    throws IOException
+{
+    // 其他省略代码
+ 
+    // TC_ENDBLOCKDATA = (byte)0x78;
+    // 表示对一个object的描述块的结束
+    bout.writeByte(TC_ENDBLOCKDATA);
+ 
+    writeClassDesc(desc.getSuperDesc(), false); // 尾递归调用，写入父类的类元数据
+}
+```
+接下来会写入一个字节的标志位TC_ENDBLOCKDATA表示对一个object的描述块的结束。
+
+然后会调用writeClassDesc()方法，传入父类的ObjectStreamClass对象，写入父类的类元数据。
+
+需要注意的是writeClassDesc()这个方法是个递归调用，调用结束返回的条件是没有了父类，即传入的ObjectStreamClass对象为null，这个时候会写入一个字节的标识位TC_NULL.
+
+在递归调用完成写入类的类元数据之后，程序执行流程回到wriyeOrdinaryObject()方法中，
+```java
+private void writeOrdinaryObject(Object obj,
+                                 ObjectStreamClass desc,
+                                 boolean unshared) throws IOException
+{
+    // 其他省略代码
+    try {
+        desc.checkSerialize();
+        // 其他省略代码
+        if (desc.isExternalizable() && !desc.isProxy()) {
+            writeExternalData((Externalizable) obj);
+        } else {
+            writeSerialData(obj, desc); // 写入被序列化的对象的实例数据
+        }
+    } finally {
+        if (extendedDebugInfo) {
+            debugInfoStack.pop();
+        }
+    }
+}
+```
+从上面的分析中我们可以知道，当写入类的元数据的时候，是先写子类的类元数据，然后递归调用的写入父类的类元数据。
+
+接下来会调用writeSerialData()方法写入被序列化的对象的字段的数据，方法实现如下:
+```java
+private void writeSerialData(Object obj, ObjectStreamClass desc)
+    throws IOException
+{
+    // 获取表示被序列化对象的数据的布局的ClassDataSlot数组，父类在前
+    ObjectStreamClass.ClassDataSlot[] slots = desc.getClassDataLayout();
+    for (int i = 0; i < slots.length; i++) {
+        ObjectStreamClass slotDesc = slots[i].desc;
+        if (slotDesc.hasWriteObjectMethod()) {
+           // 如果被序列化对象自己实现了writeObject()方法，则执行if块里的代码
+ 
+           // 一些省略代码
+        } else {
+            // 调用默认的方法写入实例数据
+            defaultWriteFields(obj, slotDesc);
+        }
+    }
+}
+```
+在这个方法中首先会调用getClassDataSlot()方法获取被序列化对象的数据的布局，关于这个方法官方文档中说明如下：
+```java
+
+/**
+ * Returns array of ClassDataSlot instances representing the data layout
+ * (including superclass data) for serialized objects described by this
+ * class descriptor.  ClassDataSlots are ordered by inheritance with those
+ * containing "higher" superclasses appearing first.  The final
+ * ClassDataSlot contains a reference to this descriptor.
+ */
+ ClassDataSlot[] getClassDataLayout() throws InvalidClassException;
+```
+需要注意的是这个方法会把从父类继承的数据一并返回，并且表示从父类继承的数据的ClassDataSlot对象在数组的最前面。
+
+对于没有自定义writeObject()方法的对象来说，接下来会调用defaultWriteFields()方法写入数据，该方法实现如下:
+```java
+private void defaultWriteFields(Object obj, ObjectStreamClass desc)
+    throws IOException
+{
+    // 其他一些省略代码
+ 
+    int primDataSize = desc.getPrimDataSize();
+    if (primVals == null || primVals.length < primDataSize) {
+        primVals = new byte[primDataSize];
+    }
+    // 获取对应类中的基本数据类型的数据并保存在primVals字节数组中
+    desc.getPrimFieldValues(obj, primVals);
+    // 把基本数据类型的数据写入底层字节容器中
+    bout.write(primVals, 0, primDataSize, false);
+ 
+    // 获取对应类的所有的字段对象
+    ObjectStreamField[] fields = desc.getFields(false);
+    Object[] objVals = new Object[desc.getNumObjFields()];
+    int numPrimFields = fields.length - objVals.length;
+    // 把对应类的Object类型(非原始类型)的对象保存到objVals数组中
+    desc.getObjFieldValues(obj, objVals);
+    for (int i = 0; i < objVals.length; i++) {
+        // 一些省略的代码
+ 
+        try {
+            // 对所有Object类型的字段递归调用writeObject0()方法写入对应的数据
+            writeObject0(objVals[i],
+                         fields[numPrimFields + i].isUnshared());
+        } finally {
+            if (extendedDebugInfo) {
+                debugInfoStack.pop();
+            }
+        }
+    }
+}
+```
+可以看到，在这个方法中会做下面几件事情:
+
+<1> 获取对应类的基本类型的字段的数据，并写入到底层的字节容器中。
+<2> 获取对应类的Object类型(非基本类型)的字段成员，递归调用writeObject0()方法写入相应的数据。
+
+从上面对写入数据的分析可以知道，写入数据是是按照先父类后子类的顺序来写的。
+
+至此，Java序列化过程分析完毕，总结一下，在本例中序列化过程如下:
+
+![](http://upload-images.jianshu.io/upload_images/4685968-7826ad825f2ef569.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+现在可以来分析下第二步中写入的temp.out文件的内容了。
+```java
+aced        Stream Magic
+0005        序列化版本号
+73          标志位:TC_OBJECT,表示接下来是个新的Object
+72          标志位:TC_CLASSDESC,表示接下来是对Class的描述
+0020        类名的长度为32
+636f 6d2e 6265 6175 7479 626f 7373 2e73 com.beautyboss.s
+6c6f 6765 6e2e 5465 7374 4f62 6a65 6374 logen.TestObject
+d3c6 7e1c 4f13 2afe 序列号
+02          flag，可序列化
+00 02       TestObject的字段的个数，为2
+49          TypeCode，I，表示int类型
+0009        字段名长度，占9个字节
+7465 7374 5661 6c75 65      字段名:testValue
+4c          TypeCode:L,表示是个Class或者Interface
+000b        字段名长度，占11个字节
+696e 6e65 724f 626a 6563 74 字段名:innerObject
+74          标志位：TC_STRING，表示后面的数据是个字符串
+0023        类名长度，占35个字节
+4c63 6f6d 2f62 6561 7574 7962 6f73 732f  Lcom/beautyboss/
+736c 6f67 656e 2f49 6e6e 6572 4f62 6a65  slogen/InnerObje
+6374 3b                                  ct;
+78          标志位:TC_ENDBLOCKDATA,对象的数据块描述的结束
+```
+接下来开始写入数据,从父类Parent开始
+```java
+0000 0064 parentValue的值:100
+0000 012c testValue的值:300
+```
+接下来是写入InnerObject的类元信息
+```java
+73 标志位,TC_OBJECT:表示接下来是个新的Object
+72 标志位,TC_CLASSDESC：表示接下来是对Class的描述
+0021 类名的长度，为33
+636f 6d2e 6265 6175 7479 626f 7373 com.beautyboss
+2e73 6c6f 6765 6e2e 496e 6e65 724f .slogen.InnerO
+626a 6563 74 bject
+4f2c 148a 4024 fb12 序列号
+02 flag，表示可序列化
+0001 字段个数，1个
+49 TypeCode,I,表示int类型
+00 0a 字段名长度,10个字节
+69 6e6e 6572 5661 6c75 65 innerValue
+78 标志位:TC_ENDBLOCKDATA,对象的数据块描述的结束
+70 标志位:TC_NULL,Null object reference.
+0000 00c8 innervalue的值:200
+```
+##3. 反序列化:readObject()
+反序列化过程就是按照前面介绍的序列化算法来解析二进制数据。
+
+有一个需要注意的问题就是，如果子类实现了Serializable接口，但是父类没有实现Serializable接口，这个时候进行反序列化会发生什么情况？
+
+答：如果父类有默认构造函数的话，即使没有实现Serializable接口也不会有问题，反序列化的时候会调用默认构造函数进行初始化，否则的话反序列化的时候会抛出.InvalidClassException:异常，异常原因为no valid constructor。
+# Other
+## 1. static和transient字段不能被序列化。
+序列化的时候所有的数据都是来自于ObejctStreamClass对象，在生成ObjectStreamClass的构造函数中会调用fields = getSerialFields(cl);这句代码来获取需要被序列化的字段，getSerialFields()方法实际上是调用getDefaultSerialFields()方法的，getDefaultSerialFields()实现如下:
+```java
+private static ObjectStreamField[] getDefaultSerialFields(Class<?> cl) {
+    Field[] clFields = cl.getDeclaredFields();
+    ArrayList<ObjectStreamField> list = new ArrayList<>();
+    int mask = Modifier.STATIC | Modifier.TRANSIENT;
+ 
+    for (int i = 0; i < clFields.length; i++) {
+        if ((clFields[i].getModifiers() & mask) == 0) {
+            // 如果字段既不是static也不是transient的才会被加入到需要被序列化字段列表中去
+            list.add(new ObjectStreamField(clFields[i], false, true));
+        }
+    }
+    int size = list.size();
+    return (size == 0) ? NO_FIELDS :
+        list.toArray(new ObjectStreamField[size]);
+}
+```
+从上面的代码中可以很明显的看到，在计算需要被序列化的字段的时候会把被static和transient修饰的字段给过滤掉。
+
+在进行反序列化的时候会给默认值。
+##2. 如何实现自定义序列化和反序列化？
+只需要被序列化的对象所属的类定义了void writeObject(ObjectOutputStream oos)和void readObject(ObjectInputStream ois)方法即可，Java序列化和反序列化的时候会调用这两个方法，那么这个功能是怎么实现的呢？
+
+1. 在ObjectClassStream类的构造函数中有下面几行代码:
+```java
+cons = getSerializableConstructor(cl);
+writeObjectMethod = getPrivateMethod(cl, "writeObject",
+    new Class<?>[] { ObjectOutputStream.class },
+    Void.TYPE);
+readObjectMethod = getPrivateMethod(cl, "readObject",
+    new Class<?>[] { ObjectInputStream.class },
+    Void.TYPE);
+readObjectNoDataMethod = getPrivateMethod(
+    cl, "readObjectNoData", null, Void.TYPE);
+hasWriteObjectData = (writeObjectMethod != null);
+```
+
+```java
+cons = getSerializableConstructor(cl);
+writeObjectMethod = getPrivateMethod(cl, "writeObject",
+    new Class<?>[] { ObjectOutputStream.class },
+    Void.TYPE);
+readObjectMethod = getPrivateMethod(cl, "readObject",
+    new Class<?>[] { ObjectInputStream.class },
+    Void.TYPE);
+readObjectNoDataMethod = getPrivateMethod(
+    cl, "readObjectNoData", null, Void.TYPE);
+hasWriteObjectData = (writeObjectMethod != null);
+```
+
+```java
+cons = getSerializableConstructor(cl);
+writeObjectMethod = getPrivateMethod(cl, "writeObject",
+    new Class<?>[] { ObjectOutputStream.class },
+    Void.TYPE);
+readObjectMethod = getPrivateMethod(cl, "readObject",
+    new Class<?>[] { ObjectInputStream.class },
+    Void.TYPE);
+readObjectNoDataMethod = getPrivateMethod(
+    cl, "readObjectNoData", null, Void.TYPE);
+hasWriteObjectData = (writeObjectMethod != null);
+```
+getPrivateMethod()方法实现如下:
+```java
+private static Method getPrivateMethod(Class<?> cl, String name,
+                                   Class<?>[] argTypes,
+                                   Class<?> returnType)
+{
+    try {
+        Method meth = cl.getDeclaredMethod(name, argTypes);
+        meth.setAccessible(true);
+        int mods = meth.getModifiers();
+        return ((meth.getReturnType() == returnType) &&
+                ((mods & Modifier.STATIC) == 0) &&
+                ((mods & Modifier.PRIVATE) != 0)) ? meth : null;
+    } catch (NoSuchMethodException ex) {
+        return null;
+    }
+}
+```
+可以看到在ObejctStreamClass的构造函数中会查找被序列化类中有没有定义为void writeObject(ObjectOutputStream oos) 的函数，如果找到的话，则会把找到的方法赋值给writeObjectMethod这个变量，如果没有找到的话则为null。
+
+2. 在调用writeSerialData()方法写入序列化数据的时候有
+```java
+private void writeSerialData(Object obj, ObjectStreamClass desc)
+    throws IOException
+{
+    ObjectStreamClass.ClassDataSlot[] slots = desc.getClassDataLayout();
+    for (int i = 0; i < slots.length; i++) {
+        ObjectStreamClass slotDesc = slots[i].desc;
+        if (slotDesc.hasWriteObjectMethod()) {
+            // 其他一些省略代码
+            try {
+                curContext = new SerialCallbackContext(obj, slotDesc);
+                bout.setBlockDataMode(true);
+                // 在这里调用用户自定义的方法
+                slotDesc.invokeWriteObject(obj, this);
+                bout.setBlockDataMode(false);
+                bout.writeByte(TC_ENDBLOCKDATA);
+            } finally {
+                curContext.setUsed();
+                curContext = oldContext;
+                if (extendedDebugInfo) {
+                    debugInfoStack.pop();
+                }
+            }
+ 
+            curPut = oldPut;
+        } else {
+            defaultWriteFields(obj, slotDesc);
+        }
+    }
+}
+```
+首先会调用hasWriteObjectMethod()方法判断有没有自定义的writeObject(),代码如下
+```java
+boolean hasWriteObjectMethod() {
+    return (writeObjectMethod != null);
+}
+```
+hasWriteObjectMethod()这个方法仅仅是判断writeObjectMethod是不是等于null，而上面说了，如果用户自定义了void writeObject(ObjectOutputStream oos)这么个方法，则writeObjectMethod不为null，在if()代码块中会调用slotDesc.invokeWriteObject(obj, this);方法，该方法中会调用用户自定义的writeObject()方法。
+
+
+Java编程思想相关知识点
+
+当程序运行时，有关对象的信息就存储在了内存当中，但是当程序终止时，对象将不再继续存在。我们需要一种储存对象信息的方法，使我们的程序关闭之后他还继续存在，当我们再次打开程序时，可以轻易的还原当时的状态。这就是对象序列化的目的。 
+
+java的对象序列化将那些实现了Serializable接口的对象转换成一个字节序列，并且能够在以后将这个字节序列完全恢复为原来的对象，甚至可以通过网络传播。 这意味着序列化机制自动弥补了不同OS之间的差异.
+
+如此，java实现了“轻量级持久性”，为啥是轻量级，因为在java中我们还不能直接通过一个类似public这样的关键字直接使一个对象序列化，并让系统自动维护其他细节问题。因此我们只能在程序中显示地序列化与反序列化
+
+对象序列化的概念加入到语言中是为了支持两种主要特性：
+- java的远程方法调用（RMI），它使存活于其他计算机上的对象使用起来就像存活于本机上一样。当远程对象发送消息时，需要通过对象序列化来传输参数和返回值。
+- 对于Java Bean来说，对象序列化是必须的。使用一个Bean时，一般情况下是在设计阶段对它的状态信息进行配置。这种状态信息必须保存下来，并在程序启动的时候进行后期恢复，这种具体工作就是由对象序列化完成的。
+
+使用——对象实现Serializable接口（仅仅是一个标记接口，没有任何方法）。
+
+序列化一个对象：
+        1. 创建某些OutputStream对象
+        2. 将其封装在一个ObjectOutputStream对象内
+        3. 只需调用writeObject（）即可将对象序列化
+            注：也可以为一个String调用writeObject()；也可以用与DataOutputStream相同的方法写入所有基本数据类型（它们具有同样的接口）
+    
+反序列化
+   将一个InputStream封装在ObjectInputStream内，然后调用readObject()。最后获得的是一个引用，它指向一个向上转型的Object，所以必须向下转型才能直接设置它们
+
+对象序列化不仅保存了对象的“全景图”，而且能够追踪对象内所包含的所有引用，并保存这些对象；接着又能对对象内包含的每个这样的引用进行追踪；以此类推。这种情况有时被称为“对象网”。
+
+例子：
+    ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("worm.out");
+    out.writeObject(w);
+    out.close();
+    ObjectInputStream in = new ObjectInputStream(new FileInputStream("worm.out");
+    String s = (String)in.readObject();
+
+ 在对一个Serializable对象进行还原的过程中，没有调用任何构造器，包括默认的构造器。
+整个对象都是通过InputStream中取得数据恢复而来的。
+
+寻找类：必须保证java虚拟机能够找到相关的.class文件。找不到就会得到一个ClassNotFOundExcption的异常。
+
+序列化的控制——通过实现Externalizable接口——代替实现Serializable接口——来对序列化过程进行控制。
+    1. Externalizable接口继承了Serializable接口，增加了两个方法，writeExternal()和readExternal()，这两个方法会在序列化和反序列化还原的过程中被自动调用。
+    2. Externalizable对象，在还原的时候所有普通的默认构造器都会被调用（包括在字段定义时的初始化）(只有这样才能使Externalizable对象产生正确的行为)，然后调用readExternal().
+    3. 如果我们从一个Externalizable对象继承，通常需要调用基类版本的writeExternal()和readExternal()来为基类组件提供恰当的存储和恢复功能。
+    4. 为了正常运行，我们不仅需要在writeExternal()方法中将来自对象的重要信息写入，还必须在readExternal（）中恢复数据
+
+ 防止对象的敏感部分被序列化，两种方式：
+        1. 将类实现Externalizable，在writeExternal()内部只对所需部分进行显示的序列化
+        2. 实现Serializable，用transient(瞬时)关键字（只能和Serializable一起使用）逐个字段的关闭序列化，他的意思：不用麻烦你保存或恢复数据——我自己会处理。
+
+Externalizable的替代方法
+        1. 实现Serializable接口，并添加名为writeObject()和readObject()的方法，这样一旦对象被序列化或者被反序列化还原，就会自动的分别调用writeObject()和readObject()的方法（它们不是接口的一部分，接口的所有东西都是public的）。只要提供这两个方法，就会使用它们而不是默认的序列化机制。
+        2. 这两个方法必须具有准确的方法特征签名，但是这两个方法并不在这个类中的其他方法中调用，而是在ObjectOutputStream和ObjectInputStream对象的writeObject()和readObject()方法
+            [图片上传失败...(image-c92672-1517928660769)] 
+        3. 技巧：在你的writeObject()和readObject()内部调用defaultWriteObject()和defaultReadObject来选择执行默认的writeObject()和readObject()；如果打算使用默认机制写入对象的非transient部分，那么必须调用defaultwriteObject()和defaultReadObject()，且作为writeObject()和readObject()的第一个操作。
+
+使用“持久性”
+    1. 只要将任何对象序列化到单一流中，就可以恢复出与我们写出时一样的对象网，并且没有任何意外重复复制出的对象。当然，我们可以在写出第一个对象和写出最后一个对象期间改变这些对象的状态，但是这是我们自己的事；无论对象在被序列化时处于什么状态（无论它们和其他对象有什么样的连接关系），我们都可以被写出。
+    2. Class是Serializable的，因此只需要直接对Class对象序列化，就可以很容易的保存static字段，任何情况下，这都是一种明智的做法。但是必须自己动手去实现序列化static的值。
+        使用serializeStaticState()和deserializeStaticState()两个static方法，它们是作为存储和读取过程的一部分被显示的调用的
+    3. 安全问题：序列化会将private数据保存下来，对于你关心的安全问题，应将其标记为transient。但是这之后，你还必须设计一种安全的保存信息的方法，以便在执行恢复时可以复位那些private变量。
diff --git "a/Java/Java\345\274\200\345\217\221\344\272\272\345\221\230\345\277\205\345\244\207linux\345\221\275\344\273\244.md" "b/Java/Java\345\274\200\345\217\221\344\272\272\345\221\230\345\277\205\345\244\207linux\345\221\275\344\273\244.md"
new file mode 100644
index 0000000000..50d20a5002
--- /dev/null
+++ "b/Java/Java\345\274\200\345\217\221\344\272\272\345\221\230\345\277\205\345\244\207linux\345\221\275\344\273\244.md"
@@ -0,0 +1,758 @@
+管道符“|”将两个命令隔开，左边命令的输出作为右边命令的输入。连续使用管道意味着第一个命令的输出会作为 第二个命令的输入，第二个命令的输出又会作为第三个命令的输入，依此类推
+#1 文件管理
+## which
+ 用于查找文件
+会在环境变量$PATH设置的目录里查找符合条件的文件。
+### 语法
+```
+which [文件...]
+```
+### 参数：
+```
+-n<文件名长度> 　指定文件名长度，指定的长度必须大于或等于所有文件中最长的文件名。
+-p<文件名长度> 　与-n参数相同，但此处的<文件名长度>包括了文件的路径。
+-w 　指定输出时栏位的宽度。
+-V 　显示版本信息。
+```
+### 实例
+使用指令"which"查看指令"bash"的绝对路径，输入如下命令：
+![](https://upload-images.jianshu.io/upload_images/4685968-f799e89b19bd48b3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+上面的指令执行后，输出信息如下所示：
+![](https://upload-images.jianshu.io/upload_images/4685968-1f7df7394763eac3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+
+##cp
+复制文件或目录
+`cp [options] source dest`
+`cp [options] source... directory`
+-a：此选项通常在复制目录时使用，它保留链接、文件属性，并复制目录下的所有内容。其作用等于dpR参数组合。
+-d：复制时保留链接。这里所说的链接相当于Windows系统中的快捷方式。
+-f：覆盖已经存在的目标文件而不给出提示。
+-i：与-f选项相反，在覆盖目标文件之前给出提示，要求用户确认是否覆盖，回答"y"时目标文件将被覆盖。
+-p：除复制文件的内容外，还把修改时间和访问权限也复制到新文件中。
+-r：若给出的源文件是一个目录文件，此时将复制该目录下所有的子目录和文件
+-l：不复制文件，只是生成链接文件。
+使用指令"cp"将当前目录"test/"下的所有文件复制到新目录"newtest"下
+`$ cp –r test/ newtest     `
+## chmod 
+文件调用权限三级 : 文件拥有者、群组、其他
+利用 chmod 控制文件如何被他人所调用。
+- r 表示可读取
+- w 表示可写入
+- x 表示可执行
+- X 表示只有当该文件是个子目录或者该文件已经被设定过为可执行。
+
+chmod也可以用数字来表示权限如 :
+chmod abc file
+其中a,b,c各为一个数字，分别表示User、Group、及Other的权限。
+
+r=4，w=2，x=1
+若要rwx属性则4+2+1=7；
+若要rw-属性则4+2=6；
+若要r-x属性则4+1=5。
+将文件 file1.txt 设为所有人皆可读取 :
+```
+chmod ugo+r file1.txt
+将文件 file1.txt 设为所有人皆可读取 
+
+chmod a+r file1.txt
+将文件 file1.txt 与 file2.txt 设为该文件拥有者，与其所属同一个群体者可写入，但其他以外的人则不可写入 :
+
+chmod ug+w,o-w file1.txt file2.txt
+
+将 ex1.py 设定为只有该文件拥有者可以执行 
+chmod u+x ex1.py
+
+将目前目录下的所有文件与子目录皆设为任何人可读取 
+chmod -R a+r *
+此外chmod也可以用数字来表示权限如 :
+
+chmod 777 file
+语法为：
+
+chmod abc file
+其中a,b,c各为一个数字，分别表示User、Group、及Other的权限。
+
+r=4，w=2，x=1
+若要rwx属性则4+2+1=7；
+若要rw-属性则4+2=6；
+若要r-x属性则4+1=5。
+chmod a=rwx file
+和
+
+chmod 777 file
+效果相同
+
+chmod ug=rwx,o=x file
+和
+
+chmod 771 file
+```
+## cat
+功能:连接文件并打印到标准输出设备
+`cat [-AbeEnstTuv] [--help] [--version] fileName`
+-n 或 --number：由 1 开始对所有输出的行数编号
+-b 或 --number-nonblank：和 -n 相似，只不过对于空白行不编号
+
+实例：
+把 textfile1 的文档内容加上行号后输入 textfile2 这个文档里：
+`cat -n textfile1 > textfile2`
+
+把 textfile1 和 textfile2 的文档内容加上行号（空白行不加）之后将内容附加到 textfile3 文档里：
+`cat -b textfile1 textfile2 >> textfile3`
+
+清空 /etc/test.txt 文档内容：
+`cat /dev/null > /etc/test.txt`
+
+cat 也可以用来制作镜像文件。例如要制作软盘的镜像文件，将软盘放好后输入：
+`cat /dev/fd0 > OUTFILE`
+
+相反的，如果想把 image file 写到软盘，输入：
+`cat IMG_FILE > /dev/fd0`
+## more
+类似 `cat` ，不过会以一页一页的形式显示，更方便使用者逐页阅读，而最基本的指令就是按空白键（space）就往下一页显示，按 b 键就会往回（back）一页显示，而且还有搜寻字串的功能（与 vi 相似），使用中的说明文件，请按 h
+`more [-dlfpcsu] [-num] [+/pattern] [+linenum] [fileNames..] `
+### 参数
+-num 一次显示的行数
+-d 提示使用者，在画面下方显示 [Press space to continue, 'q' to quit.] ，如果使用者按错键，则会显示 [Press 'h' for instructions.] 而不是 '哔' 声
+-l 取消遇见特殊字元 ^L（送纸字元）时会暂停的功能
+-f 计算行数时，以实际上的行数，而非自动换行过后的行数（有些单行字数太长的会被扩展为两行或两行以上）
+-p 不以卷动的方式显示每一页，而是先清除萤幕后再显示内容
+-c 跟 -p 相似，不同的是先显示内容再清除其他旧资料
+-s 当遇到有连续两行以上的空白行，就代换为一行的空白行
+-u 不显示下引号 （根据环境变数 TERM 指定的 terminal 而有所不同）
++/pattern 在每个文档显示前搜寻该字串（pattern），然后从该字串之后开始显示
++num 从第 num 行开始显示
+fileNames 欲显示内容的文档，可为复数个数
+### 实例
+```
+逐页显示 testfile 文档内容，如有连续两行以上空白行则以一行空白行显示。
+more -s testfile
+
+从第 20 行开始显示 testfile 之文档内容。
+more +20 testfile
+```
+##tac
+从最后一行开始显示内容，并将所有内容输出 
+##head：只显示前几行 
+
+##tail
+查看文件的内容，有一个常用的参数 -f 常用于查阅正在改变的日志文件
+`tail -10 someFile`
+查看文件后 10 行内容
+`head -10 someFile`
+查看文件前 10 行内容
+`tail -f someFile`
+用于调试,实时查看文件内容,会把 filename 文件里的最尾部的内容显示在屏幕上，并且不断刷新，只要 filename 更新就可以看到最新的文件内容
+`tail [参数] [文件]  `
+```
+-f 循环读取
+-q 不显示处理信息
+-v 显示详细的处理信息
+-c<数目> 显示的字节数
+-n<行数> 显示行数
+--pid=PID 与-f合用,表示在进程ID,PID死掉之后结束.
+-q, --quiet, --silent 从不输出给出文件名的首部
+-s, --sleep-interval=S 与-f合用,表示在每次反复的间隔休眠S秒
+```
+###实例
+```
+要显示 notes.log 文件最后 10 行
+tail notes.log
+
+要跟踪名为 notes.log 的文件增长情况
+tail -f notes.log
+此命令显示 notes.log 文件最后 10 行
+当将某些行添加至 notes.log 文件时，tail 命令会继续显示这些行
+显示一直继续，直到您按下（Ctrl-C）组合键停止显示。
+
+显示文件 notes.log 的内容，从第 20 行至文件末尾:
+tail +20 notes.log
+
+显示文件 notes.log 的最后 10 个字符:
+tail -c 10 notes.log
+```
+##nl：和 cat 一样，只是 nl 要显示行号 
+## make 
+编译
+-j :指定作业数。
+
+
+##man rm （ rm --help ）
+查看帮助
+# 2 磁盘管理
+## pwd
+显示工作目录
+执行pwd指令可立刻得知您目前所在的工作目录的绝对路径名称。
+
+## cd
+切换当前工作目录至 dirName
+若目录名称省略，则变换 home 目录
+
+## mkdir
+建立名称为 dirName 子目录
+*   -p 确保目录名称存在，不存在的就建一个
+
+
+# 3 文档编辑
+## grep
+用于查找文件里符合条件的字符串。
+grep指令用于查找内容包含指定的范本样式的文件，如果发现某文件的内容符合所指定的范本样式，预设grep指令会把含有范本样式的那一列显示出来。若不指定任何文件名称，或是所给予的文件名为"-"，则grep指令会从标准输入设备读取数据。
+-r或--recursive 此参数的效果和指定"-d recurse"参数相同。
+-v或--revert-match 反转
+
+反向查找。前面各个例子是查找并打印出符合条件的行，通过"-v"参数可以打印出不符合条件行的内容。
+查找文件名中包含 test 的文件中不包含test 的行，此时，使用的命令为：
+`grep -v test *test*`
+# 4 系统管理
+## groupadd
+创建一个新的工作组，新工作组的信息将被添加到系统文件中
+- 语法
+groupadd(选项)(参数)
+```
+g：指定新建工作组的[id](http://man.linuxde.net/id "id命令")；
+-r：创建系统工作组，系统工作组的组ID小于500；
+-K：覆盖配置文件“/ect/[login](http://man.linuxde.net/login "login命令").defs”；
+-o：允许添加组ID号不唯一的工作组。</pre>
+```
+- 参数
+组名：指定新建工作组的组名
+- 实例
+建立一个新组，并设置组ID加入系统
+```
+groupadd -g 344 linuxde
+```
+此时在/etc/passwd文件中产生一个组ID（GID）是344的项目
+
+
+## ps 
+显示当前进程 (process) 的状态
+-  -A 显示进程信息
+![](https://upload-images.jianshu.io/upload_images/4685968-512aff1e593d1599.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+-  -u user  显示指定用户信息
+![](https://upload-images.jianshu.io/upload_images/4685968-7c7a71f3b9dfb4b3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- -ef  显示所有命令，连带命令行
+![](https://upload-images.jianshu.io/upload_images/4685968-e3ae42585f4e4276.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- pstree |grep java
+查看进程树
+![](https://upload-images.jianshu.io/upload_images/4685968-bd8146a54c354da0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+
+## rpm -aq|grep php
+查看安装介质
+
+
+## ls
+显示指定工作目录下之内容（列出目前工作目录所含之文件及子目录)。
+` ls [-alrtAFR] [name...]`
+```
+-a 显示所有文件及目录 (ls内定将文件名或目录名称开头为"."的视为隐藏档，不会列出)
+-h 用"K","M","G"来显示文件和目录的大小。
+-l 除文件名称外，亦将文件型态、权限、拥有者、文件大小等资讯详细列出 = ll
+-r 将文件以相反次序显示(原定依英文字母次序)
+-t 将文件依建立时间之先后次序列出
+-A 同 -a ，但不列出 "." (目前目录) 及 ".." (父目录)
+-F 在列出的文件名称后加一符号；例如可执行档则加 "*", 目录则加 "/"
+-R 若目录下有文件，则以下之文件亦皆依序列出
+```
+列出根目录(\)下的所有目录：
+```
+# ls /
+bin               dev   lib         media  net   root     srv  upload  www
+boot              etc   lib64       misc   opt   sbin     sys  usr
+home  lost+found  mnt    proc  selinux  tmp  var
+```
+列出目前工作目录下所有名称是 s 开头的文件，越新的排越后面 :
+`ls -ltr s*`
+将 /bin 目录以下所有目录及文件详细资料列出 :
+`ls -lR /bin`
+列出目前工作目录下所有文件及目录；目录于名称后加 "/", 可执行档于名称后加 "*" :
+`ls -AF`
+
+
+find / -name libNativeMethod.so
+等同 ll |grep someFile
+
+#grep someText *
+在当前目录所有文本中查找
+
+#ifconfig
+IP 地址配置，可以使用 setup 命令启动字符界面来配置
+
+#env
+环境配置，相当 window 下 set
+
+env |grep PATH
+查看环境变量
+
+#export
+相当于 set classpath
+
+#echo
+输出变量名
+
+#netstat -npl
+查看端口
+
+#lsof -i :22
+查看端口进程
+
+#cp from to
+拷贝文件
+
+cp -fr ./j2sdk1.4.2_04 /usr/java
+拷贝目录
+
+
+
+# mv
+用来为文件或目录改名、或将文件或目录移入其它位置。
+## 语法
+`mv [options] source dest`
+`mv [options] source... directory`
+参数说明：
+- -i: 若指定目录已有同名文件，则先询问是否覆盖旧文件;
+- -f: 在mv操作要覆盖某已有的目标文件时不给任何指示;
+## mv参数设置与运行结果
+mv 文件名 文件名	:将源文件名改为目标文件名
+mv 文件名 目录名	:将文件移动到目标目录
+mv 目录名 目录名	:目标目录已存在，将源目录移动到目标目录；目标目录不存在则改名
+mv 目录名 文件名	:出错
+## 实例
+将文件 aaa 更名为 bbb :
+`mv aaa bbb`
+将info目录放入logs目录中。注意，如果logs目录不存在，则该命令将info改名为logs。
+`mv info/ logs `
+再如将/usr/student下的所有文件和目录移到当前目录下，命令行为：
+`$ mv /usr/student/*  . `
+
+#rm -r
+递归删除， -f 表示 force
+
+>somefile
+清空文件内容
+
+which java
+查看 java 进程对应的目录
+
+#who
+显示当前用户
+
+#users
+显示当前会话
+
+#zip -r filename.zip filesdir
+某个文件夹打 zip 包
+
+#unzip somefile.zip
+解压 zip 文档到当前目录
+
+gunzip somefile.cpio.gz
+解压 .gz
+
+cpio -idmv < somefile.cpio
+CPIO 操作
+
+ps auxwww|sort -n -r -k 5|head -5
+按资源占用情况来排序，第一个 5 表示第几列，第二个 5 表示前几位
+
+hostname -i
+显示本机机器名，添加 i ，显示 etc/hosts 对应 ip 地址
+
+rpm -ivh some.rpm
+安装软件
+
+rpm -Uvh some.rpm
+更新软件
+
+rpm -qa |grep somesoftName
+是否已安装某软件
+# 5 备份压缩
+## tar 
+备份文件 
+是用来建立，还原备份文件的工具程序，它可以加入，解开备份文件内的文件。
+##参数：
+-f<备份文件>或--file=<备份文件> 指定备份文件。
+-v或--verbose 显示指令执行过程。
+-x或--extract或--get 从备份文件中还原文件。
+-z或--gzip或--ungzip 通过gzip指令处理备份文件。
+###实例
+压缩文件 非打包
+```java
+# touch a.c       
+# tar -czvf test.tar.gz a.c   //压缩 a.c文件为test.tar.gz
+a.c
+```
+列出压缩文件内容
+```java
+# tar -tzvf test.tar.gz 
+-rw-r--r-- root/root     0 2010-05-24 16:51:59 a.c
+```
+解压文件
+tar -xzvf test.tar.gz a.c
+打包
+tar –cvzf somefile.tar.gz fileDir
+
+
+#shutdown -i6 -y 0
+立即重启服务器
+
+#reboot
+立即重启服务器，相当于 shutdow –r now
+
+#halt
+
+立即关机， shutdown -h
+
+shutdonw -r 23:30
+
+shutdown -r +15
+
+shutdonw -r +30
+
+定时重启
+
+gdmsetup
+
+启动系统配置管理界面，需要在图形界面执行
+
+setup
+
+启动文字配置管理界面
+
+vi /etc/sysconfig/network
+
+修改机器名 , 然后要重启机器或者 service network restart
+
+#locale
+显示系统语言
+
+export LANG=zh_CN.GBK
+
+设定系统语言，解决 consol 中文乱码
+
+ln -s src_full_file the_link_name
+
+创建软链接
+
+last
+
+倒序查看已登陆用户历史
+
+history
+
+查看历史命令
+
+
+
+date -s 10/09/2009
+
+修改日期
+
+date -s 13:24:00
+
+修改时间，直接 date 显示时间
+
+df -k
+
+查看文件磁盘空间
+
+df -v
+
+查看文件空间
+
+du
+
+查看磁盘空间使用情况
+
+#free
+
+查看内存使用情况
+# 6 系统管理
+## top
+实时显示 process 的动态
+d : 改变显示的更新速度，或是在交谈式指令列( interactive command)按 s
+q : 没有任何延迟的显示速度，如果使用者是有 superuser 的权限，则 top 将会以最高的优先序执行
+c : 切换显示模式，共有两种模式，一是只显示执行档的名称，另一种是显示完整的路径与名称S : 累积模式，会将己完成或消失的子行程 ( dead child process ) 的 CPU time 累积起来
+s : 安全模式，将交谈式指令取消, 避免潜在的危机
+i : 不显示任何闲置 (idle) 或无用 (zombie) 的行程
+n : 更新的次数，完成后将会退出 top
+b : 批次档模式，搭配 "n" 参数一起使用，可以用来将 top 的结果输出到档案内
+显示进程信息
+
+# top
+显示完整命令
+# top -c
+以批处理模式显示程序信息
+
+# top -b
+以累积模式显示程序信息
+
+# top -S
+设置信息更新次数
+
+top -n 2
+
+//表示更新两次后终止更新显示
+设置信息更新时间
+
+# top -d 3
+
+//表示更新周期为3秒
+显示指定的进程信息
+
+# top -p 139
+
+//显示进程号为139的进程信息，CPU、内存占用率等
+显示更新十次后退出
+
+top -n 10
+使用者将不能利用交谈式指令来对行程下命令
+
+top -s
+将更新显示二次的结果输入到名称为 top.log 的档案里
+
+top -n 2 -b < top.log
+vmstat 5 10
+
+没 5 秒刷新一次，刷新 10 次； time 、 timex 、 uptime 、 iostat 、 sar
+
+cat /proc/cpuinfo|grep processor|wc – l
+
+获取 cpu 个数
+## service 
+service <service>
+打印指定服务<service>的命令行使用帮助。
+service <service> start
+启动指定的系统服务<service>
+service <service> stop
+停止指定的系统服务<service>
+service <service> restart
+重新启动指定的系统服务<service>，即先停止（stop），然后再启动（start）。
+chkconfig --list
+查看系统服务列表，以及每个服务的运行级别。
+chkconfig <service> on
+设置指定服务<service>开机时自动启动。
+chkconfig <service> off
+设置指定服务<service>开机时不自动启动。
+
+ntsysv
+
+以全屏幕文本界面设置服务开机时是否自动启动。
+service mysqld start
+
+启动 mysql 服务，其他如
+
+service mysqld stop
+
+停止 mysql 服务
+
+serice mysqld status
+
+显示 mysql 服务状态
+
+service –status-al
+查看已有服务
+
+# Systemd 
+设计目标是，为系统的启动和管理提供一套完整的解决方案。
+根据 Linux 惯例，字母d是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就是它要守护整个系统。
+Systemd 并不是一个命令，而是一组命令，涉及到系统管理的方方面面。
+## systemctl
+是 Systemd 的主命令，用于管理系统。
+Systemd 可以管理所有系统资源。不同的资源统称为 Unit（单位）。
+Unit 一共分成12种。
+
+Service unit：系统服务
+Target unit：多个 Unit 构成的一个组
+Device Unit：硬件设备
+Mount Unit：文件系统的挂载点
+Automount Unit：自动挂载点
+Path Unit：文件或路径
+Scope Unit：不是由 Systemd 启动的外部进程
+Slice Unit：进程组
+Snapshot Unit：Systemd 快照，可以切回某个快照
+Socket Unit：进程间通信的 socket
+Swap Unit：swap 文件
+Timer Unit：定时器
+
+systemctl list-units命令可以查看当前系统的所有 Unit 。
+
+netstat -nap | grep port
+
+# yum（ Yellow dog Updater, Modified）
+是一个在Fedora和RedHat以及SUSE中的Shell前端软件包管理器。
+
+基于RPM包管理，能够从指定的服务器自动下载RPM包并且安装，可以自动处理依赖性关系，并且一次安装所有依赖的软体包，无须繁琐地一次次下载、安装。
+
+yum提供了查找、安装、删除某一个、一组甚至全部软件包的命令，而且命令简洁而又好记。
+##语法
+```java
+yum [options] [command] [package ...]
+```
+- options：可选，选项包括
+  - -h（帮助）
+  - -y当安装过程提示选择全部为"yes"
+  - -q（不显示安装的过程）等等。
+- command：要进行的操作。
+- package操作的对象。
+##常用命令 
+1.列出所有可更新的软件清单命令：yum check-update
+2.更新所有软件命令：yum update
+3.仅安装指定的软件命令：yum install <package_name>
+4.仅更新指定的软件命令：yum update <package_name>
+5.列出所有可安裝的软件清单命令：yum list
+6.删除软件包命令：yum remove <package_name>
+7.查找软件包 命令：yum search <keyword>
+8.清除缓存命令:
+yum clean packages: 清除缓存目录下的软件包
+yum clean headers: 清除缓存目录下的 headers
+yum clean oldheaders: 清除缓存目录下旧的 headers
+yum clean, yum clean all (= yum clean packages; yum clean oldheaders) :清除缓存目录下的软件包及旧的headers
+
+#rpm (redhat package manager)
+用于管理套件。
+原本是 Red Hat Linux 发行版专门用来管理 Linux 各项套件的程序，由于它遵循 GPL 规则且功能强大方便，因而广受欢迎。逐渐受到其他发行版的采用。RPM 套件管理方式的出现，让 Linux 易于安装，升级，间接提升了 Linux 的适用度。
+##参数说明：
+-a 　查询所有套件
+-q 　使用询问模式，当遇到任何问题时，rpm指令会先询问用户
+## chkconfig
+检查，设置系统的各种服务。
+查询操作系统在每一个执行等级中会执行哪些系统服务
+```java
+chkconfig [--add][--del][--list][系统服务] 或 chkconfig [--level <等级代号>][系统服务][on/off/reset]
+```
+##参数：
+```java
+--add 　增加所指定的系统服务，让chkconfig指令得以管理它，并同时在系统启动的叙述文件内增加相关数据。
+--del 　删除所指定的系统服务，不再由chkconfig指令管理，并同时在系统启动的叙述文件内删除相关数据。
+--level<等级代号> 　指定读系统服务要在哪一个执行等级中开启或关毕。
+```
+```java
+列出chkconfig所知道的所有命令。
+# chkconfig -list 
+```
+```java
+开启服务。
+# chkconfig telnet/mysqld on //开启Telnet/mysql服务
+# chkconfig -list //列出chkconfig所知道的所有的服务的情况
+```
+```java
+关闭服务
+# chkconfig telnet off  //关闭Telnet服务
+# chkconfig -list //列出chkconfig所知道的所有的服务的情况
+```
+# Ctrl命令
+##Ctrl C
+ kill foreground process 
+发送 SIGINT 信号给前台进程组中的所有进程，强制终止程序的执行
+##Ctrl  Z
+  suspend foreground process 
+ 发送 SIGTSTP 信号给前台进程组中的所有进程，常用于挂起一个进程，而并非结束进程，用户可以使用使用fg/bg操作恢复执行前台或后台的进程。fg命令在前台恢复执行被挂起的进 程，此时可以使用ctrl-z再次挂起该进程，bg命令在后台恢复执行被挂起的进程，而此时将无法使用ctrl-z 再次挂起该进程；一个比较常用的功能：
+正在使用vi编辑一个文件时，需要执行shell命令查询一些需要的信息，可以使用ctrl-z挂起vi，等执行                   完shell命令后再使用fg恢复vi继续编辑你的文件（当然，也可以在vi中使用！command方式执行shell命令, 但是没有该方法方便）。
+
+##ctrl-d:
+Terminate input, or exit shell 
+一个特殊的二进制值，表示 EOF，作用相当于在终端中输入exit后回车
+##ctrl-/    
+发送 SIGQUIT 信号给前台进程组中的所有进程，终止前台进程并生成 core 文件
+
+##ctrl-s   
+中断控制台输出
+
+##ctrl-q   
+恢复控制台输出
+
+##ctrl-l    
+清屏
+
+
+
+其实，控制字符都是可以通过stty命令更改的，可在终端中输入命令"stty -a"查看终端配置
+![](http://upload-images.jianshu.io/upload_images/4685968-e43eb0501196bbea.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+## kill 
+kill  PID
+杀掉某进程
+kill -9 PID
+此命令将信号 9（SIGKILL 信号）发送到有效用户拥有的所有进程，即使是那些在其他工作站上启动以及属于其他进程组的进程也是如此。如果一个您请求的列表正被打印，它也被停止。
+##source
+也称为“点命令”，也就是一个点符号（.）
+常用于重新执行刚修改的初始化文件，使之立即生效，而不必注销并重新登录。
+```shell
+source filename 或 . filename
+```
+source命令除了上述的用途之外，还有一个另外一个用途。在对编译系统核心时常常需要输入一长串的命令，如：
+```shell
+make mrproper
+make menuconfig
+make dep
+make clean
+make bzImage
+…………
+```
+如果把这些命令做成一个文件，让它自动顺序执行，对于需要多次反复编译系统核心的用户来说会很方便，而用source命令就可以做到这一点，它的作用就是把一个文件的内容当成shell来执行，
+先在linux的源代码目录下（如/usr/src/linux-2.4.20）建立一个文件，如make_command，在其中输入一下内容：
+```shell
+make mrproper &&
+make menuconfig &&
+make dep &&
+make clean &&
+make bzImage &&
+make modules &&
+make modules_install &&
+cp arch/i386/boot/bzImage /boot/vmlinuz_new &&
+cp System.map /boot &&
+vi /etc/lilo.conf &&
+lilo -v
+```
+文件建立好之后，每次编译核心的时候，只需要在/usr/src/linux-2.4.20下输入：
+`source make_command`
+即可，如果你用的不是lilo来引导系统，可以把最后两行去掉，配置自己的引导程序来引导内核。
+顺便补充一点，&&命令表示顺序执行由它连接的命令，但是只有它之前的命令成功执行完成了之后才可以继续执行它后面的命令。
+##问题：linux下有些工具安装之后，除了要修改root下的.bashfile(也就是添加个环境变量) ，还要修改etc/profile 下的环境变量 ， 两个profile是干什么用的？区别？
+
+解答：
+- /etc/profile ：这个文件是每个用户登录时都会运行的环境变量设置，属于系统级别的环境变量，设置在里 面的东西对所有用户适用
+- .bashfile 是单用户登录时比如root会运行的,只对当前用户适用，而且只有在你使用的也是bash作为shell时才行. rpm是red hat,fedora,centos这几个发行版使用的安装包,和其它tar.gz的区别是有个文件头,多了一些信息。 rpm包多数是二进制文件,可以直接运行的,但tar.gz包很多是源代码,要编译后才能运行。 二进制文件和windows下的exe文件一个意思,可以直接运行。
+##whereis
+只能用于程序名的搜索，而且只搜索二进制文件（参数-b）、man说明文件（参数-m）和源代码文件（参数-s）。如果省略参数，则返回所有信息。
+
+##fuser
+查询文件、目录、socket端口和文件系统的使用进程
+###1.查询文件和目录使用者
+fuser最基本的用法是查询某个文件或目录被哪个进程使用：
+```java
+# fuser -v ./ 
+                     USER        PID ACCESS COMMAND
+./:                  dailidong  17108 ..c.. bash
+                     root      25559 ..c.. sudo
+                     root      26772 ..c.. bash
+```
+ ###2.查询端口使用者
+```java
+# fuser -vn tcp 3306
+
+                            USER        PID ACCESS COMMAND
+3306/tcp:            mysql      2535 F.... mysqld
+```
+#在 vim 命令模式
+:noh  取消/ sth 的搜索结果高亮特效
+## ip
+查看本机的 IP 地址
+```
+ip addr show  
+```
+![结果](https://upload-images.jianshu.io/upload_images/4685968-3e2b6e161f3fd27c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 软件包管理器
+apt-get是Debian、Ubuntu、Linux Mint、elementary OS等Linux发行版的默认软件包管理器
+apt-get purge packagename 等同于 apt-get remove packagename --purge
+## apt-get remove 
+只删除软件包，不删除配置文件
+##apt-get purge 
+删除软件包并删除配置文件
+
+配置文件只包括/etc目录中的软件服务使用的配置信息，不包括home目录中的
diff --git "a/Java/Java\345\274\202\345\270\270\344\271\213IllegalMonitorStateException.md" "b/Java/Java\345\274\202\345\270\270\344\271\213IllegalMonitorStateException.md"
new file mode 100644
index 0000000000..c96d2fe7e2
--- /dev/null
+++ "b/Java/Java\345\274\202\345\270\270\344\271\213IllegalMonitorStateException.md"
@@ -0,0 +1,48 @@
+# JavaDoc
+Thrown to indicate that a thread has attempted to wait on an object's monitor or to notify other threads waiting on an object's monitor without owning the specified monitor.
+其实意思就是说,也就是当前的线程不是此对象监视器的所有者。也就是要在当前线程锁定对象，才能用锁定的对象此行这些方法，需要用到synchronized ，锁定什么对象就用什么对象来执行  notify(), notifyAll(),wait(), wait(long), wait(long, int)操作，否则就会报IllegalMonitorStateException
+
+A thread becomes the owner of the object's monitor in one of three ways:
+1\. By executing a synchronized instance method of that object.
+2\. By executing the body of a synchronized statement that synchronizes on the object.
+3\. For objects of type Class, by executing a synchronized static method of that class. 
+通过以下三种方法之一，线程可以成为此对象监视器的所有者：
+
+*   执行此对象的同步 (Sychronized) 实例方法
+*   执行在此对象上进行同步的 synchronized 语句的正文
+*   对于 Class 类型的对象，执行该类的同步静态方法
+
+也就是在说,就是需要在调用wait()或者notify()之前，必须使用synchronized语义绑定住被wait/notify的对象。
+
+# 解决方法:
+通过实现加锁的方式实现线程同步时产生的并发问题
+## 1 锁定方法所属的实例对象
+```
+public synchronized void method（）{
+    //然后就可以调用：this.notify()...
+    //或者直接调用notify()...
+}
+```
+## 2 锁定方法所属的实例的Class
+```
+public Class Test{
+ public static synchronized void method（）{
+    //然后调用：Test.class.notify()...
+ }
+}
+```
+## 3 锁定其他对象
+```
+public Class Test{
+public Object lock = new Object();
+ public static void method（）{
+    synchronized (lock) {
+     //需要调用 lock.notify();
+    } 
+ }
+}
+```
+# 总结
+线程操作的wait()、notify()、notifyAll()只能在同步控制方法或同步控制块内调用
+如果在非同步控制方法或控制块里调用，程序能通过编译，但运行的时候，将得到  IllegalMonitorStateException 异常，并伴随着一些含糊信息，比如 ‘当前线程不是拥有者’。
+其实异常的含义是 调用wait()、notify()、notifyAll()的任务在调用这些方法前必须 ‘拥有’（获取）对象的锁。”
diff --git "a/Java/Java\346\200\247\350\203\275\350\260\203\344\274\230\345\267\245\345\205\267\344\271\213JDK\345\221\275\344\273\244\350\241\214.md" "b/Java/Java\346\200\247\350\203\275\350\260\203\344\274\230\345\267\245\345\205\267\344\271\213JDK\345\221\275\344\273\244\350\241\214.md"
new file mode 100644
index 0000000000..d0b58f6995
--- /dev/null
+++ "b/Java/Java\346\200\247\350\203\275\350\260\203\344\274\230\345\267\245\345\205\267\344\271\213JDK\345\221\275\344\273\244\350\241\214.md"
@@ -0,0 +1,91 @@
+##1.1 jps
+类似Linux的ps,但是jps只用于列出Java的进程
+可以方便查看Java进程的启动类,传入参数和JVM参数等
+直接运行,不加参数,列出Java程序的进程ID以及Main函数等名称
+![jps命令本质也是Java程序](https://upload-images.jianshu.io/upload_images/4685968-9c2189ded9cbd53e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![-m 输出传递给Java进程的参数](https://upload-images.jianshu.io/upload_images/4685968-15d03dbd5f802109.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![-l 输出主函数的完整路径](https://upload-images.jianshu.io/upload_images/4685968-bd8f57565d346543.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![-q 只输出进程ID](https://upload-images.jianshu.io/upload_images/4685968-e388ace92f303daf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![-v 显示传递给jvm的参数](https://upload-images.jianshu.io/upload_images/4685968-9a3bab93f94ce6c8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##1.2 jstat
+用于观察Java应用程序运行时信息的工具,详细查看堆使用情况以及GC情况
+![jstat -options](https://upload-images.jianshu.io/upload_images/4685968-fbc855e949719c77.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 1.2.1 jstat -class pid
+显示加载class的数量及所占空间等信息
+![-compiler -t:显示JIT编译的信息](https://upload-images.jianshu.io/upload_images/4685968-723f9f0823227204.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 1.2.2 -gc pid
+可以显示gc的信息，查看gc的次数及时间
+![](https://upload-images.jianshu.io/upload_images/4685968-6b81e96c9ce4a122.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 1.2.3 -gccapacity
+比-gc多了各个代的最大值和最小值
+![jstat -gccapacity 3661](https://upload-images.jianshu.io/upload_images/4685968-8f0c0568a833c939.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-b5dec1ef483c3985.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### -gccause
+最近一次GC统计和原因
+![](https://upload-images.jianshu.io/upload_images/4685968-19e7194758e4b938.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- LGCC:上次GC原因
+- GCC:当前GC原因
+![ -gcnew pid:new对象的信息。](https://upload-images.jianshu.io/upload_images/4685968-30740d4582274fde.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-e8e917f5b46b831c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### jstat -gcnewcapacity pid:new对象的信息及其占用量
+![](https://upload-images.jianshu.io/upload_images/4685968-5d42263a5cfb4520.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![-gcold 显示老年代和永久代信息](https://upload-images.jianshu.io/upload_images/4685968-27925ae2707ab9cc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ddc55146d27ff8d8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![-gcoldcapacity展现老年代的容量信息](https://upload-images.jianshu.io/upload_images/4685968-7468e008a50dc204.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-049dcf0ac4d634b6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### -gcutil
+显示GC回收相关信息
+![](https://upload-images.jianshu.io/upload_images/4685968-3abed42f97b9ffc4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-f906ce1ad06007a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### -printcompilation
+当前VM执行的信息
+![jstat -printcompilation 3661](https://upload-images.jianshu.io/upload_images/4685968-c13976c3f1895bab.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 还可以同时加两个数
+![输出进程4798的ClassLoader信息,每1秒统计一次,共输出2次](https://upload-images.jianshu.io/upload_images/4685968-0c2724b93209e8f2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##1.3 jinfo
+`jinfo <option> <pid>`
+查看正在运行的Java程序的扩展参数，甚至在运行时修改部分参数
+## 查看运行时参数
+```
+jinfo -flag MaxTenuringThreshold 31518
+-XX:MaxTenuringThreshold=15
+```
+## 在运行时修改参数值
+```
+> jinfo -flag PrintGCDetails 31518
+-XX:-PrintGCDetails
+
+> jinfo -flag +PrintGCDetails 31518
+
+> jinfo -flag PrintGCDetails 31518
+
+-XX:+PrintGCDetails
+
+```
+
+##1.4 jmap
+生成堆快照和对象的统计信息
+![-histo 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量. ](https://upload-images.jianshu.io/upload_images/4685968-501d6e1e20b11199.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![-dump:[live,]format=b,file=<filename> 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件. ](https://upload-images.jianshu.io/upload_images/4685968-9ac52bcbe63fcf42.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+获得堆快照文件之后，我们可以使用多种工具对文件进行分析，例如jhat，visual vm等。
+##1.5 jhat
+分析Java应用程序的堆快照文件,以前面生成的为例
+![jhat heap.hprof ](https://upload-images.jianshu.io/upload_images/4685968-320b7bd7678802b9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+jhat在分析完成之后，使用HTTP服务器展示其分析结果，在浏览器中访问[http://127.0.0.1:7000/](https://link.jianshu.com?t=http://127.0.0.1:7000/)即可得到分析结果。
+![](https://upload-images.jianshu.io/upload_images/4685968-b6d3d5c6926e2192.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##1.6b jstack
+导出Java应用程序的线程堆栈
+`jstack -l <pid>`
+
+
+jstack可以检测死锁，下例通过一个简单例子演示jstack检测死锁的功能。java代码如下：
+![](https://upload-images.jianshu.io/upload_images/4685968-b78a85d4c8c4c6c1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![使用jps命令查看进程号为11468，然后使用jstack -l 11468 > a.txt命令把堆栈信息打印到文件中](https://upload-images.jianshu.io/upload_images/4685968-c3dcf0188b245441.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-54afe14f306cd956.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+从这个输出可以知道：
+1、在输出的最后一段，有明确的"Found one Java-level deadlock"输出，所以通过jstack命令我们可以检测死锁
+2、输出中包含了所有线程，除了我们的north,sorth线程外，还有"Attach Listener", "C2 CompilerThread0", "C2 CompilerThread1"等等；
+3、每个线程下面都会输出当前状态，以及这个线程当前持有锁以及等待锁，当持有与等待造成循环等待时，将导致死锁
diff --git "a/Java/Java\346\272\220\347\240\201\350\247\243\346\236\220---ThreadPoolExecutor-\347\272\277\347\250\213\346\261\240.md" "b/Java/Java\346\272\220\347\240\201\350\247\243\346\236\220---ThreadPoolExecutor-\347\272\277\347\250\213\346\261\240.md"
new file mode 100644
index 0000000000..5b66a76d58
--- /dev/null
+++ "b/Java/Java\346\272\220\347\240\201\350\247\243\346\236\220---ThreadPoolExecutor-\347\272\277\347\250\213\346\261\240.md"
@@ -0,0 +1,1269 @@
+# 1 线程池的好处
+ 线程使应用能够更加充分合理地协调利用CPU、内存、网络、I/O等系统资源.
+线程的创建需要开辟虚拟机栈、本地方法栈、程序计数器等线程私有的内存空间;
+在线程销毁时需要回收这些系统资源.
+频繁地创建和销毁线程会浪费大量的系统资源,增加并发编程风险.
+
+在服务器负载过大的时候,如何让新的线程等待或者友好地拒绝服务?
+
+这些都是线程自身无法解决的;
+所以需要通过线程池协调多个线程,并实现类似主次线程隔离、定时执行、周期执行等任务.
+
+线程池的作用包括:
+●利用线程池管理并复用线程、控制最大并发数等
+●实现任务线程队列缓存策略和拒绝机制
+●实现某些与时间相关的功能
+如定时执行、周期执行等
+●隔离线程环境
+比如，交易服务和搜索服务在同一台服务器上,分别开启两个线程池,交易线程的资源消耗明显要大;
+因此,通过配置独立的线程池,将较慢的交易服务与搜索服务隔离开,避免各服务线程相互影响.
+
+在开发中,合理地使用线程池能够带来3个好处
+ - **降低资源消耗** 通过重复利用已创建的线程,降低创建和销毁线程造成的系统资源消耗
+ - **提高响应速度** 当任务到达时,任务可以不需要等到线程创建就能立即执行
+ - **提高线程的可管理性** 线程是稀缺资源,如果过多地创建,不仅会消耗系统资源，还会降低系统的稳定性，导致使用线程池可以进行统一分配、调优和监控。
+
+在了解线程池的基本作用后，我们学习一下线程池是如何创建线程的
+
+# 2 创建线程池
+首先从`ThreadPoolExecutor`构造方法讲起,学习如何自定义`ThreadFactory`和`RejectedExecutionHandler`;
+并编写一个最简单的线程池示例.
+然后,通过分析`ThreadPoolExecutor`的`execute`和`addWorker`两个核心方法;
+学习如何把任务线程加入到线程池中运行.
+
+- ThreadPoolExecutor 的构造方法如下
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852732_4685968-a5f955b792bd453e.png)
+
+- 第1个参数: corePoolSize 表示常驻核心线程数
+如果等于0,则任务执行完之后,没有任何请求进入时销毁线程池的线程;
+如果大于0,即使本地任务执行完毕,核心线程也不会被销毁.
+这个值的设置非常关键;
+设置过大会浪费资源;
+设置过小会导致线程频繁地创建或销毁.
+
+- 第2个参数: maximumPoolSize 表示线程池能够容纳同时执行的最大线程数
+从第1处来看,必须>=1.
+如果待执行的线程数大于此值,需要借助第5个参数的帮助,缓存在队列中.
+如果`maximumPoolSize = corePoolSize`,即是固定大小线程池.
+
+- 第3个参数: keepAliveTime 表示线程池中的线程空闲时间
+当空闲时间达到`keepAliveTime`时,线程会被销毁,直到只剩下`corePoolSize`个线程;
+避免浪费内存和句柄资源.
+在默认情况下,当线程池的线程数大于`corePoolSize`时,`keepAliveTime`才起作用.
+但是当`ThreadPoolExecutor`的`allowCoreThreadTimeOut = true`时,核心线程超时后也会被回收.
+
+- 第4个参数: TimeUnit表示时间单位
+keepAliveTime的时间单位通常是TimeUnit.SECONDS.
+
+- 第5个参数: workQueue 表示缓存队列
+当请求的线程数大于`maximumPoolSize`时,线程进入`BlockingQueue`.
+后续示例代码中使用的LinkedBlockingQueue是单向链表,使用锁来控制入队和出队的原子性;
+两个锁分别控制元素的添加和获取,是一个生产消费模型队列.
+
+- 第6个参数: threadFactory 表示线程工厂
+它用来生产一组相同任务的线程;
+线程池的命名是通过给这个factory增加组名前缀来实现的.
+在虚拟机栈分析时,就可以知道线程任务是由哪个线程工厂产生的.
+
+- 第7个参数: handler 表示执行拒绝策略的对象
+当超过第5个参数`workQueue`的任务缓存区上限的时候,就可以通过该策略处理请求,这是一种简单的限流保护.
+友好的拒绝策略可以是如下三种:
+(1 ) 保存到数据库进行削峰填谷;在空闲时再提取出来执行
+(2)转向某个提示页面
+(3)打印日志
+
+### 2.1.1 corePoolSize(核心线程数量)
+线程池中应该保持的主要线程的数量.即使线程处于空闲状态，除非设置了`allowCoreThreadTimeOut`这个参数,当提交一个任务到线程池时,若线程数量<corePoolSize,线程池会创建一个新线程放入works(一个HashSet)中执行任务,即使其他空闲的基本线程能够执行新任务也还是会创建新线程
+等到需要执行的任务数大于线程池基本大小时就不再创建,会尝试放入等待队列workQueue
+如果调用线程池的`prestartAllCoreThreads()`,线程池会提前创建并启动所有核心线程
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852753_4685968-8410e7935aa8b28e.png)
+### 2.1.2 maximumPoolSize（线程池最大线程数）
+线程池允许创建的最大线程数
+若队列满,并且已创建的线程数小于最大线程数,则线程池会再创建新的线程放入works中执行任务,CashedThreadPool的关键,固定线程数的线程池无效
+若使用了无界任务队列,这个参数就没什么效果
+ - workQueue
+存储待执行任务的阻塞队列，这些任务必须是`Runnable`的对象（如果是Callable对象，会在submit内部转换为Runnable对象） 
+ 
+- runnableTaskQueue(任务队列):用于保存等待执行的任务的阻塞队列.可以选择以下几个阻塞队列.
+  - LinkedBlockingQueue:一个基于链表结构的阻塞队列,此队列按FIFO排序元素,吞吐量通常要高于ArrayBlockingQueue.静态工厂方法Executors.newFixedThreadPool()使用了这个队列
+  - SynchronousQueue:一个不存储元素的阻塞队列.每个插入操作必须等到另一个线程调用移除操作,否则插入操作一直处于阻塞状态,吞吐量通常要高于Linked-BlockingQueue,静态工厂方法Executors.newCachedThreadPool使用了这个队列
+ 
+
+
+ - ThreadFactory:用于设置创建线程的工厂,可以通过线程工厂给每个创建出来的线程设置更有意义的名字.使用开源框架guava提供ThreadFactoryBuilder可以快速给线程池里的线程设置有意义的名字,代码如下
+
+```
+new ThreadFactoryBuilder().setNameFormat("XX-task-%d").build();
+```
+ - RejectedExecutionHandler（拒绝策略）
+当队列和线程池都满,说明线程池饱和,必须采取一种策略处理提交的新任务
+策略默认`AbortPolicy`,表无法处理新任务时抛出异常
+在JDK 1.5中Java线程池框架提供了以下4种策略
+   - AbortPolicy：丢弃任务，抛出 RejectedExecutionException
+   - CallerRunsPolicy:只用调用者所在线程来运行任务,有反馈机制，使任务提交的速度变慢）。
+   - DiscardOldestPolicy
+若没有发生shutdown,尝试丢弃队列里最近的一个任务,并执行当前任务, 丢弃任务缓存队列中最老的任务，并且尝试重新提交新的任务
+   - DiscardPolicy:不处理,丢弃掉, 拒绝执行，不抛异常 
+ 当然,也可以根据应用场景需要来实现RejectedExecutionHandler接口自定义策略.如记录日志或持久化存储不能处理的任务
+```
+   /**
+     * Invokes the rejected execution handler for the given command.
+     * Package-protected for use by ScheduledThreadPoolExecutor.
+     */
+    final void reject(Runnable command) {
+        // 执行拒绝策略
+        handler.rejectedExecution(command, this);
+    }
+```
+`handler` 构造线程池时候就传的参数，`RejectedExecutionHandler `的实例
+`RejectedExecutionHandler` 在 `ThreadPoolExecutor` 中有四个实现类可供我们直接使用，当然，也可以实现自己的策略，一般也没必要。
+``` 
+    //只要线程池没有被关闭，由提交任务的线程自己来执行这个任务
+    public static class CallerRunsPolicy implements RejectedExecutionHandler {
+
+        public CallerRunsPolicy() { }
+
+        /**
+         * Executes task r in the caller's thread, unless the executor
+         * has been shut down, in which case the task is discarded.
+         *
+         * @param r the runnable task requested to be executed
+         * @param e the executor attempting to execute this task
+         */
+        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
+            if (!e.isShutdown()) {
+                r.run();
+            }
+        }
+    }
+
+    // 不管怎样，直接抛出 RejectedExecutionException 异常
+    // 默认的策略，如果我们构造线程池的时候不传相应的 handler ，则指定使用这个
+    public static class AbortPolicy implements RejectedExecutionHandler {
+       
+        public AbortPolicy() { }
+
+        /**
+         * Always throws RejectedExecutionException.
+         *
+         * @param r the runnable task requested to be executed
+         * @param e the executor attempting to execute this task
+         * @throws RejectedExecutionException always
+         */
+        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
+            throw new RejectedExecutionException("Task " + r.toString() +
+                                                 " rejected from " +
+                                                 e.toString());
+        }
+    }
+
+    // 不做任何处理，直接忽略掉这个任务
+    public static class DiscardPolicy implements RejectedExecutionHandler {
+        /**
+         * Creates a {@code DiscardPolicy}.
+         */
+        public DiscardPolicy() { }
+
+        /**
+         * Does nothing, which has the effect of discarding task r.
+         *
+         * @param r the runnable task requested to be executed
+         * @param e the executor attempting to execute this task
+         */
+        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
+        }
+    }
+
+    // 若线程池未被关闭
+    // 把队列队头的任务(也就是等待了最长时间的)直接扔掉，然后提交这个任务到等待队列中
+    public static class DiscardOldestPolicy implements RejectedExecutionHandler {
+      
+        public DiscardOldestPolicy() { }
+
+        /**
+         * Obtains and ignores the next task that the executor
+         * would otherwise execute, if one is immediately available,
+         * and then retries execution of task r, unless the executor
+         * is shut down, in which case task r is instead discarded.
+         *
+         * @param r the runnable task requested to be executed
+         * @param e the executor attempting to execute this task
+         */
+        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
+            if (!e.isShutdown()) {
+                e.getQueue().poll();
+                e.execute(r);
+            }
+        }
+    }
+```
+- keepAliveTime（线程活动保持时间）
+线程没有任务执行时最多保持多久时间终止
+线程池的工作线程空闲后，保持存活的时间。
+所以，如果任务很多，并且每个任务执行的时间比较短，可以调大时间，提高线程的利用率
+
+ - TimeUnit（线程活动保持时间的单位）:指示第三个参数的时间单位；可选的单位有天（DAYS）、小时（HOURS）、分钟（MINUTES）、毫秒（MILLISECONDS）、微秒（MICROSECONDS，千分之一毫秒）和纳秒（NANOSECONDS，千分之一微秒）
+
+
+从代码第2处来看，**队列、线程工厂、拒绝处理服务**都必须有实例对象;
+但在实际编程中,很少有程序员对这三者进行实例化,而通过`Executors`这个线程池静态工厂提供默认实现;
+那么Exceutors与ThreadPoolExecutor是什么关系呢?
+![线程池相关类图](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852909_4685968-eaaaf8fd88497757.png)
+
+# Executors工厂类
+`ExecutorService` 的抽象类`AbstractExecutorService `提供了`submit`、`invokeAll` 等方法的实现;
+但是核心方法`Executor.execute()`并没有在这里实现.
+因为所有的任务都在该方法执行,不同实现会带来不同的执行策略.
+
+通过`Executors`的静态工厂方法可以创建三个线程池的包装对象
+- ForkJoinPool、
+- ThreadPoolExecutor
+- ScheduledThreadPoolExecutor
+
+● Executors.newWorkStealingPool
+JDK8 引入,创建持有足够线程的线程池支持给定的并行度;
+并通过使用多个队列减少竞争;
+构造方法中把CPU数量设置为默认的并行度.
+返回`ForkJoinPool` ( JDK7引入)对象,它也是`AbstractExecutorService` 的子类
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852906_4685968-3b4a8e8c1408f892.png)
+
+
+● Executors.newCachedThreadPool
+`maximumPoolSize` 最大可以至`Integer.MAX_VALUE`,是高度可伸缩的线程池.
+若达到该上限,相信没有服务器能够继续工作,直接OOM.
+`keepAliveTime` 默认为60秒;
+工作线程处于空闲状态,则回收工作线程;
+如果任务数增加,再次创建出新线程处理任务.
+
+● Executors.newScheduledThreadPool
+线程数最大至`Integer.MAX_ VALUE`,与上述相同,存在OOM风险.
+`ScheduledExecutorService`接口的实现类,支持**定时及周期性任务执行**;
+相比`Timer`,` ScheduledExecutorService` 更安全,功能更强大.
+与`newCachedThreadPool`的区别是**不回收工作线程**.
+
+● Executors.newSingleThreadExecutor
+创建一个单线程的线程池,相当于单线程串行执行所有任务,保证按任务的提交顺序依次执行.
+
+● Executors.newFixedThreadPool
+输入的参数即是固定线程数;
+既是核心线程数也是最大线程数;
+不存在空闲线程,所以`keepAliveTime`等于0.
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852819_4685968-8cd91f3c6eada9de.png)
+其中使用了 LinkedBlockingQueue, 但是没有设置上限!!!,堆积过多任务!!!
+
+下面介绍`LinkedBlockingQueue`的构造方法
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852910_4685968-fce261dbe30def71.png)
+使用这样的无界队列,如果瞬间请求非常大,会有OOM的风险;
+除`newWorkStealingPool` 外,其他四个创建方式都存在资源耗尽的风险.
+
+不推荐使用其中的任何创建线程池的方法,因为都没有任何限制,存在安全隐患.
+
+ `Executors`中默认的线程工厂和拒绝策略过于简单,通常对用户不够友好.
+线程工厂需要做创建前的准备工作,对线程池创建的线程必须明确标识,就像药品的生产批号一样,为线程本身指定有意义的名称和相应的序列号.
+拒绝策略应该考虑到业务场景,返回相应的提示或者友好地跳转.
+以下为简单的ThreadFactory 示例
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852797_4685968-d2025287a82add95.png)
+
+上述示例包括线程工厂和任务执行体的定义;
+通过newThread方法快速、统一地创建线程任务,强调线程一定要有特定意义的名称,方便出错时回溯.
+
+- 单线程池：newSingleThreadExecutor()方法创建，五个参数分别是ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue())。含义是池中保持一个线程，最多也只有一个线程，也就是说这个线程池是顺序执行任务的，多余的任务就在队列中排队。 
+- 固定线程池：newFixedThreadPool(nThreads)方法创建
+![](https://uploadfiles.nowcoder.com/images/20190625/5088755_1561474494512_5D0DD7BCB7171E9002EAD3AEF42149E6 "图片标题") 
+
+池中保持nThreads个线程，最多也只有nThreads个线程，多余的任务也在队列中排队。 
+![](https://uploadfiles.nowcoder.com/images/20190625/5088755_1561476084467_4A47A0DB6E60853DEDFCFDF08A5CA249 "图片标题") 
+
+![](https://uploadfiles.nowcoder.com/images/20190625/5088755_1561476102425_FB5C81ED3A220004B71069645F112867 "图片标题") 
+线程数固定且线程不超时
+- 缓存线程池：newCachedThreadPool()创建，五个参数分别是ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue())。
+含义是池中不保持固定数量的线程，随需创建，最多可以创建Integer.MAX_VALUE个线程（说一句，这个数量已经大大超过目前任何操作系统允许的线程数了），空闲的线程最多保持60秒，多余的任务在SynchronousQueue（所有阻塞、并发队列在后续文章中具体介绍）中等待。 
+
+为什么单线程池和固定线程池使用的任务阻塞队列是LinkedBlockingQueue()，而缓存线程池使用的是SynchronousQueue()呢？ 
+因为单线程池和固定线程池中，线程数量是有限的，因此提交的任务需要在LinkedBlockingQueue队列中等待空余的线程；而缓存线程池中，线程数量几乎无限（上限为Integer.MAX_VALUE），因此提交的任务只需要在SynchronousQueue队列中同步移交给空余线程即可。
+
+- 单线程调度线程池：newSingleThreadScheduledExecutor()创建，五个参数分别是 (1, Integer.MAX_VALUE, 0, NANOSECONDS, new DelayedWorkQueue())。含义是池中保持1个线程，多余的任务在DelayedWorkQueue中等待。 
+- 固定调度线程池：newScheduledThreadPool(n)创建，五个参数分别是 (n, Integer.MAX_VALUE, 0, NANOSECONDS, new DelayedWorkQueue())。含义是池中保持n个线程，多余的任务在DelayedWorkQueue中等待。
+
+有一项技术可以缓解执行时间较长任务造成的影响，即限定任务等待资源的时间，而不要无限的等待
+
+先看第一个例子，测试单线程池、固定线程池和缓存线程池（注意增加和取消注释）：
+
+```
+public class ThreadPoolExam {
+    public static void main(String[] args) {
+        //first test for singleThreadPool
+        ExecutorService pool = Executors.newSingleThreadExecutor();
+        //second test for fixedThreadPool
+//        ExecutorService pool = Executors.newFixedThreadPool(2);
+        //third test for cachedThreadPool
+//        ExecutorService pool = Executors.newCachedThreadPool();
+        for (int i = 0; i < 5; i++) {
+            pool.execute(new TaskInPool(i));
+        }
+        pool.shutdown();
+    }
+}
+
+class TaskInPool implements Runnable {
+    private final int id;
+
+    TaskInPool(int id) {
+        this.id = id;
+    }
+
+    @Override
+    public void run() {
+        try {
+            for (int i = 0; i < 5; i++) {
+                System.out.println("TaskInPool-["+id+"] is running phase-"+i);
+                TimeUnit.SECONDS.sleep(1);
+            }
+            System.out.println("TaskInPool-["+id+"] is over");
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+    }
+}
+```
+
+如图为排查底层公共缓存调用出错时的截图
+![有意义的线程命名](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852749_4685968-85502533906c33f2.png)
+绿色框采用自定义的线程工厂,明显比蓝色框默认的线程工厂创建的线程名称拥有更多的额外信息:如调用来源、线程的业务含义，有助于快速定位到死锁、StackOverflowError 等问题.
+
+# 拒绝策略
+下面再简单地实现一下`RejectedExecutionHandler`;
+实现了接口的`rejectedExecution`方法,打印出当前线程池状态
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852809_4685968-ac7fac2c6b332daf.png)
+
+
+在`ThreadPoolExecutor`中提供了四个公开的内部静态类
+● AbortPolicy  - **默认** 
+丢弃任务并抛出`RejectedExecutionException`
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852986_4685968-dcf8126c187d4bfa.png)
+
+● DiscardPolicy - **不推荐**
+丢弃任务,但不拋异常.
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852956_4685968-d5195020e347d8eb.png)
+
+● DiscardOldestPolicy
+抛弃队列中等待最久的任务,然后把当前任务加入队列中.
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853806_4685968-d3a36b90211138f4.png)
+
+● CallerRunsPolicy
+调用任务的run()方法绕过线程池直接执行.
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852908_4685968-c06a04d6ce30de97.png)
+
+
+根据之前实现的线程工厂和拒绝策略,线程池的相关代码实现如下
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473854161_4685968-8b1c576213bea3ca.png)
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853636_4685968-184f455240f1b79c.png)
+当任务被拒绝的时候，拒绝策略会打印出当前线程池的大小已经达到了`maximumPoolSize=2`,且队列已满,完成的任务数提示已经有1个(最后一行).
+
+# 源码讲解
+在`ThreadPoolExecutor`的属性定义中频繁地用位运算来表示线程池状态;
+位运算是改变当前值的一种高效手段.
+
+下面从属性定义开始
+
+>Integer 有32位;
+最右边29位表工作线程数;
+最左边3位表示线程池状态,可表示从0至7的8个不同数值
+线程池的状态用高3位表示,其中包括了符号位.
+五种状态的十进制值按从小到大依次排序为
+RUNNING < SHUTDOWN < STOP < TIDYING <TERMINATED
+这样设计的好处是可以通过比较值的大小来确定线程池的状态.
+例如程序中经常会出现isRunning的判断:
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852842_4685968-8dc7d0eacb458f2e.png)
+
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852717_4685968-813376a9826e24c6.png)
+
+- 000-1111111111111111111111111;
+类似于子网掩码,用于与运算;
+得到左边3位,还是右边29位
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853309_4685968-6c7f894116972a2f.png)
+
+用左边3位,实现5种线程池状态;
+在左3位之后加入中画线有助于理解;
+
+- 111 - 0000000000000000000000000000(十进制: -536, 870, 912);
+该状态表 线程池能接受新任务
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852713_4685968-e838c56b99544e93.png)
+
+
+- 000 - 0000000000000000000000000(十进制: 0);
+此状态不再接受新任务,但可继续执行队列中的任务
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853025_4685968-d3447678b77c851f.png)
+
+- 001 - 00000000000000000000000000(十进制: 536,870， 912);
+此状态全面拒绝,并中断正在处理的任务
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852872_4685968-6c399a28de0f375b.png)
+
+- 010 - 00000000000000000000000000.(十进制值: 1, 073, 741, 824);
+该状态表 所有任务已经被终止
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852814_4685968-e1341ccae3d73473.png)
+
+- 101 - 000000000000000000000000000(十进制值: 1, 610,612, 736)
+该状态表 已清理完现场
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852713_4685968-2b83ef2a0f28b570.png)
+
+
+与运算,比如 001 - 000000000000000000000100011 表 67个工作线程;
+掩码取反: 111 - 00000000000000000000000.,即得到左边3位001;
+表示线程池当前处于**STOP**状态
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852956_4685968-0d9b0884abe8e1c1.png)
+
+同理掩码 000 - 11111111111111111111,得到右边29位,即工作线程数
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852768_4685968-90063b2134c89772.png)
+
+把左3位与右29位或运算,合并成一个值
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852959_4685968-858df4ebcb91a84e.png)
+
+
+我们都知道`Executor`接口有且只有一个方法`execute()`;
+通过参数传入待执行线程的对象.
+下面分析`ThreadPoolExecutor`关于`execute()`方法的实现
+
+线程池执行任务的方法如下
+```
+   /**
+     * Executes the given task sometime in the future.  The task
+     * may execute in a new thread or in an existing pooled thread.
+     *
+     * If the task cannot be submitted for execution, either because this
+     * executor has been shutdown or because its capacity has been reached,
+     * the task is handled by the current {@code RejectedExecutionHandler}.
+     *
+     * @param command the task to execute
+     * @throws RejectedExecutionException at discretion of
+     *         {@code RejectedExecutionHandler}, if the task
+     *         cannot be accepted for execution
+     * @throws NullPointerException if {@code command} is null
+     */
+    public void execute(Runnable command) {
+        if (command == null)
+            throw new NullPointerException();
+        /*
+         * Proceed in 3 steps:
+         *
+         * 1. If fewer than corePoolSize threads are running, try to
+         * start a new thread with the given command as its first
+         * task.  The call to addWorker atomically checks runState and
+         * workerCount, and so prevents false alarms that would add
+         * threads when it shouldn't, by returning false.
+         *
+         * 2. If a task can be successfully queued, then we still need
+         * to double-check whether we should have added a thread
+         * (because existing ones died since last checking) or that
+         * the pool shut down since entry into this method. So we
+         * recheck state and if necessary roll back the enqueuing if
+         * stopped, or start a new thread if there are none.
+         *
+         * 3. If we cannot queue task, then we try to add a new
+         * thread.  If it fails, we know we are shut down or saturated
+         * and so reject the task.
+         */
+        // 返回包含线程数及线程池状态的Integer 类型数值
+        int c = ctl.get();
+
+        // 若工作线程数 < 核心线程数,则创建线程并执行当前任务
+        if (workerCountOf(c) < corePoolSize) {
+            if (addWorker(command, true))
+```
+`execute`方法在不同的阶段有三次`addWorker`的尝试动作。
+```
+                return;
+            // 若创建失败,为防止外部已经在线程池中加入新任务,在此重新获取一下
+            c = ctl.get();
+        }
+
+        // 若 工作线程数 >=核心线程数 或线程创建失败,则将当前任务放到工作队列中
+        // 只有线程池处于 RUNNING 态,才执行后半句 : 置入队列
+        if (isRunning(c) && workQueue.offer(command)) {
+            int recheck = ctl.get();
+            
+            // 只有线程池处于 RUNNING 态,才执行后半句 : 置入队列
+            if (! isRunning(recheck) && remove(command))
+                reject(command);
+            // 若之前的线程已被消费完,新建一个线程
+            else if (workerCountOf(recheck) == 0)
+                addWorker(null, false);
+        // 核心线程和队列都已满,尝试创建一个新线程
+        }
+        else if (!addWorker(command, false))
+            // 抛出RejectedExecutionException异常
+            // 若 addWorker 返回是 false,即创建失败,则唤醒拒绝策略.
+            reject(command);
+    }
+```
+发生拒绝的理由有两个
+( 1 )线程池状态为非RUNNING状态
+(2)等待队列已满。
+
+下面继续分析`addWorker`
+
+## addWorker 源码解析
+
+根据当前线程池状态,检查是否可以添加新的任务线程,若可以则创建并启动任务;
+若一切正常则返回true;
+返回false的可能性如下
+1. 线程池没有处于`RUNNING`态
+2. 线程工厂创建新的任务线程失败
+### 参数
+- firstTask
+外部启动线程池时需要构造的第一个线程,它是线程的母体
+- core
+新增工作线程时的判断指标
+     - true
+需要判断当前`RUNNING`态的线程是否少于`corePoolsize`
+    - false
+需要判断当前`RUNNING`态的线程是否少于`maximumPoolsize`
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853220_4685968-28604fb5da1922e4.png)
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852789_4685968-995fae94294021c7.png)
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852830_4685968-3f775b9d518f3783.png)
+
+这段代码晦涩难懂,部分地方甚至违反代码规约,但其中蕴含丰富的编码知识点
+
+- 第1处,配合循环语句出现的label,类似于goto 作用
+label 定义时,必须把标签和冒号的组合语句紧紧相邻定义在循环体之前,否则会编译出错.
+目的是 在实现多重循环时能够快速退出到任何一层;
+出发点似乎非常贴心,但在大型软件项目中,滥用标签行跳转的后果将是灾难性的.
+示例代码中在`retry`下方有两个无限循环;
+在`workerCount`加1成功后,直接退出两层循环.
+
+- 第2处,这样的表达式不利于阅读,应如是
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852785_4685968-086e9d5f9da2afd4.png)
+
+- 第3处,与第1处的标签呼应,`AtomicInteger`对象的加1操作是原子性的;
+`break retry`表 直接跳出与`retry` 相邻的这个循环体
+ 
+- 第4处,此`continue`跳转至标签处,继续执行循环.
+如果条件为false,则说明线程池还处于运行状态,即继续在`for(;)`循环内执行.
+
+- 第5处,`compareAndIncrementWorkerCount `方法执行失败的概率非常低.
+即使失败,再次执行时成功的概率也是极高的,类似于自旋原理.
+这里是先加1,创建失败再减1,这是轻量处理并发创建线程的方式;
+如果先创建线程,成功再加1,当发现超出限制后再销毁线程,那么这样的处理方式明显比前者代价要大.
+
+- 第6处,`Worker `对象是工作线程的核心类实现，部分源码如下
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853232_4685968-c9352782c56c3d67.png)
+它实现了`Runnable`接口,并把本对象作为参数输入给`run()`中的`runWorker (this)`;
+所以内部属性线程`thread`在`start`的时候,即会调用`runWorker`.
+
+# 总结
+线程池的相关源码比较精炼，还包括线程池的销毁、任务提取和消费等，与线程状态图一样，线程池也有自己独立的状态转化流程，本节不再展开。
+总结一下，使用线程池要注意如下几点:
+(1)合理设置各类参数，应根据实际业务场景来设置合理的工作线程数。
+(2)线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
+(3)创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。
+
+线程池不允许使用Executors，而是通过ThreadPoolExecutor的方式创建，这样的处理方式能更加明确线程池的运行规则，规避资源耗尽的风险。
+
+
+
+
+
+进一步查看源码发现,这些方法最终都调用了ThreadPoolExecutor和ScheduledThreadPoolExecutor的构造函数
+而ScheduledThreadPoolExecutor继承自ThreadPoolExecutor
+
+## 0.2 ThreadPoolExecutor 自定义线程池
+![](https://uploadfiles.nowcoder.com/images/20190625/5088755_1561476436402_10FB15C77258A991B0028080A64FB42D "图片标题") 
+它们都是某种线程池,可以控制线程创建,释放,并通过某种策略尝试复用线程去执行任务的一个管理框架
+
+,因此最终所有线程池的构造函数都调用了Java5后推出的ThreadPoolExecutor的如下构造函数                        
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852810_4685968-bf41009597986058.png)
+
+## Java默认提供的线程池
+Java中的线程池是运用场景最多的并发框架,几乎所有需要异步或并发执行任务的程序都可以使用线程池
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853075_4685968-4f18b5e96eb1d930.png)
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852989_4685968-b7ec59a800442b26.png)
+
+我们只需要将待执行的方法放入 run 方法中，将 Runnable 接口的实现类交给线程池的
+execute 方法，作为他的一个参数，比如： 
+```java
+Executor e=Executors.newSingleThreadExecutor();           
+e.execute(new Runnable(){ //匿名内部类     public  void run(){  
+//需要执行的任务 
+} 
+}); 
+
+```
+# 线程池的实现原理
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852674_4685968-fa16ddf5e4094e75.png)
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852730_4685968-a07b8b323331c15e.png)
+
+ThreadPoolExecutor执行execute()分4种情况
+ - 若当前运行的线程少于`corePoolSize`,则创建新线程来执行任务(执行这一步需要获取全局锁)
+ - 若运行的线程多于或等于`corePoolSize`,则将任务加入`BlockingQueue`
+ - 若无法将任务加入`BlockingQueue`,则创建新的线程来处理任务(执行这一步需要获取全局锁)
+ - 若创建新线程将使当前运行的线程超出`maximumPoolSize`,任务将被拒绝,并调用`RejectedExecutionHandler.rejectedExecution()`
+
+采取上述思路,是为了在执行`execute()`时,尽可能避免获取全局锁
+在ThreadPoolExecutor完成预热之后（当前运行的线程数大于等于corePoolSize),几乎所有的execute()方法调用都是执行步骤2,而步骤2不需要获取全局锁
+
+#**源码分析**
+```
+   /**
+	 * 检查是否可以根据当前池状态和给定的边界（核心或最大)
+     * 添加新工作线程。如果是这样,工作线程数量会相应调整，如果可能的话,一个新的工作线程创建并启动
+     * 将firstTask作为其运行的第一项任务。
+     * 如果池已停止此方法返回false
+     * 如果线程工厂在被访问时未能创建线程,也返回false
+     * 如果线程创建失败，或者是由于线程工厂返回null，或者由于异常（通常是在调用Thread.start（）后的OOM）），我们干净地回滚。
+	 *
+	 * @param core if true use corePoolSize as bound, else
+	 * maximumPoolSize. (A boolean indicator is used here rather than a
+	 * value to ensure reads of fresh values after checking other pool
+	 * state).
+	 * @return true if successful
+	 */
+    private boolean addWorker(Runnable firstTask, boolean core) {
+        retry:
+        for (;;) {
+            int c = ctl.get();
+            int rs = runStateOf(c);
+      
+            
+    /**
+     * Check if queue empty only if necessary.
+     * 
+     * 如果线程池已关闭，并满足以下条件之一，那么不创建新的 worker：
+     *      1. 线程池状态大于 SHUTDOWN，也就是 STOP, TIDYING, 或 TERMINATED
+     *      2. firstTask != null
+     *      3. workQueue.isEmpty()
+     * 简单分析下：
+     *      状态控制的问题，当线程池处于 SHUTDOWN ，不允许提交任务，但是已有任务继续执行
+     *      当状态大于 SHUTDOWN ，不允许提交任务，且中断正在执行任务
+     *      多说一句：若线程池处于 SHUTDOWN，但 firstTask 为 null，且 workQueue 非空，是允许创建 worker 的
+     *  
+     */
+            if (rs >= SHUTDOWN &&
+                ! (rs == SHUTDOWN &&
+                   firstTask == null &&
+                   ! workQueue.isEmpty()))
+                return false;
+
+            for (;;) {
+                int wc = workerCountOf(c);
+                if (wc >= CAPACITY ||
+                    wc >= (core ? corePoolSize : maximumPoolSize))
+                    return false;
+                // 如果成功，那么就是所有创建线程前的条件校验都满足了，准备创建线程执行任务
+                // 这里失败的话，说明有其他线程也在尝试往线程池中创建线程
+                if (compareAndIncrementWorkerCount(c))
+                    break retry;
+                // 由于有并发，重新再读取一下 ctl
+                c = ctl.get();  // Re-read ctl
+                // 正常如果是 CAS 失败的话，进到下一个里层的for循环就可以了
+                // 可如果是因为其他线程的操作，导致线程池的状态发生了变更，如有其他线程关闭了这个线程池
+                // 那么需要回到外层的for循环
+                if (runStateOf(c) != rs)
+                    continue retry;
+                // else CAS failed due to workerCount change; retry inner loop
+            }
+        }
+
+     /* *
+        * 到这里，我们认为在当前这个时刻，可以开始创建线程来执行任务
+        */
+         
+        // worker 是否已经启动
+        boolean workerStarted = false;
+        // 是否已将这个 worker 添加到 workers 这个 HashSet 中
+        boolean workerAdded = false;
+        Worker w = null;
+        try {
+           // 把 firstTask 传给 worker 的构造方法
+            w = new Worker(firstTask);
+            // 取 worker 中的线程对象，Worker的构造方法会调用 ThreadFactory 来创建一个新的线程
+            final Thread t = w.thread;
+            if (t != null) {
+               //先加锁
+                final ReentrantLock mainLock = this.mainLock;
+                // 这个是整个类的全局锁，持有这个锁才能让下面的操作“顺理成章”，
+                // 因为关闭一个线程池需要这个锁，至少我持有锁的期间，线程池不会被关闭
+                mainLock.lock();
+                try {
+                    // Recheck while holding lock.
+                    // Back out on ThreadFactory failure or if
+                    // shut down before lock acquired.
+                    int rs = runStateOf(ctl.get());
+
+                    // 小于 SHUTTDOWN 即 RUNNING
+                    // 如果等于 SHUTDOWN，不接受新的任务，但是会继续执行等待队列中的任务
+                    if (rs < SHUTDOWN ||
+                        (rs == SHUTDOWN && firstTask == null)) {
+                        // worker 里面的 thread 不能是已启动的
+                        if (t.isAlive()) // precheck that t is startable
+                            throw new IllegalThreadStateException();
+                        // 加到 workers 这个 HashSet 中
+                        workers.add(w);
+                        int s = workers.size();
+                        if (s > largestPoolSize)
+                            largestPoolSize = s;
+                        workerAdded = true;
+                    }
+                } finally {
+                    mainLock.unlock();
+                }
+               // 若添加成功
+                if (workerAdded) {
+                    // 启动线程
+                    t.start();
+                    workerStarted = true;
+                }
+            }
+        } finally {
+            // 若线程没有启动，做一些清理工作，若前面 workCount 加了 1，将其减掉
+            if (! workerStarted)
+                addWorkerFailed(w);
+        }
+        // 返回线程是否启动成功
+        return workerStarted;
+    }
+```
+看下  `addWorkFailed` 
+![workers 中删除掉相应的 worker,workCount 减 1
+private void addWor](https://upload-images.jianshu.io/upload_images/4685968-77abdc7bff21cca6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![记录 workers 中的个数的最大值,因为 workers 是不断增加减少的，通过这个值可以知道线程池的大小曾经达到的最大值](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852708_4685968-078472b682fcc9cd.png)
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473853633_4685968-33f514577e97dc35.png)
+
+
+
+
+`worker` 中的线程 `start` 后，其 `run` 方法会调用 `runWorker `
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852880_4685968-a009bc02a224dce2.png)
+继续往下看 `runWorker`
+```
+//  worker 线程启动后调用,while 循环(即自旋!)不断从等待队列获取任务并执行
+//  worker 初始化时，可指定 firstTask，那么第一个任务也就可以不需要从队列中获取
+final void runWorker(Worker w) {
+    Thread wt = Thread.currentThread();
+    // 该线程的第一个任务(若有)
+    Runnable task = w.firstTask;
+    w.firstTask = null;
+    // 允许中断
+    w.unlock(); 
+ 
+    boolean completedAbruptly = true;
+    try {
+        // 循环调用 getTask 获取任务
+        while (task != null || (task = getTask()) != null) {
+            w.lock();          
+            // 若线程池状态大于等于 STOP，那么意味着该线程也要中断
+              /**
+               * 若线程池STOP，请确保线程 已被中断
+               * 如果没有，请确保线程未被中断
+               * 这需要在第二种情况下进行重新检查，以便在关中断时处理shutdownNow竞争
+               */
+            if ((runStateAtLeast(ctl.get(), STOP) ||
+                 (Thread.interrupted() &&
+                  runStateAtLeast(ctl.get(), STOP))) &&
+                !wt.isInterrupted())
+                wt.interrupt();
+            try {
+                // 这是一个钩子方法，留给需要的子类实现
+                beforeExecute(wt, task);
+                Throwable thrown = null;
+                try {
+                    // 到这里终于可以执行任务了
+                    task.run();
+                } catch (RuntimeException x) {
+                    thrown = x; throw x;
+                } catch (Error x) {
+                    thrown = x; throw x;
+                } catch (Throwable x) {
+                    // 这里不允许抛出 Throwable，所以转换为 Error
+                    thrown = x; throw new Error(x);
+                } finally {
+                    // 也是一个钩子方法，将 task 和异常作为参数，留给需要的子类实现
+                    afterExecute(task, thrown);
+                }
+            } finally {
+                // 置空 task，准备 getTask 下一个任务
+                task = null;
+                // 累加完成的任务数
+                w.completedTasks++;
+                // 释放掉 worker 的独占锁
+                w.unlock();
+            }
+        }
+        completedAbruptly = false;
+    } finally {
+        // 到这里，需要执行线程关闭
+        // 1. 说明 getTask 返回 null，也就是说，这个 worker 的使命结束了，执行关闭
+        // 2. 任务执行过程中发生了异常
+        //    第一种情况，已经在代码处理了将 workCount 减 1，这个在 getTask 方法分析中说
+        //    第二种情况，workCount 没有进行处理，所以需要在 processWorkerExit 中处理
+        processWorkerExit(w, completedAbruptly);
+    }
+}
+```
+看看 `getTask() `
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561473852780_4685968-5e94773193d9cf49.png)
+```
+// 此方法有三种可能
+// 1. 阻塞直到获取到任务返回。默认 corePoolSize 之内的线程是不会被回收的，它们会一直等待任务
+// 2. 超时退出。keepAliveTime 起作用的时候，也就是如果这么多时间内都没有任务，那么应该执行关闭
+// 3. 如果发生了以下条件，须返回 null
+//     池中有大于 maximumPoolSize 个 workers 存在(通过调用 setMaximumPoolSize 进行设置)
+//     线程池处于 SHUTDOWN，而且 workQueue 是空的，前面说了，这种不再接受新的任务
+//     线程池处于 STOP，不仅不接受新的线程，连 workQueue 中的线程也不再执行
+private Runnable getTask() {
+    boolean timedOut = false; // Did the last poll() time out?
+
+   for (;;) {
+   // 允许核心线程数内的线程回收，或当前线程数超过了核心线程数，那么有可能发生超时关闭
+ 
+            // 这里 break，是为了不往下执行后一个 if (compareAndDecrementWorkerCount(c))
+            // 两个 if 一起看：如果当前线程数 wc > maximumPoolSize，或者超时，都返回 null
+            // 那这里的问题来了，wc > maximumPoolSize 的情况，为什么要返回 null？
+            // 换句话说，返回 null 意味着关闭线程。
+            // 那是因为有可能开发者调用了 setMaximumPoolSize 将线程池的 maximumPoolSize 调小了
+        
+            // 如果此 worker 发生了中断，采取的方案是重试
+            // 解释下为什么会发生中断，这个读者要去看 setMaximumPoolSize 方法，
+            // 如果开发者将 maximumPoolSize 调小了，导致其小于当前的 workers 数量，
+            // 那么意味着超出的部分线程要被关闭。重新进入 for 循环，自然会有部分线程会返回 null
+            int c = ctl.get();
+            int rs = runStateOf(c);
+
+            // Check if queue empty only if necessary.
+            if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
+                // CAS 操作，减少工作线程数
+                decrementWorkerCount();
+                return null;
+            }
+
+            int wc = workerCountOf(c);
+
+            // Are workers subject to culling?
+            boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
+
+            if ((wc > maximumPoolSize || (timed && timedOut))
+                && (wc > 1 || workQueue.isEmpty())) {
+                if (compareAndDecrementWorkerCount(c))
+                    return null;
+                continue;
+            }
+
+            try {
+                Runnable r = timed ?
+                    workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
+                    workQueue.take();
+                if (r != null)
+                    return r;
+                timedOut = true;
+            } catch (InterruptedException retry) {
+            // 如果此 worker 发生了中断，采取的方案是重试
+            // 解释下为什么会发生中断，这个读者要去看 setMaximumPoolSize 方法，
+            // 如果开发者将 maximumPoolSize 调小了，导致其小于当前的 workers 数量，
+            // 那么意味着超出的部分线程要被关闭。重新进入 for 循环，自然会有部分线程会返回 null
+                timedOut = false;
+            }
+        }
+}
+```
+到这里，基本上也说完了整个流程，回到 execute(Runnable command) 方法，看看各个分支，我把代码贴过来一下：
+```
+/**
+     * Executes the given task sometime in the future.  The task
+     * may execute in a new thread or in an existing pooled thread.
+     *
+     * If the task cannot be submitted for execution, either because this
+     * executor has been shutdown or because its capacity has been reached,
+     * the task is handled by the current {@code RejectedExecutionHandler}.
+     *
+     * @param command the task to execute
+     * @throws RejectedExecutionException at discretion of
+     *         {@code RejectedExecutionHandler}, if the task
+     *         cannot be accepted for execution
+     * @throws NullPointerException if {@code command} is null
+     */
+    public void execute(Runnable command) {
+        if (command == null)
+            throw new NullPointerException();
+        /*
+         * Proceed in 3 steps:
+         *
+         * 1. If fewer than corePoolSize threads are running, try to
+         * start a new thread with the given command as its first
+         * task.  The call to addWorker atomically checks runState and
+         * workerCount, and so prevents false alarms that would add
+         * threads when it shouldn't, by returning false.
+         *
+         * 2. If a task can be successfully queued, then we still need
+         * to double-check whether we should have added a thread
+         * (because existing ones died since last checking) or that
+         * the pool shut down since entry into this method. So we
+         * recheck state and if necessary roll back the enqueuing if
+         * stopped, or start a new thread if there are none.
+         *
+         * 3. If we cannot queue task, then we try to add a new
+         * thread.  If it fails, we know we are shut down or saturated
+         * and so reject the task.
+         */
+        //表示 “线程池状态” 和 “线程数” 的整数
+        int c = ctl.get();
+        // 如果当前线程数少于核心线程数，直接添加一个 worker 执行任务，
+        // 创建一个新的线程，并把当前任务 command 作为这个线程的第一个任务(firstTask)
+        if (workerCountOf(c) < corePoolSize) {
+        // 添加任务成功，即结束
+        // 执行的结果，会包装到 FutureTask 
+        // 返回 false 代表线程池不允许提交任务
+            if (addWorker(command, true))
+                return;
+           
+            c = ctl.get();
+        }
+
+        // 到这说明，要么当前线程数大于等于核心线程数，要么刚刚 addWorker 失败
+  
+        // 如果线程池处于 RUNNING ，把这个任务添加到任务队列 workQueue 中
+        if (isRunning(c) && workQueue.offer(command)) {
+            /* 若任务进入 workQueue，我们是否需要开启新的线程
+             * 线程数在 [0, corePoolSize) 是无条件开启新线程的
+             * 若线程数已经大于等于 corePoolSize，则将任务添加到队列中，然后进到这里
+             */
+            int recheck = ctl.get();
+            // 若线程池不处于 RUNNING ，则移除已经入队的这个任务，并且执行拒绝策略
+            if (! isRunning(recheck) && remove(command))
+                reject(command);
+            // 若线程池还是 RUNNING ，且线程数为 0，则开启新的线程
+            // 这块代码的真正意图：担心任务提交到队列中了，但是线程都关闭了
+            else if (workerCountOf(recheck) == 0)
+                addWorker(null, false);
+        }
+        // 若 workQueue 满，到该分支
+        // 以 maximumPoolSize 为界创建新 worker，
+        // 若失败，说明当前线程数已经达到 maximumPoolSize，执行拒绝策略
+        else if (!addWorker(command, false))
+            reject(command);
+    }
+```
+**工作线程**:线程池创建线程时,会将线程封装成工作线程Worker,Worker在执行完任务后,还会循环获取工作队列里的任务来执行.我们可以从Worker类的run()方法里看到这点
+
+```
+  public void run() {
+        try {
+            Runnable task = firstTask;
+            firstTask = null;
+            while (task != null || (task = getTask()) != null) {
+                runTask(task);
+                task = null;
+            }
+        } finally {
+            workerDone(this);
+        }
+    }
+ boolean workerStarted = false;
+        boolean workerAdded = false;
+        Worker w = null;
+        try {
+            w = new Worker(firstTask);
+
+            final Thread t = w.thread;
+            if (t != null) {
+               //先加锁
+                final ReentrantLock mainLock = this.mainLock;
+                mainLock.lock();
+                try {
+                    // Recheck while holding lock.
+                    // Back out on ThreadFactory failure or if
+                    // shut down before lock acquired.
+                    int rs = runStateOf(ctl.get());
+
+                    if (rs < SHUTDOWN ||
+                        (rs == SHUTDOWN && firstTask == null)) {
+                        if (t.isAlive()) // precheck that t is startable
+                            throw new IllegalThreadStateException();
+                        workers.add(w);
+                        int s = workers.size();
+                        if (s > largestPoolSize)
+                            largestPoolSize = s;
+                        workerAdded = true;
+                    }
+                } finally {
+                    mainLock.unlock();
+                }
+                if (workerAdded) {
+                    t.start();
+                    workerStarted = true;
+                }
+            }
+        } finally {
+            if (! workerStarted)
+                addWorkerFailed(w);
+        }
+        return workerStarted;
+    }
+```
+线程池中的线程执行任务分两种情况
+ - 在execute()方法中创建一个线程时,会让这个线程执行当前任务
+ - 这个线程执行完上图中 1 的任务后,会反复从BlockingQueue获取任务来执行
+
+# 线程池的使用
+
+## 2.2  向线程池提交任务
+ 可以使用两个方法向线程池提交任务
+### 2.2.1 execute()
+用于提交不需要返回值的任务,所以无法判断任务是否被线程池执行成功.通过以下代码可知execute()方法输入的任务是一个Runnable类的实例.
+```
+    threadsPool.execute(new Runnable() {
+            @Override
+            public void run() {
+                   // TODO Auto-generated method stub
+            }
+        });
+```
+从运行结果可以看出，单线程池中的线程是顺序执行的。固定线程池（参数为2）中，永远最多只有两个线程并发执行。缓存线程池中，所有线程都并发执行。 
+第二个例子，测试单线程调度线程池和固定调度线程池。
+
+```
+public class ScheduledThreadPoolExam {
+    public static void main(String[] args) {
+        //first test for singleThreadScheduledPool
+        ScheduledExecutorService scheduledPool = Executors.newSingleThreadScheduledExecutor();
+        //second test for scheduledThreadPool
+//        ScheduledExecutorService scheduledPool = Executors.newScheduledThreadPool(2);
+        for (int i = 0; i < 5; i++) {
+            scheduledPool.schedule(new TaskInScheduledPool(i), 0, TimeUnit.SECONDS);
+        }
+        scheduledPool.shutdown();
+    }
+}
+
+class TaskInScheduledPool implements Runnable {
+    private final int id;
+
+    TaskInScheduledPool(int id) {
+        this.id = id;
+    }
+
+    @Override
+    public void run() {
+        try {
+            for (int i = 0; i < 5; i++) {
+                System.out.println("TaskInScheduledPool-["+id+"] is running phase-"+i);
+                TimeUnit.SECONDS.sleep(1);
+            }
+            System.out.println("TaskInScheduledPool-["+id+"] is over");
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+    }
+}
+```
+从运行结果可以看出，单线程调度线程池和单线程池类似，而固定调度线程池和固定线程池类似。 
+总结：
+
+- 如果没有特殊要求，使用缓存线程池总是合适的；
+- 如果只能运行一个线程，就使用单线程池。
+- 如果要运行调度任务，则按需使用调度线程池或单线程调度线程池
+- 如果有其他特殊要求，则可以直接使用ThreadPoolExecutor类的构造函数来创建线程池，并自己给定那五个参数。
+
+### 2.2.2 submit()
+用于提交需要返回值的任务.线程池会返回一个future类型对象,通过此对象可以判断任务是否执行成功
+并可通过get()获取返回值,get()会阻塞当前线程直到任务完成,而使用get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回,这时候可能任务没有执行完.
+
+```
+    Future<Object> future = executor.submit(harReturnValuetask);
+        try {
+            Object s = future.get();
+        } catch (InterruptedException e) {
+            // 处理中断异常
+        } catch (ExecutionException e) {
+            // 处理无法执行任务异常
+        } finally {
+            // 关闭线程池
+            executor.shutdown();
+        }
+```
+## 2.3 关闭线程池
+可通过调用线程池的**shutdown**或**shutdownNow**方法来关闭线程池.
+它们的原理是遍历线程池中的工作线程,然后逐个调用线程的**interrupt**方法来中断线程,所以无法响应中断的任务可能永远无法终止.
+但是它们存在一定的区别
+
+ - **shutdownNow**首先将线程池的状态设置成STOP,然后尝试停止所有的正在执行或暂停任务的线程,并返回等待执行任务的列表
+ - **shutdown**只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线程.
+
+只要调用了这两个关闭方法中的任意一个,isShutdown方法就会返回true.
+当所有的任务都已关闭后,才表示线程池关闭成功,这时调用isTerminaed方法会返回true.
+至于应该调用哪一种方法,应该由提交到线程池的任务的特性决定,通常调用shutdown方法来关闭线程池,若任务不一定要执行完,则可以调用shutdownNow方法.
+##2.4 合理配置
+要想合理地配置线程池,就必须首先分析任务特性,可从以下几个角度来分析
+ - 任务的性质：CPU密集型任务、IO密集型任务和混合型任务
+ - 任务的优先级：高、中和低
+ - 任务的执行时间：长、中和短
+ - 任务的依赖性：是否依赖其他系统资源，如数据库连接。
+
+性质不同的任务可以用不同规模的线程池分开处理
+- CPU密集型任务
+应配置尽可能小的线程,配置
+ ` N(CPU)+1 `或者 `N(CPU) * 2  `
+- I/O密集型任务
+业务读取较多,线程并不是一直在执行任务,则应配置尽可能多的线程
+`N(CPU)/1 - 阻塞系数(0.8~0.9)`
+- 混合型的任务,如果可以拆分,将其拆分成一个CPU密集型任务和一个IO密集型任务,只要这两个任务执行的时间相差不是太大,那么分解后执行的吞吐量将高于串行执行的吞吐量.如果这两个任务执行时间相差太大,则没必要进行分解.
+
+可以通过Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数.
+
+优先级不同的任务可以使用PriorityBlockingQueue处理.它可以让优先级高
+的任务先执行.
+
+> 注意　如果一直有优先级高的任务提交到队列里,那么优先级低的任务可能永远不能执行
+
+执行时间不同的任务可以交给不同规模的线程池来处理,或者可以使用优先级队列,让执行时间短的任务先执行.
+
+依赖数据库连接池的任务,因为线程提交SQL后需要等待数据库返回结果,等待的时间越长,则CPU空闲时间就越长,那么线程数应该设置得越大,这样才能更好地利用CPU.
+
+**建议使用有界队列**  有界队列能增加系统的稳定性和预警能力，可以根据需要设大一点,比如几千.
+假如系统里后台任务线程池的队列和线程池全满了,不断抛出抛弃任务的异常,通过排查发现是数据库出现了问题,导致执行SQL变得非常缓慢,因为后台任务线程池里的任务全是需要向数据库查询和插入数据的,所以导致线程池里的工作线程全部阻塞,任务积压在线程池里.
+如果我们设置成无界队列,那么线程池的队列就会越来越多,有可能会撑满内存,导致整个系统不可用,而不只是后台任务出现问题.
+## 2.5　线程池的监控
+如果在系统中大量使用线程池,则有必要对线程池进行监控,方便在出现问题时,可以根据线程池的使用状况快速定位问题.可通过线程池提供的参数进行监控,在监控线程池的时候可以使用以下属性:
+
+ - taskCount：线程池需要执行的任务数量
+ - completedTaskCount：线程池在运行过程中已完成的任务数量，小于或等于taskCount。
+ - largestPoolSize：线程池里曾经创建过的最大线程数量.通过这个数据可以知道线程池是否曾经满过.如该数值等于线程池的最大大小,则表示线程池曾经满过.
+ - getPoolSize：线程池的线程数量.如果线程池不销毁的话,线程池里的线程不会自动销毁，所以这个大小只增不减.
+ - getActiveCount：获取活动的线程数.
+
+通过扩展线程池进行监控.可以通过继承线程池来自定义线程池,重写线程池的
+beforeExecute、afterExecute和terminated方法,也可以在任务执行前、执行后和线程池关闭前执行一些代码来进行监控.例如,监控任务的平均执行时间、最大执行时间和最小执行时间等.
+这几个方法在线程池里是空方法.
+
+```
+protected void beforeExecute(Thread t, Runnable r) { }
+```
+## 2.6 线程池的状态 
+1.当线程池创建后，初始为 running 状态 
+2.调用 shutdown 方法后，处 shutdown 状态，此时不再接受新的任务，等待已有的任务执行完毕 
+3.调用 shutdownnow 方法后，进入 stop 状态，不再接受新的任务，并且会尝试终止正在执行的任务。 
+4.当处于 shotdown 或 stop 状态，并且所有工作线程已经销毁，任务缓存队列已清空，线程池被设为 terminated 状态。 
+
+#总结
+## java 线程池有哪些关键属性？
+- corePoolSize 到 maximumPoolSize 之间的线程会被回收，当然 corePoolSize 的线程也可以通过设置而得到回收（allowCoreThreadTimeOut(true)）。
+- workQueue 用于存放任务，添加任务的时候，如果当前线程数超过了 corePoolSize，那么往该队列中插入任务，线程池中的线程会负责到队列中拉取任务。
+- keepAliveTime 用于设置空闲时间，如果线程数超出了 corePoolSize，并且有些线程的空闲时间超过了这个值，会执行关闭这些线程的操作
+- rejectedExecutionHandler 用于处理当线程池不能执行此任务时的情况，默认有抛出 RejectedExecutionException 异常、忽略任务、使用提交任务的线程来执行此任务和将队列中等待最久的任务删除，然后提交此任务这四种策略，默认为抛出异常。
+##线程池中的线程创建时机？
+- 如果当前线程数少于 corePoolSize，那么提交任务的时候创建一个新的线程，并由这个线程执行这个任务；
+- 如果当前线程数已经达到 corePoolSize，那么将提交的任务添加到队列中，等待线程池中的线程去队列中取任务；
+- 如果队列已满，那么创建新的线程来执行任务，需要保证池中的线程数不会超过 maximumPoolSize，如果此时线程数超过了 maximumPoolSize，那么执行拒绝策略。
+
+##任务执行过程中发生异常怎么处理？
+如果某个任务执行出现异常，那么执行任务的线程会被关闭，而不是继续接收其他任务。然后会启动一个新的线程来代替它。
+
+##什么时候会执行拒绝策略？
+- workers 的数量达到了 corePoolSize，任务入队成功，以此同时线程池被关闭了，而且关闭线程池并没有将这个任务出队，那么执行拒绝策略。这里说的是非常边界的问题，入队和关闭线程池并发执行，读者仔细看看 execute 方法是怎么进到第一个 reject(command) 里面的。
+- workers 的数量大于等于 corePoolSize，准备入队，可是队列满了，任务入队失败，那么准备开启新的线程，可是线程数已经达到 maximumPoolSize，那么执行拒绝策略。
+
+# 参考
+《码出高效》
+<<Java并发编程的艺术>>
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/Java\350\257\255\346\263\225\347\263\226.md" "b/Java/Java\350\257\255\346\263\225\347\263\226.md"
new file mode 100644
index 0000000000..dacb3b9a0b
--- /dev/null
+++ "b/Java/Java\350\257\255\346\263\225\347\263\226.md"
@@ -0,0 +1,27 @@
+#1 泛型与类型擦除
+泛型是JDK 1.5的一项新增特性，它的本质是参数化类型(Parametersized Type) 的应用，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类，接口和方法的创建中, 分別称为泛型类、泛型接口和泛型方法。
+
+在Java语言处于还没有出现泛型的版本时。只能通过Object 是所有类型的父类和类型强制转换两个特点的配合来实现类型泛化。例如，在哈希表的存取中,JDK 1.5之前使用HashMap的get() 方法，返回值就是个0bject。由于Java语言里面所有的类型都维承于java.lang.Object 所以Object转型成任何对象都是有可能的。但是也因为有无限的可能性。就只有程序员和运行期的虚拟机才知道这个Objet到底是个什么类型的对象。在编译期间，编译器无法检查这个Object的强制转型是否成功。如果仅仅依赖程序员去保障这项操作的正确性，许多ClassCastException的风险就会转嫁到程予运行期之中。
+
+Java语言中的泛型则不一样，它只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型(Raw Type) ，并且在相应的地方插入了强制转型代码，因此，对于运行期的Java来说Araylist<int>Aralist<String>就是同一个类。所以泛型是Java语言的一颗语法糖Java称为类型擦除，基于这种方法实现的泛型称为伪泛型。
+
+![泛型擦除前的例子](https://upload-images.jianshu.io/upload_images/4685968-2c93db4ccfaf1fc4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+把这段Java代码编译成Class文件，然后再用字节码反编译后，將会发现泛型都不见了，又变回了Java泛型出现之前的写法，泛型类型都变回了原类型.如
+![](https://upload-images.jianshu.io/upload_images/4685968-73b7f4720749ecbb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+通过擦除來实现泛型丧失了一些泛型思想应有的优雅
+![当泛型遇见重载1](https://upload-images.jianshu.io/upload_images/4685968-38a718d9584c5ed6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+不能被编译的，因为参数List<Integer>和List<String>编译之后都被擦除了。变成了一样的原生类型List<E>,擦除动作导致这两种方法的特征签名变得一模一样。初步看来，无法重载的原因已经找到了，但真的就如此吗? 只能说，泛型擦除成相同的原生类型只是无法重载的部分原因
+
+![当泛型遇见置载2](https://upload-images.jianshu.io/upload_images/4685968-f6c1eeaed390cd9a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+由于Java泛型的引入,各种场景(虚拟机解析,反射等> 下的方法调用都可能对原有基础产生影响，如在泛型类中如何获取传入的参数化类型等。因此，JCP组织对虚拟机规范做出了相应的修改，引人了诺如Signature,LocalVariableTypeTable 等新的属性用于解决伴随泛型而来的参数类型的识别问题，Signature 是其中最重要的一项属性,它的作用就是存储一个方法在字节码层面的特征签名,这个属性中保存的参数类型并不是原生类型，而是包括了参数化类型的信息。修改后的虚拟机规范裂水所有能识别49.0以上版本的Class
+文件的虚拟机都要能正确地识别Signature参数.
+
+从Signature属性的出现我们还可以得出结论，所谓的擦除，仅仅是对方法的Code属性中的宇节码进行擦除，实际上元数据还是保留了泛型信息,这也是我们能通过反射取得参数化类型的根本依据。
+![自动装箱: 拆箱与遍历循环](https://upload-images.jianshu.io/upload_images/4685968-2866b12ca5564476.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![自动装箱: 拆箱与遍历循环编译后](https://upload-images.jianshu.io/upload_images/4685968-0433b37de73e7230.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+遍历循环则把代码还原成了迭代器的实现，这也是为何遍历循环需要被遍历的类实现Iterable接口的原因。最后再看看变长参数，它在调用的时候变成了一个数组类型的参数,在变长参数出现之前，程序员就是使用数组来完成类似功能的。
+![](https://upload-images.jianshu.io/upload_images/4685968-7fe6b94f0458dfda.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+
diff --git "a/Java/Java\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220---HashMap.md" "b/Java/Java\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220---HashMap.md"
new file mode 100644
index 0000000000..bd1ea05cb6
--- /dev/null
+++ "b/Java/Java\351\233\206\345\220\210\346\272\220\347\240\201\350\247\243\346\236\220---HashMap.md"
@@ -0,0 +1,714 @@
+# 1 概述
+HashMap是基于哈希表实现的,每一个元素是一个key-value对,其内部通过单链表解决冲突问题,容量不足(超过了阀值)时,同样会自动增长.
+	
+HashMap是非线程安全的,只适用于单线程环境,多线程环境可以采用并发包下的`concurrentHashMap`
+    
+HashMap 实现了Serializable接口，因此它支持序列化，实现了Cloneable接口，能被克隆
+	
+HashMap是基于哈希表的Map接口的非同步实现.此实现提供所有可选的映射操作,并允许使用null值和null键.此类不保证映射的顺序,特别是它不保证该顺序恒久不变.
+	
+Java8中又对此类底层实现进行了优化，比如引入了红黑树的结构以解决哈希碰撞
+　
+# 2 HashMap的数据结构
+在Java中,最基本的结构就是两种,一个是数组,另外一个是模拟指针(引用),所有的数据结构都可以用这两个基本结构来构造,HashMap也不例外.
+HashMap实际上是一个"链表散列"的数据结构,即数组和链表的结合体.
+
+![HashMap的结构](http://upload-images.jianshu.io/upload_images/4685968-cd353393ebc2ddf7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+HashMap的主结构类似于一个数组,添加值时通过`key`确定储存位置.
+每个位置是一个Entry的数据结构,该结构可组成链表.
+当发生冲突时,相同hash值的键值对会组成链表.
+这种`数组+链表`的组合形式大部分情况下都能有不错的性能效果,Java6、7就是这样设计的.
+然而,在极端情况下,一组（比如经过精心设计的）键值对都发生了冲突，这时的哈希结构就会退化成一个链表，使HashMap性能急剧下降.
+
+所以在Java8中,HashMap的结构实现变为数组+链表+红黑树
+![Java8 HashMap的结构](https://upload-images.jianshu.io/upload_images/4685968-0e08421c5183e8ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+可以看出,HashMap底层就是一个数组结构
+数组中的每一项又是一个链表
+当新建一个HashMap时,就会初始化一个数组.
+
+# 3 三大集合与迭代子
+HashMap使用三大集合和三种迭代子来轮询其Key、Value和Entry对象
+```
+public class HashMapExam {
+    public static void main(String[] args) {
+        Map<Integer, String> map = new HashMap<>(16);
+        for (int i = 0; i < 15; i++) {
+            map.put(i, new String(new char[]{(char) ('A'+ i)}));
+        }
+
+        System.out.println("======keySet=======");
+        Set<Integer> set = map.keySet();
+        Iterator<Integer> iterator = set.iterator();
+        while (iterator.hasNext()) {
+            System.out.println(iterator.next());
+        }
+
+        System.out.println("======values=======");
+        Collection<String> values = map.values();
+        Iterator<String> stringIterator=values.iterator();
+        while (stringIterator.hasNext()) {
+            System.out.println(stringIterator.next());
+        }
+
+        System.out.println("======entrySet=======");
+        for (Map.Entry<Integer, String> entry : map.entrySet()) {
+            System.out.println(entry);
+        }
+    }
+}
+```
+
+# 4 源码分析
+```    
+    //默认的初始容量16,且实际容量是2的整数幂 
+    static final int DEFAULT_INITIAL_CAPACITY = 1 << 4;
+    
+    //最大容量(传入容量过大将被这个值替换)
+    static final int MAXIMUM_CAPACITY = 1 << 30;
+     
+    // 默认加载因子为0.75(当表达到3/4满时,才会再散列),这个因子在时间和空间代价之间达到了平衡.更高的因子可以降低表所需的空间,但是会增加查找代价,而查找是最频繁操作
+    static final float DEFAULT_LOAD_FACTOR = 0.75f;
+
+	//桶的树化阈值：即 链表转成红黑树的阈值，在存储数据时，当链表长度 >= 8时，则将链表转换成红黑树
+    static final int TREEIFY_THRESHOLD = 8;
+   // 桶的链表还原阈值：即 红黑树转为链表的阈值，当在扩容（resize（））时（HashMap的数据存储位置会重新计算），在重新计算存储位置后，当原有的红黑树内数量 <= 6时，则将 红黑树转换成链表
+    static final int UNTREEIFY_THRESHOLD = 6;
+   //最小树形化容量阈值：即 当哈希表中的容量 > 该值时，才允许树形化链表 （即 将链表 转换成红黑树）
+```
+因为红黑树的平均查找长度是log(n)，长度为8的时候，平均查找长度为3，如果继续使用链表，平均查找长度为8/2=4，这才有转换为树的必要
+链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短
+
+还有选择6和8，中间有个差值7可以有效防止链表和树频繁转换
+假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。
+```
+    // 为了避免扩容/树形化选择的冲突，这个值不能小于 4 * TREEIFY_THRESHOLD
+    // 小于该值时使用的是扩容哦!!!
+    static final int MIN_TREEIFY_CAPACITY = 64;
+    
+    // 存储数据的Node数组,长度是2的幂.    
+    // HashMap采用链表法解决冲突，每一个Node本质上是一个单向链表 
+    //HashMap底层存储的数据结构,是一个Node数组.上面得知Node类为元素维护了一个单向链表.至此,HashMap存储的数据结构也就很清晰了:维护了一个数组,每个数组又维护了一个单向链表.之所以这么设计,考虑到遇到哈希冲突的时候,同index的value值就用单向链表来维护
+    //与 JDK 1.7 的对比（Entry类），仅仅只是换了名字
+    transient Node<K,V>[] table;
+
+    // HashMap的底层数组中已用槽的数量 
+    transient int size;
+    // HashMap的阈值，用于判断是否需要调整HashMap的容量（threshold = 容量*加载因子） 
+    int threshold;
+    
+    // 负载因子实际大小
+    final float loadFactor;
+    
+    // HashMap被改变的次数 
+    transient int modCount;
+    
+    // 指定“容量大小”和“加载因子”的构造函数,是最基础的构造函数
+    public HashMap(int initialCapacity, float loadFactor) {
+        if (initialCapacity < 0)
+            throw new IllegalArgumentException("Illegal initial capacity: " +
+                                               initialCapacity);
+        // HashMap的最大容量只能是MAXIMUM_CAPACITY                                       
+        if (initialCapacity > MAXIMUM_CAPACITY)
+            initialCapacity = MAXIMUM_CAPACITY;
+        //负载因子须大于0
+        if (loadFactor <= 0 || Float.isNaN(loadFactor))
+            throw new IllegalArgumentException("Illegal load factor: " +
+                                               loadFactor);
+        // 设置"负载因子"                                        
+        this.loadFactor = loadFactor;
+        // 设置"HashMap阈值",当HashMap中存储数据的数量达到threshold时,就需将HashMap的容量加倍    
+        this.threshold = tableSizeFor(initialCapacity);
+    }
+```
+
+- 上面的tableSizeFor有何用?
+tableSizeFor方法保证函数返回值是大于等于给定参数initialCapacity最小的2的幂次方的数值
+```
+    static final int tableSizeFor(int cap) {
+        int n = cap - 1;
+        n |= n >>> 1;
+        n |= n >>> 2;
+        n |= n >>> 4;
+        n |= n >>> 8;
+        n |= n >>> 16;
+        return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
+    }
+```
+ 可以看出该方法是一系列的二进制位操作
+
+>a |= b 等同于 a = a|b
+
+逐行分析
+- `int n = cap - 1`
+给定的cap 减 1,为了避免参数cap本来就是2的幂次方,这样一来,经过后续操作，cap将会变成2 * cap,是不符合我们预期的
+
+- `n |= n >>> 1`
+n >>> 1 : n无符号右移1位,即n二进制最高位的1右移一位
+n | (n >>> 1) 导致 n二进制的高2位值为1
+目前n的高1~2位均为1
+- `n |= n >>> 2`
+n继续无符号右移2位
+n | (n >>> 2) 导致n二进制表示的高3~4位经过运算值均为1
+目前n的高1~4位均为1
+- `n |= n >>> 4`
+n继续无符号右移4位
+n | (n >>> 4) 导致n二进制表示的高5~8位经过运算值均为1
+目前n的高1~8位均为1
+- `n |= n >>> 8`
+n继续无符号右移8位
+n | (n >>> 8) 导致n二进制表示的高9~16位经过运算值均为1
+目前n的高1~16位均为1	
+
+可以看出,无论给定cap(cap < MAXIMUM_CAPACITY )的值是多少,经过以上运算,其值的二进制所有位都会是1.再将其加1,这时候这个值一定是2的幂次方.
+当然如果经过运算值大于MAXIMUM_CAPACITY,直接选用MAXIMUM_CAPACITY.
+![例子](http://upload-images.jianshu.io/upload_images/4685968-ffb968a6b1a70fa9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+至此tableSizeFor如何保证cap为2的幂次方已经显而易见了,那么问题来了
+
+## 4.1 **为什么cap要保持为2的幂次方？**
+主要与HashMap中的数据存储有关.
+
+在Java8中,HashMap中key的Hash值由Hash(key)方法计得
+![](https://upload-images.jianshu.io/upload_images/4685968-e8540295874593d7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+HashMap中存储数据table的index是由key的Hash值决定的.
+在HashMap存储数据时,我们期望数据能均匀分布,以防止哈希冲突.
+自然而然我们就会想到去用`%`取余操作来实现我们这一构想
+
+>取余(%)操作 : 如果除数是2的幂次则等价于与其除数减一的与(&)操作.
+
+这也就解释了为什么一定要求cap要为2的幂次方.再来看看table的index的计算规则：
+![](https://upload-images.jianshu.io/upload_images/4685968-ddd3a2805bea14c4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ 等价于:
+```
+ index = e.hash % newCap
+```
+采用二进制位操作&,相对于%,能够提高运算效率,这就是cap的值被要求为2幂次的原因
+![](https://upload-images.jianshu.io/upload_images/4685968-5b47864c20546b8d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![数据结构 & 参数与 JDK 7 / 8](https://upload-images.jianshu.io/upload_images/4685968-80fbc4a63ab41290.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 4.2 **Node类**
+
+```
+static class Node<K,V> implements Map.Entry<K,V> {
+        final int hash;
+        final K key;
+        V value;
+        Node<K,V> next;
+
+        Node(int hash, K key, V value, Node<K,V> next) {
+            this.hash = hash;
+            this.key = key;
+            this.value = value;
+            this.next = next;
+        }
+
+        public final K getKey()        { return key; }
+        public final V getValue()      { return value; }
+        public final String toString() { return key + "=" + value; }
+
+        public final int hashCode() {
+            return Objects.hashCode(key) ^ Objects.hashCode(value);
+        }
+
+        public final V setValue(V newValue) {
+            V oldValue = value;
+            value = newValue;
+            return oldValue;
+        }
+
+        public final boolean equals(Object o) {
+            if (o == this)
+                return true;
+            if (o instanceof Map.Entry) {
+                Map.Entry<?,?> e = (Map.Entry<?,?>)o;
+                if (Objects.equals(key, e.getKey()) &&
+                    Objects.equals(value, e.getValue()))
+                    return true;
+            }
+            return false;
+        }
+    }
+```
+Node<K,V> 类是HashMap中的静态内部类,实现Map.Entry<K,V>接口.定义了key键、value值、next节点,也就是说元素之间构成了单向链表.
+
+## 4.3 TreeNode
+```
+static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
+        TreeNode<K,V> parent;  // red-black tree links
+        TreeNode<K,V> left;
+        TreeNode<K,V> right;
+        TreeNode<K,V> prev;    // needed to unlink next upon deletion
+        boolean red;
+        TreeNode(int hash, K key, V val, Node<K,V> next) {}
+
+        // 返回当前节点的根节点  
+        final TreeNode<K,V> root() {  
+          for (TreeNode<K,V> r = this, p;;) {  
+            if ((p = r.parent) == null)  
+                return r;  
+            r = p;  
+        }  
+    } 
+ }
+```
+红黑树结构包含前、后、左、右节点，以及标志是否为红黑树的字段
+此结构是Java8新加的
+
+## 4.4 hash方法
+Java 8中的散列值优化函数
+![](https://upload-images.jianshu.io/upload_images/4685968-2c057211c7051fd9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+只做一次16位右位移异或
+key.hashCode()函数调用的是key键值类型自带的哈希函数，返回int型散列值
+
+理论上散列值是一个int型，如果直接拿散列值作为下标访问HashMap主数组的话，考虑到2进制32位带符号的int范围大概40亿的映射空间。只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。
+但问题是一个40亿长度的数组，内存是放不下的.HashMap扩容之前的数组初始大小才16,所以这个散列值是不能直接拿来用的.
+用之前还要先做对数组的长度取模运算，得到的余数才能用来访问数组下标
+源码中模运算就是把散列值和数组长度做一个"与"操作，
+![](https://upload-images.jianshu.io/upload_images/4685968-4fcd8fe2039d26c5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+这也正好解释了为什么HashMap的数组长度要取2的整次幂
+因为这样（数组长度-1）正好相当于一个“低位掩码”
+“与”操作的结果就是散列值的高位全部归零，只保留低位值，用来做数组下标访问
+
+以初始长度16为例，16-1=15
+2进制表示是00000000 00000000 00001111
+和某散列值做“与”操作如下，结果就是截取了最低的四位值
+![](https://upload-images.jianshu.io/upload_images/4685968-89fececc1ca1c0b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+但这时候问题就来了,这样就算我的散列值分布再松散,要是只取最后几位的话,碰撞也会很严重
+
+这时候“扰动函数”的价值就体现出来了
+![](https://upload-images.jianshu.io/upload_images/4685968-4825a9e897a9723b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+右位移16位，正好是32位一半，自己的高半区和低半区做异或，就是为了混合原始hashCode的高位和低位，以此来加大低位的随机性
+而且混合后的低位掺杂了高位的部分特征，这样高位的信息也被变相保留下来。
+
+index的运算规则是
+```
+e.hash & (newCap - 1)
+```
+newCap是2的幂,所以newCap - 1的高位全0
+
+若e.hash值只用自身的hashcode,index只会和e.hash的低位做&操作.这样一来,index的值就只有低位参与运算,高位毫无存在感,从而会带来哈希冲突的风险
+所以在计算key的hashCode时,用其自身hashCode与其低16位做异或操作
+这也就让高位参与到index的计算中来了,即降低了哈希冲突的风险又不会带来太大的性能问题
+
+## 4.5 Put方法
+![](https://upload-images.jianshu.io/upload_images/4685968-ac54873c0837d3ba.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![](https://upload-images.jianshu.io/upload_images/4685968-76c3c90239e1f15e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![HashMap-put(k,v)](http://upload-images.jianshu.io/upload_images/4685968-0ccc069e89b40e4c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+①.判断键值对数组table[i]是否为空或为null，否则执行resize()进行扩容
+
+②.根据键值key计算hash值得到插入的数组索引i，如果table[i]==null，直接新建节点添加，转向⑥，如果table[i]不为空，转向③
+
+③.判断table[i]的首个元素是否和key一样，如果相同直接覆盖value，否则转向④，这里的相同指的是hashCode以及equals
+
+④.判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对，否则转向⑤
+
+⑤.遍历table[i]，判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操作，否则进行链表的插入操作；遍历过程中若发现key已经存在直接覆盖value即可
+
+⑥.插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold，如果超过，执行resize()扩容
+```
+ public V put(K key, V value) {
+        // 对key的hashCode()做hash
+        return putVal(hash(key), key, value, false, true);
+    }
+    
+final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
+        Node<K,V>[] tab; Node<K,V> p; int n, i;
+        // 步骤① tab为空则调用resize()初始化创建
+        if ((tab = table) == null || (n = tab.length) == 0)         
+            n = (tab = resize()).length;
+        // 步骤② 计算index,并对null做处理  
+        //tab[i = (n - 1) & hash对应下标的第一个节点   
+        if ((p = tab[i = (n - 1) & hash]) == null)
+            // 无哈希冲突的情况下,将value直接封装为Node并赋值
+            tab[i] = newNode(hash, key, value, null);
+        else {
+            Node<K,V> e; K k;
+            // 步骤③ 节点的key相同,直接覆盖节点
+            if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))
+                e = p;
+            // 步骤④ 判断该链为红黑树    
+            else if (p instanceof TreeNode)
+                 // p是红黑树类型，则调用putTreeVal方式赋值
+                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
+            // 步骤⑤ p非红黑树类型,该链为链表    
+            else {
+                // index 相同的情况下
+                for (int binCount = 0; ; ++binCount) {
+                    if ((e = p.next) == null) {
+                        // 如果p的next为空,将新的value值添加至链表后面
+                        p.next = newNode(hash, key, value, null);
+                        if (binCount >= TREEIFY_THRESHOLD - 1)
+                            // 如果链表长度大于8,链表转化为红黑树,执行插入
+                            treeifyBin(tab, hash);
+                        break;
+                    }
+                    // key相同则跳出循环
+                    if (e.hash == hash &&  ((k = e.key) == key || (key != null && key.equals(k))))
+                        break;
+                    //就是移动指针方便继续取 p.next
+    
+                    p = e;
+                }
+            }
+            if (e != null) { // existing mapping for key
+                V oldValue = e.value;
+                //根据规则选择是否覆盖value
+                if (!onlyIfAbsent || oldValue == null)
+                    e.value = value;
+                afterNodeAccess(e);
+                return oldValue;
+            }
+        }
+        ++modCount;
+        // 步骤⑥:超过最大容量,就扩容
+        if (++size > threshold)
+            // size大于加载因子,扩容
+            resize();
+        afterNodeInsertion(evict);
+        return null;
+    }
+```
+在构造函数中最多也只是设置了initialCapacity、loadFactor的值,并没有初始化table,table的初始化工作是在put方法中进行的.
+## 4.6 resize
+![](https://upload-images.jianshu.io/upload_images/4685968-fd60bec62611e900.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+扩容(resize)就是重新计算容量,向HashMap对象里不停的添加元素,内部的数组无法装载更多的元素时,就需要扩大数组的长度.
+当然Java里的数组是无法自动扩容的,方法是使用一个新的数组代替已有的容量小的数组
+```
+   /**
+     * 该函数有2种使用情况：1.初始化哈希表 2.当前数组容量过小，需扩容
+     */
+final Node<K,V>[] resize() {
+        Node<K,V>[] oldTab = table;
+        int oldCap = (oldTab == null) ? 0 : oldTab.length;
+        int oldThr = threshold;
+        int newCap, newThr = 0;
+
+        // 针对情况2：若扩容前的数组容量超过最大值，则不再扩充
+        if (oldCap > 0) {
+            if (oldCap >= MAXIMUM_CAPACITY) {
+                threshold = Integer.MAX_VALUE;
+                return oldTab;
+            }
+            // 针对情况2：若无超过最大值，就扩充为原来的2倍
+            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
+                     oldCap >= DEFAULT_INITIAL_CAPACITY)
+                //newCap设置为oldCap的2倍并小于MAXIMUM_CAPACITY，且大于默认值, 新的threshold增加为原来的2倍
+                newThr = oldThr << 1; // double threshold
+        }
+     
+        // 针对情况1：初始化哈希表（采用指定 or 默认值）
+        else if (oldThr > 0) // initial capacity was placed in threshold
+            // threshold>0, 将threshold设置为newCap,所以要用tableSizeFor方法保证threshold是2的幂次方
+            newCap = oldThr;
+        else {               // zero initial threshold signifies using defaults
+            // 默认初始化
+            newCap = DEFAULT_INITIAL_CAPACITY;
+            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
+        }
+
+        // 计算新的resize上限
+        if (newThr == 0) {
+            // newThr为0，newThr = newCap * 0.75
+            float ft = (float)newCap * loadFactor;
+            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
+                      (int)ft : Integer.MAX_VALUE);
+        }
+        threshold = newThr;
+        @SuppressWarnings({"rawtypes","unchecked"})
+            // 新生成一个table数组
+            Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
+        table = newTab;
+        if (oldTab != null) {
+            // oldTab 复制到 newTab
+            for (int j = 0; j < oldCap; ++j) {
+                Node<K,V> e;
+                if ((e = oldTab[j]) != null) {
+                    oldTab[j] = null;
+                    if (e.next == null)
+                       // 链表只有一个节点，直接赋值
+                       //为什么要重新Hash呢？因为长度扩大以后，Hash的规则也随之改变。
+                        newTab[e.hash & (newCap - 1)] = e;
+                    else if (e instanceof TreeNode)
+                        // e为红黑树的情况
+                        ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
+                    else { // preserve order链表优化重hash的代码块
+                        Node<K,V> loHead = null, loTail = null;
+                        Node<K,V> hiHead = null, hiTail = null;
+                        Node<K,V> next;
+                        do {
+                            next = e.next;
+                            // 原索引
+                            if ((e.hash & oldCap) == 0) {
+                                if (loTail == null)
+                                    loHead = e;
+                                else
+                                    loTail.next = e;
+                                loTail = e;
+                            }
+                            // 原索引 + oldCap
+                            else {
+                                if (hiTail == null)
+                                    hiHead = e;
+                                else
+                                    hiTail.next = e;
+                                hiTail = e;
+                            }
+                        } while ((e = next) != null);
+                        // 原索引放到bucket里
+                        if (loTail != null) {
+                            loTail.next = null;
+                            newTab[j] = loHead;
+                        }
+                        // 原索引+oldCap放到bucket里
+                        if (hiTail != null) {
+                            hiTail.next = null;
+                            newTab[j + oldCap] = hiHead;
+                        }
+                    }
+                }
+            }
+        }
+        return newTab;
+    }
+```
+![图片发自简书App](http://upload-images.jianshu.io/upload_images/4685968-3edeccbe9811a4c3.jpg)
+
+
+
+## 4.7 remove方法
+remove(key) 方法 和 remove(key, value) 方法都是通过调用removeNode的方法来实现删除元素的
+```
+ final Node<K,V> removeNode(int hash, Object key, Object value,
+                               boolean matchValue, boolean movable) {
+        Node<K,V>[] tab; Node<K,V> p; int n, index;
+        if ((tab = table) != null && (n = tab.length) > 0 &&
+            (p = tab[index = (n - 1) & hash]) != null) {
+            Node<K,V> node = null, e; K k; V v;
+            if (p.hash == hash &&
+                ((k = p.key) == key || (key != null && key.equals(k))))
+                // index 元素只有一个元素
+                node = p;
+            else if ((e = p.next) != null) {
+                if (p instanceof TreeNode)
+                    // index处是一个红黑树
+                    node = ((TreeNode<K,V>)p).getTreeNode(hash, key);
+                else {
+                    // index处是一个链表，遍历链表返回node
+                    do {
+                        if (e.hash == hash &&
+                            ((k = e.key) == key ||
+                             (key != null && key.equals(k)))) {
+                            node = e;
+                            break;
+                        }
+                        p = e;
+                    } while ((e = e.next) != null);
+                }
+            }
+            // 分不同情形删除节点
+            if (node != null && (!matchValue || (v = node.value) == value ||
+                                 (value != null && value.equals(v)))) {
+                if (node instanceof TreeNode)
+                    ((TreeNode<K,V>)node).removeTreeNode(this, tab, movable);
+                else if (node == p)
+                    tab[index] = node.next;
+                else
+                    p.next = node.next;
+                ++modCount;
+                --size;
+                afterNodeRemoval(node);
+                return node;
+            }
+        }
+        return null;
+    }
+```
+## 4.8 get
+```
+/**
+   * 函数原型
+   * 作用：根据键key，向HashMap获取对应的值
+   */ 
+   map.get(key)；
+
+
+ /**
+   * 源码分析
+   */ 
+   public V get(Object key) {
+    Node<K,V> e;
+    // 1. 计算需获取数据的hash值
+    // 2. 通过getNode（）获取所查询的数据 ->>分析1
+    // 3. 获取后，判断数据是否为空
+    return (e = getNode(hash(key), key)) == null ? null : e.value;
+}
+
+/**
+   * 分析1：getNode(hash(key), key))
+   */ 
+final Node<K,V> getNode(int hash, Object key) {
+    Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
+
+    // 1. 计算存放在数组table中的位置
+    if ((tab = table) != null && (n = tab.length) > 0 &&
+        (first = tab[(n - 1) & hash]) != null) {
+
+        // 4. 通过该函数，依次在数组、红黑树、链表中查找（通过equals（）判断）
+        // a. 先在数组中找，若存在，则直接返回
+        if (first.hash == hash && // always check first node
+            ((k = first.key) == key || (key != null && key.equals(k))))
+            return first;
+
+        // b. 若数组中没有，则到红黑树中寻找
+        if ((e = first.next) != null) {
+            // 在树中get
+            if (first instanceof TreeNode)
+                return ((TreeNode<K,V>)first).getTreeNode(hash, key);
+
+            // c. 若红黑树中也没有，则通过遍历，到链表中寻找
+            do {
+                if (e.hash == hash &&
+                    ((k = e.key) == key || (key != null && key.equals(k))))
+                    return e;
+            } while ((e = e.next) != null);
+        }
+    }
+    return null;
+}
+```
+> 在JDK1.7及以前的版本中，HashMap里是没有红黑树的实现的，在JDK1.8中加入了红黑树是为了防止哈希表碰撞攻击，当链表链长度为8时，及时转成红黑树，提高map的效率
+
+如果某个桶中的记录过大的话（当前是TREEIFY_THRESHOLD = 8），HashMap会动态的使用一个专门的treemap实现来替换掉它。这样做的结果会更好，是O(logn)，而不是糟糕的O(n)。它是如何工作的？
+前面产生冲突的那些KEY对应的记录只是简单的追加到一个链表后面，这些记录只能通过遍历来进行查找。但是超过这个阈值后HashMap开始将列表升级成一个二叉树，使用哈希值作为树的分支变量，如果两个哈希值不等，但指向同一个桶的话，较大的那个会插入到右子树里。如果哈希值相等，HashMap希望key值最好是实现了Comparable接口的，这样它可以按照顺序来进行插入。这对HashMap的key来说并不是必须的，不过如果实现了当然最好。如果没有实现这个接口，在出现严重的哈希碰撞的时候，你就并别指望能获得性能提升了。
+
+这个性能提升有什么用处？比方说恶意的程序，如果它知道我们用的是哈希算法，它可能会发送大量的请求，导致产生严重的哈希碰撞。然后不停的访问这些key就能显著的影响服务器的性能，这样就形成了一次拒绝服务攻击（DoS）。JDK 8中从O(n)到O(logn)的飞跃，可以有效地防止类似的攻击，同时也让HashMap性能的可预测性稍微增强了一些
+```
+/**
+   * 源码分析：resize(2 * table.length)
+   * 作用：当容量不足时（容量 > 阈值），则扩容（扩到2倍）
+   */ 
+   void resize(int newCapacity) {  
+
+    // 1. 保存旧数组（old table） 
+    Entry[] oldTable = table;  
+
+    // 2. 保存旧容量（old capacity ），即数组长度
+    int oldCapacity = oldTable.length; 
+
+    // 3. 若旧容量已经是系统默认最大容量了，那么将阈值设置成整型的最大值，退出    
+    if (oldCapacity == MAXIMUM_CAPACITY) {  
+        threshold = Integer.MAX_VALUE;  
+        return;  
+    }  
+
+    // 4. 根据新容量（2倍容量）新建1个数组，即新table  
+    Entry[] newTable = new Entry[newCapacity];  
+
+    // 5. （重点分析）将旧数组上的数据（键值对）转移到新table中，从而完成扩容 ->>分析1.1 
+    transfer(newTable); 
+
+    // 6. 新数组table引用到HashMap的table属性上
+    table = newTable;  
+
+    // 7. 重新设置阈值  
+    threshold = (int)(newCapacity * loadFactor); 
+} 
+
+ /**
+   * 分析1.1：transfer(newTable); 
+   * 作用：将旧数组上的数据（键值对）转移到新table中，从而完成扩容
+   * 过程：按旧链表的正序遍历链表、在新链表的头部依次插入
+   */ 
+void transfer(Entry[] newTable) {
+      // 1. src引用了旧数组
+      Entry[] src = table; 
+
+      // 2. 获取新数组的大小 = 获取新容量大小                 
+      int newCapacity = newTable.length;
+
+      // 3. 通过遍历 旧数组，将旧数组上的数据（键值对）转移到新数组中
+      for (int j = 0; j < src.length; j++) { 
+          // 3.1 取得旧数组的每个元素  
+          Entry<K,V> e = src[j];           
+          if (e != null) {
+              // 3.2 释放旧数组的对象引用（for循环后，旧数组不再引用任何对象）
+              src[j] = null; 
+
+              do { 
+                  // 3.3 遍历 以该数组元素为首 的链表
+                  // 注：转移链表时，因是单链表，故要保存下1个结点，否则转移后链表会断开
+                  Entry<K,V> next = e.next; 
+                 // 3.3 重新计算每个元素的存储位置
+                 int i = indexFor(e.hash, newCapacity); 
+                 // 3.4 将元素放在数组上：采用单链表的头插入方式 = 在链表头上存放数据 = 将数组位置的原有数据放在后1个指针、将需放入的数据放到数组位置中
+                 // 即 扩容后，可能出现逆序：按旧链表的正序遍历链表、在新链表的头部依次插入
+                 e.next = newTable[i]; 
+                 newTable[i] = e;  
+                 // 访问下1个Entry链上的元素，如此不断循环，直到遍历完该链表上的所有节点
+                 e = next;             
+             } while (e != null);
+             // 如此不断循环，直到遍历完数组上的所有数据元素
+         }
+     }
+ }
+```
+从上面可看出：在扩容resize（）过程中，在将旧数组上的数据 转移到 新数组上时，转移数据操作 = 按旧链表的正序遍历链表、在新链表的头部依次插入，即在转移数据、扩容后，容易出现链表逆序的情况
+
+>`设重新计算存储位置后不变，即扩容前 = 1->2->3，扩容后 = 3->2->1`
+
+此时若并发执行 put 操作，一旦出现扩容情况，则 容易出现 环形链表，从而在获取数据、遍历链表时 形成死循环（Infinite Loop），即死锁
+![](https://upload-images.jianshu.io/upload_images/4685968-f0fc8abf5588bda4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![image.png](https://upload-images.jianshu.io/upload_images/4685968-33e1eb8ca4751050.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-52f69ae7fb5284dc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![为什么 HashMap 中 String、Integer 这样的包装类适合作为 key 键](https://upload-images.jianshu.io/upload_images/4685968-7ab28eced8714fe6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 单线程rehash
+单线程情况下，rehash无问题
+[![HashMap rehash single thread](http://upload-images.jianshu.io/upload_images/4685968-a36b5a282b6ffefa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](http://www.jasongj.com/img/java/concurrenthashmap/single_thread_rehash.png)
+# 多线程并发下的rehash
+
+这里假设有两个线程同时执行了put操作并引发了rehash，执行了transfer方法，并假设线程一进入transfer方法并执行完next = e.next后，因为线程调度所分配时间片用完而“暂停”，此时线程二完成了transfer方法的执行。此时状态如下。
+
+[![HashMap rehash multi thread step 1](http://upload-images.jianshu.io/upload_images/4685968-c68bf4c25dfd8f2d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](http://www.jasongj.com/img/java/concurrenthashmap/multi_thread_rehash_1.png)
+接着线程1被唤醒，继续执行第一轮循环的剩余部分
+```
+e.next = newTable[1] = null
+newTable[1] = e = key(5)
+e = next = key(9)
+```
+结果如下图所示
+[![HashMap rehash multi thread step 2](http://upload-images.jianshu.io/upload_images/4685968-39e50bf8b6272f1d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](http://www.jasongj.com/img/java/concurrenthashmap/multi_thread_rehash_2.png) 
+
+接着执行下一轮循环，结果状态图如下所示
+[![HashMap rehash multi thread step 3](http://upload-images.jianshu.io/upload_images/4685968-4d3ecfe9177c8ec5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](http://www.jasongj.com/img/java/concurrenthashmap/multi_thread_rehash_3.png) 
+
+继续下一轮循环，结果状态图如下所示
+[![HashMap rehash multi thread step 4](http://upload-images.jianshu.io/upload_images/4685968-14ed3884c7e20cd0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](http://www.jasongj.com/img/java/concurrenthashmap/multi_thread_rehash_4.png) 
+
+此时循环链表形成，并且key(11)无法加入到线程1的新数组。在下一次访问该链表时会出现死循环。
+# Fast-fail
+### [](http://www.jasongj.com/java/concurrenthashmap/#%E4%BA%A7%E7%94%9F%E5%8E%9F%E5%9B%A0 "产生原因")产生原因
+
+在使用迭代器的过程中如果HashMap被修改，那么`ConcurrentModificationException`将被抛出，也即Fast-fail策略。
+
+当HashMap的iterator()方法被调用时，会构造并返回一个新的EntryIterator对象，并将EntryIterator的expectedModCount设置为HashMap的modCount（该变量记录了HashMap被修改的次数）。
+```
+HashIterator() {
+  expectedModCount = modCount;
+  if (size > 0) { // advance to first entry
+  Entry[] t = table;
+  while (index < t.length && (next = t[index++]) == null)
+    ;
+  }
+}
+```
+
+
+在通过该Iterator的next方法访问下一个Entry时，它会先检查自己的expectedModCount与HashMap的modCount是否相等，如果不相等，说明HashMap被修改，直接抛出`ConcurrentModificationException`。该Iterator的remove方法也会做类似的检查。该异常的抛出意在提醒用户及早意识到线程安全问题。
+
+### [](http://www.jasongj.com/java/concurrenthashmap/#%E7%BA%BF%E7%A8%8B%E5%AE%89%E5%85%A8%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88 "线程安全解决方案")线程安全解决方案
+
+单线程条件下，为避免出现`ConcurrentModificationException`，需要保证只通过HashMap本身或者只通过Iterator去修改数据，不能在Iterator使用结束之前使用HashMap本身的方法修改数据。因为通过Iterator删除数据时，HashMap的modCount和Iterator的expectedModCount都会自增，不影响二者的相等性。如果是增加数据，只能通过HashMap本身的方法完成，此时如果要继续遍历数据，需要重新调用iterator()方法从而重新构造出一个新的Iterator，使得新Iterator的expectedModCount与更新后的HashMap的modCount相等。
+
+多线程条件下，可使用`Collections.synchronizedMap`方法构造出一个同步Map，或者直接使用线程安全的ConcurrentHashMap。
+
diff --git "a/Java/Spring Boot/SpringBoot+Security-\345\217\221\351\200\201\347\237\255\344\277\241\351\252\214\350\257\201\347\240\201.md" "b/Java/Spring Boot/SpringBoot+Security-\345\217\221\351\200\201\347\237\255\344\277\241\351\252\214\350\257\201\347\240\201.md"
new file mode 100644
index 0000000000..55fbf4bdda
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot+Security-\345\217\221\351\200\201\347\237\255\344\277\241\351\252\214\350\257\201\347\240\201.md"	
@@ -0,0 +1,12 @@
+#在core模块下properties包中创建SmsCodeProperties
+![](https://upload-images.jianshu.io/upload_images/4685968-46c982a0460868e5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#在ValidateCodeProperties中new一个SmsCodeProperties对象，并实现getter、setter方法
+![](https://upload-images.jianshu.io/upload_images/4685968-0557bfffe3b274ba.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#在core模块下validate包中创建SmsCodeGenerator实现ValidateCodeGenerator接口
+
+#创建SmsCodeSender接口，定义发送短信的抽象方法
+![](https://upload-images.jianshu.io/upload_images/4685968-0efa986e2ff67784.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+实现SmsCodeSender接口
+![](https://upload-images.jianshu.io/upload_images/4685968-342dfb15f354e35b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+在ValidateCodeBeanConfig中把SmsCodeSenderImpl注入到容器中
+![](https://upload-images.jianshu.io/upload_images/4685968-3e1b6cd36d038543.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Boot/SpringBoot-\344\270\211\345\244\247\345\237\272\346\234\254\346\263\250\350\247\243.md" "b/Java/Spring Boot/SpringBoot-\344\270\211\345\244\247\345\237\272\346\234\254\346\263\250\350\247\243.md"
new file mode 100644
index 0000000000..40f06d6ca4
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot-\344\270\211\345\244\247\345\237\272\346\234\254\346\263\250\350\247\243.md"	
@@ -0,0 +1,19 @@
+# 1 @RestController
+![](https://upload-images.jianshu.io/upload_images/4685968-2598be573b324d42.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+该注解被称作 stereotype 注解。它能为代码阅读者提供一些提示，对于 Spring 而言，这个类具有特殊作用。我们的类是一个 web @Controller，因此 Spring 在处理传入的 web 请求时会考虑它
+@RequestMapping 注解提供了 routing（路由）信息。它告诉 Spring，任何具有路径为 / 的 HTTP 请求都应映射到 home 方法
+@RestController 注解告知 Spring 渲染结果字符串直接返回给调用者
+>@RestController 和 @RequestMapping 是 Spring MVC 注解（它们不是 Spring Boot 特有的）
+# 2 @EnableAutoConfiguration
+![](https://upload-images.jianshu.io/upload_images/4685968-5507d450a6e8eb8f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+第二个类级别注解
+此注解告知 Spring Boot 根据您添加的 jar 依赖来“猜测”您想如何配置 Spring 并进行自动配置，由于` spring-boot-starter-web `添加了 Tomcat 和 Spring MVC，auto-configuration（自动配置）将假定您要开发 web 应用并相应设置了 Spring
+
+> - Starter 与自动配置 
+Auto-configuration 被设计与 Starter 配合使用，但这两个概念并不是直接相关的。您可以自由选择 starter 之外的 jar 依赖，Spring Boot 仍然会自动配置您的应用程序
+# 3 @SpringBootApplication
+![](https://upload-images.jianshu.io/upload_images/4685968-b23bd908285f1079.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+很多 Spring Boot 开发者总是使用 `@Configuration`、`@EnableAutoConfiguration` 和 `@ComponentScan` 注解标记在主类上
+由于 这些注解经常一起使用（特别是如果您遵循上述的[最佳实践](https://docshome.gitbooks.io/springboot/content/pages/using-spring-boot.html#using-boot-structuring-your-code)）。Spring Boot 提供了一个更方便的 `@SpringBootApplication` 注解可用来替代这个组合。
+>@SpringBootApplication 还提供了别名来自定义 @EnableAutoConfiguration 和 @ComponentScan 的属性。
diff --git "a/Java/Spring Boot/SpringBoot-\345\244\232\346\250\241\345\235\227.md" "b/Java/Spring Boot/SpringBoot-\345\244\232\346\250\241\345\235\227.md"
new file mode 100644
index 0000000000..a5e3ea87e7
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot-\345\244\232\346\250\241\345\235\227.md"	
@@ -0,0 +1,16 @@
+# 1 课程介绍
+## 1.1 简介
+![课程内容](https://upload-images.jianshu.io/upload_images/4685968-9ca261935344bcf7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 1.2 SpringBoot 的角色
+![](https://upload-images.jianshu.io/upload_images/4685968-53b08319cb19de21.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 1.3 SpringBoot2.0 新特性
+![](https://upload-images.jianshu.io/upload_images/4685968-d8a972dc40e1674c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![为什么选择 Web Flux](https://upload-images.jianshu.io/upload_images/4685968-6b42f2ddcc90df31.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![环境装配](https://upload-images.jianshu.io/upload_images/4685968-235739b8bd99488e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 2 应用
+![简单应用](https://upload-images.jianshu.io/upload_images/4685968-f3474112726b084c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![场景说明](https://upload-images.jianshu.io/upload_images/4685968-01377b37d9dc8c87.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-721768c3150534e6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 3 多模块
+![](https://upload-images.jianshu.io/upload_images/4685968-f7f7ef9fa8394491.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-01ae47dc5047097c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Boot/SpringBoot2-0\345\223\215\345\272\224\345\274\217\347\274\226\347\250\213\347\263\273\345\210\227(\344\270\200)-\345\257\274\350\257\273.md" "b/Java/Spring Boot/SpringBoot2-0\345\223\215\345\272\224\345\274\217\347\274\226\347\250\213\347\263\273\345\210\227(\344\270\200)-\345\257\274\350\257\273.md"
new file mode 100644
index 0000000000..e1f008dd0a
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot2-0\345\223\215\345\272\224\345\274\217\347\274\226\347\250\213\347\263\273\345\210\227(\344\270\200)-\345\257\274\350\257\273.md"	
@@ -0,0 +1,7 @@
+![](https://upload-images.jianshu.io/upload_images/4685968-3523a877fda846e3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9a0c66da2d3b2a8d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9490f467b9acb4af.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-27a553a52082c177.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-1d279bfe57ade07f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-bc357c51cc85c51d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-28a5120de742cd1c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Boot/SpringBoot\347\273\237\344\270\200\345\274\202\345\270\270\345\244\204\347\220\206.md" "b/Java/Spring Boot/SpringBoot\347\273\237\344\270\200\345\274\202\345\270\270\345\244\204\347\220\206.md"
new file mode 100644
index 0000000000..7861594d52
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot\347\273\237\344\270\200\345\274\202\345\270\270\345\244\204\347\220\206.md"	
@@ -0,0 +1,17 @@
+# BasicErrorController
+SpringBoot内置了一个BasicErrorController对异常进行统一的处理，当在页面发生异常的时候会自动把请求转到/error(Spring Boot提供的一个默认的映射) 
+，可以自定义页面内容，只需在classpath路径下新建error页面即可。当然我们也可以自定义error页面的路径 
+如:
+`server.error.path=/custom/error
+BasicErrorController提供两种返回错误一种是页面返回、当你是页面请求的时候就会返回页面，另外一种是json请求的时候就会返回json错误
+
+可以查看源码。
+
+# 定义全局异常处理类：并用@ControllerAdvice注解
+- 返回视图，新建方法defaultErrorHandler 用@ExceptionHandler注解
+- 返回JSON，新建方法 用jsonErrorHandler 用@ExceptionHandler和@ResponseBody（必须）注解
+![](https://upload-images.jianshu.io/upload_images/4685968-702bf9d222304e9b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#自定义异常类，继承Exception（或RuntimeException）
+![](https://upload-images.jianshu.io/upload_images/4685968-010fd9a4f76fb914.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#页面
+![](https://upload-images.jianshu.io/upload_images/4685968-a760a4fe8a240d5b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Boot/SpringBoot\351\233\206\346\210\220BootStrap.md" "b/Java/Spring Boot/SpringBoot\351\233\206\346\210\220BootStrap.md"
new file mode 100644
index 0000000000..7888e05694
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot\351\233\206\346\210\220BootStrap.md"	
@@ -0,0 +1,11 @@
+![](http://upload-images.jianshu.io/upload_images/4685968-8381c58c5453cac1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-28a266ec81f2bf95.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-d8e0ed836c4bf7ce.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-10f7bff4c5e5956c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-6398dbd171e6f704.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-5568eac9f6bda33e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-09452f833ddb1b66.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-14f55cb12ddc02f1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-3ae5dcb07ee0c1ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-45887287c8353154.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![image.png](http://upload-images.jianshu.io/upload_images/4685968-bb6c05389127b6e8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Boot/SpringBoot\351\233\206\346\210\220RabbitMQ.md" "b/Java/Spring Boot/SpringBoot\351\233\206\346\210\220RabbitMQ.md"
new file mode 100644
index 0000000000..e9951ed6fc
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot\351\233\206\346\210\220RabbitMQ.md"	
@@ -0,0 +1,9 @@
+![](http://upload-images.jianshu.io/upload_images/4685968-530c5010441b9594.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![添加依赖](http://upload-images.jianshu.io/upload_images/4685968-77bda6b3081d09d2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![配置](http://upload-images.jianshu.io/upload_images/4685968-f480c6be56ed7dcd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-673a539a80107e8b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+无法远程连接,需要配置文件
+cd etc/rabbitmq
+
+
diff --git "a/Java/Spring Boot/SpringBoot\351\233\206\346\210\220Thymeleaf\346\250\241\346\235\277.md" "b/Java/Spring Boot/SpringBoot\351\233\206\346\210\220Thymeleaf\346\250\241\346\235\277.md"
new file mode 100644
index 0000000000..a5067006eb
--- /dev/null
+++ "b/Java/Spring Boot/SpringBoot\351\233\206\346\210\220Thymeleaf\346\250\241\346\235\277.md"	
@@ -0,0 +1,49 @@
+#1 创建一个maven工程，这个应该都会
+#2 pom文件加入下面内容即可(版本号自己改
+
+```
+    <parent>
+		<groupId>org.springframework.boot</groupId>
+		<artifactId>spring-boot-starter-parent</artifactId>
+		<version>1.5.4.RELEASE</version>
+		<relativePath/> <!-- lookup parent from repository -->
+	</parent>
+
+    <dependency>
+		<groupId>org.springframework.boot</groupId>
+		<artifactId>spring-boot-starter-thymeleaf</artifactId>
+	</dependency>
+```
+#3 写一个入口类
+#4 写个home.html
+#5 在工程的resources目录下创建一个application.properties文件，这个文件是spring-boot用来配置一些工程属性用的
+
+```
+# 配置服务器端口，默认是8080，可以不用配置
+server.port=8080
+# 模板配置
+# 这个开发配置为false，避免改了模板还要重启服务器
+spring.thymeleaf.cache=false
+# 这个是配置模板路径的，默认就是templates，可不用配置
+spring.thymeleaf.prefix=classpath:/templates/
+# 这个可以不配置，检查模板位置
+spring.thymeleaf.check-template-location=true
+# 下面3个不做解释了，可以不配置
+spring.thymeleaf.suffix=.html
+spring.thymeleaf.encoding=UTF-8
+spring.thymeleaf.content-type=text/html
+
+# 模板的模式
+spring.thymeleaf.mode=HTML5
+
+```
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/Spring Boot/Springboot-\347\247\222\346\235\200\351\241\271\347\233\256.md" "b/Java/Spring Boot/Springboot-\347\247\222\346\235\200\351\241\271\347\233\256.md"
new file mode 100644
index 0000000000..090d22791b
--- /dev/null
+++ "b/Java/Spring Boot/Springboot-\347\247\222\346\235\200\351\241\271\347\233\256.md"	
@@ -0,0 +1,17 @@
+# 介绍
+![](https://upload-images.jianshu.io/upload_images/4685968-ad6ff95bc64452a5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ca05ab9f7786dd04.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-625dab12e9ce4d9f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-28daf9f1947f94f7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-f53221d5606db07d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2 应用SpringBoot完成基础项目搭建
+![](https://upload-images.jianshu.io/upload_images/4685968-02bfa6b7c46b0144.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-8a97615888d237bc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ed1c19f92259140b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c7437b03538441fa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c7dd5783028f7e71.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c339aa0183f6dc8c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+# 参考
diff --git "a/Java/Spring Boot/Springboot\351\233\206\346\210\220Thymeleaf.md" "b/Java/Spring Boot/Springboot\351\233\206\346\210\220Thymeleaf.md"
new file mode 100644
index 0000000000..870e42286a
--- /dev/null
+++ "b/Java/Spring Boot/Springboot\351\233\206\346\210\220Thymeleaf.md"	
@@ -0,0 +1,6 @@
+修改build.gradle
+![](http://upload-images.jianshu.io/upload_images/4685968-5dfe30a7ec84f0dc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-fe8042c8e7ca5731.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+基本属性设置
+![application.properties文件](http://upload-images.jianshu.io/upload_images/4685968-6e6ba4d5c129d13a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\203)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\212\240\350\275\275\345\205\250\351\207\217\347\264\242\345\274\225).md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\203)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\212\240\350\275\275\345\205\250\351\207\217\347\264\242\345\274\225).md"
new file mode 100644
index 0000000000..4a296e2e5b
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\203)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\212\240\350\275\275\345\205\250\351\207\217\347\264\242\345\274\225).md"	
@@ -0,0 +1,35 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-6a8b28d2fd95e8b7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题") 
+1.[Java开发技术交流Q群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+
+2.[完整博客链接](http://www.shishusheng.com)
+
+3.[个人知乎](http://www.zhihu.com/people/shi-shu-sheng-)
+
+4.[gayhub](https://github.com/Wasabi1234)
+
+# [相关源码](https://github.com/Wasabi1234/JavaEdge-Ad-Spring-Cloud)
+
+# 1 导出表数据字段定义（1）
+- 新建dump包
+![](https://upload-images.jianshu.io/upload_images/4685968-5d02476488c1ab83.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c8e00ce281aacc70.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-508d2e57dd89ce52.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7d3e737d50db892a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-bfb0c9a2c6b807d5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c979770a9090d792.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-e44b5eb7d6e6d079.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7c880fa6af16b74c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5d2db5a11101f5f5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2 表数据导出到文件功能实现
+为方便,直接在 sponsor 模块 test 包下进行代码编写,方便调用各种db 接口
+- 新建启动类
+![](https://upload-images.jianshu.io/upload_images/4685968-ad46c6e7b96ccd29.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 直接复制得到 java 目录下的配置文件即可
+![](https://upload-images.jianshu.io/upload_images/4685968-c2b686471e5ba4a3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 写数据文件的服务类
+![](https://upload-images.jianshu.io/upload_images/4685968-faac1a040a19b2d0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 3 索引操作Handler的定义与说明
+![](https://upload-images.jianshu.io/upload_images/4685968-420f1a56fe3292ea.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\211)---\351\200\232\347\224\250\346\250\241\345\235\227\347\232\204\345\274\200\345\217\221.md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\211)---\351\200\232\347\224\250\346\250\241\345\235\227\347\232\204\345\274\200\345\217\221.md"
new file mode 100644
index 0000000000..b05aa771b6
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\270\211)---\351\200\232\347\224\250\346\250\241\345\235\227\347\232\204\345\274\200\345\217\221.md"	
@@ -0,0 +1,43 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-6a8b28d2fd95e8b7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题") 
+1.[Java开发技术交流Q群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+
+2.[完整博客链接](http://www.shishusheng.com)
+
+3.[个人知乎](http://www.zhihu.com/people/shi-shu-sheng-)  
+
+4.[gayhub](https://github.com/Wasabi1234)
+
+# [相关源码](https://github.com/Wasabi1234/JavaEdge-Ad-Spring-Cloud)
+
+# 1 通用模块功能的介绍
+![ad - commons 模块](https://upload-images.jianshu.io/upload_images/4685968-1b70574a776c90f2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 统一的响应处理
+![](https://upload-images.jianshu.io/upload_images/4685968-2e1bf519944c0be7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 异常处理
+![](https://upload-images.jianshu.io/upload_images/4685968-6e883a199e3b315b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2 统一响应处理的开发
+![](https://upload-images.jianshu.io/upload_images/4685968-67f070c747403897.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3cbeae097d4670c8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ec58ed7b6e7f0d11.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a507f0189bfb560b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 删除 src 目录,修改 pom 文件,只用作管理系统业务层代码
+![](https://upload-images.jianshu.io/upload_images/4685968-2f317666e38efa42.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a51cb6c0c9ff5508.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-104bc27ca779a529.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d12ba26af1127250.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-630c908c1d94823f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 小技巧,先创建一个临时文件,再创建包就不会出现级联现象
+![](https://upload-images.jianshu.io/upload_images/4685968-9d926f20c7f9aae2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-94a2b42354cb39eb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 有的类与方法不需要全局响应,应当排除,特设此注解
+![](https://upload-images.jianshu.io/upload_images/4685968-0771b9a094d73189.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 3 统一异常处理的开发
+![](https://upload-images.jianshu.io/upload_images/4685968-8854f0cb7023d551.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 4 统一配置的开发
+![](https://upload-images.jianshu.io/upload_images/4685968-6bb685e42c95e09f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\214)---\346\220\255\345\273\272\350\204\232\346\211\213\346\236\266.md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\214)---\346\220\255\345\273\272\350\204\232\346\211\213\346\236\266.md"
new file mode 100644
index 0000000000..f3ab4d3d95
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\214)---\346\220\255\345\273\272\350\204\232\346\211\213\346\236\266.md"	
@@ -0,0 +1,89 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-d7307e723c8c29ad?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题")
+1.Q群【Java开发技术交流】：[https://jq.qq.com/?_wv=1027&k=5UB4P1T](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+2.完整博客链接:[www.shishusheng.com](http://www.shishusheng.com)
+3.知乎:[http://www.zhihu.com/people/shi-shu-sheng-](http://www.zhihu.com/people/shi-shu-sheng-)
+4.gayhub:[https://github.com/Wasabi1234](https://github.com/Wasabi1234)
+
+# 源码地址
+https://github.com/Wasabi1234/JavaEdge-Ad-Spring-Cloud
+
+# 1 Maven 基础
+![Maven 介绍](https://upload-images.jianshu.io/upload_images/4685968-4c3fe7f49f7cf594.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![基本样式](https://upload-images.jianshu.io/upload_images/4685968-8e0aceea5baad8a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0b8f05499b5133de.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 坐标
+![](https://upload-images.jianshu.io/upload_images/4685968-30cf58d8cdbdd2b6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 常用命令
+![](https://upload-images.jianshu.io/upload_images/4685968-514b18e68518230a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2 Maven 相关特性
+- 传递依赖与排除依赖
+![](https://upload-images.jianshu.io/upload_images/4685968-2811c0adf4bc9d09.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 依赖冲突
+![](https://upload-images.jianshu.io/upload_images/4685968-c5057067a48dcff8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 多模块项目 / 聚合
+![](https://upload-images.jianshu.io/upload_images/4685968-4da8f940e790576c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 3  主工程搭建
+![](https://upload-images.jianshu.io/upload_images/4685968-19de6133d1af3e87.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-008d3c4fa13fcd38.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-cac3d4de1f85d358.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7da7f99631c2acd7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-01e810ac8a6fdf7f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 4 开发单节点 Eureka Server
+![](https://upload-images.jianshu.io/upload_images/4685968-4ec4dc830762cd69.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ebc2eb0705407199.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-97d665fd4977526d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-53c3630f55d286bf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9e1aa463e7e3a660.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 父 pom 文件新添内容
+![](https://upload-images.jianshu.io/upload_images/4685968-4b365cf62fb421cf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2ba3161bebae44d0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a7f3e3c36c6fc550.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 5 Eureka Server 的部署
+- 启动前面的 e-s
+![](https://upload-images.jianshu.io/upload_images/4685968-1d57f5e3e4be0378.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 使不同服务名走相同的 ip 地址,防止单机下的注册失败
+![](https://upload-images.jianshu.io/upload_images/4685968-ac20d18c7e8a55d0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-89ca00bfe81ccf09.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 单机多节点配置信息
+![](https://upload-images.jianshu.io/upload_images/4685968-24ad0eac048c5e7b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 将服务打成 jar 包
+![](https://upload-images.jianshu.io/upload_images/4685968-8d1a8a99a1b4c093.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-169702420225f7ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-560a95ed2b79537d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- jar 包形式,须根据配置选项启动 e-s
+![java -jar ad-eureka-1.0-SNAPSHOT.jar --spring.profiles.active=server2
+](https://upload-images.jianshu.io/upload_images/4685968-9c238061d65e66fb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-809191ac8c1c8c60.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-1829a1609f2fa1bc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ce31a333b8ed2933.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- e-s 变化之处,已有三个注册实例
+![](https://upload-images.jianshu.io/upload_images/4685968-1e24b6520a507a92.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+# 6   微服务架构及网关组件介绍
+
+## 6.1 微服务架构及其应用场景
+
+### 6.1.1 微服务架构的两种方式
+![](https://upload-images.jianshu.io/upload_images/4685968-a025ea2509b14517.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![应用最广泛的方式](https://upload-images.jianshu.io/upload_images/4685968-43bff3a7aadc9dde.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 6.2 Zuul 的生命周期
+![](https://upload-images.jianshu.io/upload_images/4685968-678fe19cd8e9d472.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 7 网关启动程序的开发
+- 由于只是小型演示系统,就不使用多节点了
+![](https://upload-images.jianshu.io/upload_images/4685968-dfd1b1c6293b7661.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a8c23b04ae17b6e7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 8 自定义网关过滤器的开发
+![](https://upload-images.jianshu.io/upload_images/4685968-898accc7886196b2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0c07e1c300b65eb9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 之后,启动 e-s
+![](https://upload-images.jianshu.io/upload_images/4685968-4b259050bfadb207.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\224)---\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\276\256\346\234\215\345\212\241\350\260\203\347\224\250).md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\224)---\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\276\256\346\234\215\345\212\241\350\260\203\347\224\250).md"
new file mode 100644
index 0000000000..3b6676957d
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\344\272\224)---\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\276\256\346\234\215\345\212\241\350\260\203\347\224\250).md"	
@@ -0,0 +1,188 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-6a8b28d2fd95e8b7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题") 
+1.[Java开发技术交流Q群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+
+2.[完整博客链接](http://www.shishusheng.com)
+
+3.[个人知乎](http://www.zhihu.com/people/shi-shu-sheng-)
+
+4.[gayhub](https://github.com/Wasabi1234)
+
+# [相关源码](https://github.com/Wasabi1234/JavaEdge-Ad-Spring-Cloud)
+
+本文会介绍使用 Ribbon 与 Feign 组件实现微服务之间的调用。
+
+# 1 创建广告检索系统子模块
+- 新建搜索服务子模块
+![](https://upload-images.jianshu.io/upload_images/4685968-40096bb89429cd02.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 编辑 pom 文件
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<project xmlns="http://maven.apache.org/POM/4.0.0"
+         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <!-- 指定父pom, 注意它是 javaedge-ad-service 的子模块 -->
+    <parent>
+        <artifactId>javaedge-ad-service</artifactId>
+        <groupId>com.sss.ad</groupId>
+        <version>1.0-SNAPSHOT</version>
+    </parent>
+
+    <modelVersion>4.0.0</modelVersion>
+
+    <!-- 当前项目/模块的坐标, groupId从父模块中继承 -->
+    <artifactId>ad-search</artifactId>
+    <version>1.0-SNAPSHOT</version>
+    <packaging>jar</packaging>
+
+    <dependencies>
+        <!-- Hystrix 监控 -->
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
+        </dependency>
+        <!-- 监控端点, 采集应用指标 -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-actuator</artifactId>
+        </dependency>
+        <!-- 引入 Web 功能 -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-web</artifactId>
+        </dependency>
+        <!--
+            Eureka 客户端, 客户端向 Eureka Server 注册的时候会提供一系列的元数据信息, 例如: 主机, 端口, 健康检查url等
+            Eureka Server 接受每个客户端发送的心跳信息, 如果在某个配置的超时时间内未接收到心跳信息, 实例会被从注册列表中移除
+        -->
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
+        </dependency>
+        <!-- 引入 Feign, 可以以声明的方式调用微服务 -->
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-starter-openfeign</artifactId>
+        </dependency>
+        <!-- 引入服务容错 Hystrix 的依赖 -->
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
+        </dependency>
+        <!-- 引入服务消费者 Ribbon 的依赖 -->
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
+        </dependency>
+        <!-- Java Persistence API, ORM 规范 -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-data-jpa</artifactId>
+        </dependency>
+        <!-- 数据库连接 -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-jdbc</artifactId>
+        </dependency>
+        <!-- MySQL 驱动, 注意, 这个需要与 MySQL 版本对应 -->
+        <dependency>
+            <groupId>mysql</groupId>
+            <artifactId>mysql-connector-java</artifactId>
+            <version>8.0.12</version>
+            <scope>runtime</scope>
+        </dependency>
+
+        <!-- 通用模块 -->
+        <dependency>
+            <groupId>com.sss.ad</groupId>
+            <artifactId>ad-common</artifactId>
+            <version>1.0-SNAPSHOT</version>
+        </dependency>
+        <!-- apache 提供的一些工具类 -->
+        <dependency>
+            <groupId>commons-codec</groupId>
+            <artifactId>commons-codec</artifactId>
+            <version>1.9</version>
+        </dependency>
+        <!-- 集合类操作 -->
+        <dependency>
+            <groupId>org.apache.commons</groupId>
+            <artifactId>commons-collections4</artifactId>
+            <version>4.0</version>
+        </dependency>
+
+        <!-- binlog 监听与解析: https://github.com/shyiko/mysql-binlog-connector-java -->
+        <dependency>
+            <groupId>com.github.shyiko</groupId>
+            <artifactId>mysql-binlog-connector-java</artifactId>
+            <version>0.13.0</version>
+        </dependency>
+        <!-- 解析配置文件中的配置 -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-configuration-processor</artifactId>
+        </dependency>
+        <!--kafka 依赖-->
+        <dependency>
+            <groupId>org.springframework.kafka</groupId>
+            <artifactId>spring-kafka</artifactId>
+            <version>2.1.5.RELEASE</version>
+        </dependency>
+    </dependencies>
+
+    <!--
+        SpringBoot的Maven插件, 能够以Maven的方式为应用提供SpringBoot的支持，可以将
+        SpringBoot应用打包为可执行的jar或war文件, 然后以通常的方式运行SpringBoot应用
+     -->
+    <build>
+        <plugins>
+            <plugin>
+                <groupId>org.springframework.boot</groupId>
+                <artifactId>spring-boot-maven-plugin</artifactId>
+            </plugin>
+        </plugins>
+    </build>
+</project>
+```
+
+# 2 基于 Ribbon 实现微服务调用
+## Client Side Load Balancer: Ribbon
+Ribbon 是一个客户端负载均衡器,可很好地控制HTTP和TCP客户端的行为.
+Feign已经使用Ribbon，所以若使用@FeignClient，则本节也适用也是必备知识点.
+
+- Ribbon 中的中心概念是指定客户端的概念
+每个负载平衡器是集合组件的一部分，它们一起工作以根据需要与远程服务器通信,并且集合具有你将其作为应用程序开发人员（例如使用@FeignClient注解）的名称.
+Spring Cloud 使用 RibbonClientConfiguration 为每个命名的客户端根据需要创建一个新的集合作为ApplicationContext.这包含 ILoadBalancer，RestClient和ServerListFilter.
+
+## 2.1 添加 Ribbon
+要在项目中包含Ribbon,请使用
+group`org.springframework.cloud`,artifact ID `spring-cloud-starter-ribbon`的starter.
+![](https://upload-images.jianshu.io/upload_images/4685968-098c9e93809824fe.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+![](https://upload-images.jianshu.io/upload_images/4685968-2d29eb36cacb5587.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 定义 demo 演示类
+![](https://upload-images.jianshu.io/upload_images/4685968-845fe608103d0ee6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-929434ee59761f78.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c8dedc0f19ffc11e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 3 基于 Feign 实现微服务调用
+[Feign](https://github.com/Netflix/feign) 是一个声明式的Web服务客户端.
+这使得Web服务客户端的写入更加方便,要使用 Feign 创建一个接口，并对其添加注解。它提供了可插拔式的注解，包括Feign注解和JAX-RS注解。Feign还支持可插拔编码器和解码器.
+Spring Cloud增加了对Spring MVC注解的支持，并使用Spring Web中默认使用的`HttpMessageConverters`.
+Spring Cloud集成Ribbon和Eureka以在使用Feign时提供负载均衡的http客户端.
+
+## 3.1 如何加入Feign
+要在项目中包含Feign，请使用group`org.springframework.cloud`和artifact ID `spring-cloud-starter-feign`的启动器.
+
+- Spring Boot应用
+![](https://upload-images.jianshu.io/upload_images/4685968-7bb526fdf165b33c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 接口文件
+![](https://upload-images.jianshu.io/upload_images/4685968-61e205c8529dfe8f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+在 `@FeignClient` 注解中,String 值（上面的`eureka-client-ad-sponsor`）是一个任意的客户端名称，用于创建Ribbon负载均衡器,还可以使用`url`属性（绝对值或只是主机名）指定URL.
+应用程序上下文中的bean的名称是该接口的完全限定名,要指定自己的别名,可以使用`@FeignClient`注释的`qualifier`值.
+
+## 3.2 Feign Hystrix回退
+Hystrix支持回退的概念 : 当电路断开或出现错误时执行的默认代码路径.
+要为给定的 `@FeignClient` 启用回退,请将 `fallback` 属性设置为实现回退的类名.
+![](https://upload-images.jianshu.io/upload_images/4685968-a0e529ea777453b2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\205\255)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\271\277\345\221\212\346\225\260\346\215\256\347\264\242\345\274\225\347\232\204\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260).md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\205\255)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\271\277\345\221\212\346\225\260\346\215\256\347\264\242\345\274\225\347\232\204\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260).md"
new file mode 100644
index 0000000000..bc1951c1f6
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\205\255)----\345\271\277\345\221\212\346\243\200\347\264\242\347\263\273\347\273\237(\345\271\277\345\221\212\346\225\260\346\215\256\347\264\242\345\274\225\347\232\204\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260).md"	
@@ -0,0 +1,100 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-6a8b28d2fd95e8b7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题") 
+1.[Java开发技术交流Q群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+
+2.[完整博客链接](http://www.shishusheng.com)
+
+3.[个人知乎](http://www.zhihu.com/people/shi-shu-sheng-)
+
+4.[gayhub](https://github.com/Wasabi1234)
+
+# [相关源码](https://github.com/Wasabi1234/JavaEdge-Ad-Spring-Cloud)
+
+广告检索系统的核心是实现广告检索服务，为加快广告检索的速度，良好的索引设计是不可缺少的.
+本文首先对索引的设计与维护进行介绍，之后，实现广告数据的索引服务.
+
+# 1 广告数据索引设计介绍
+![](https://upload-images.jianshu.io/upload_images/4685968-ea8592a83b6925b3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 1.1 正向索引
+- 定义
+也称为正排索引（Forward Index）,通过唯一键/主键生成与对象的映射关系.
+即通过主键（Key）检索到文档（Doc）内容,以下简称正排表或Table.
+
+Table 不仅提供按主键的增删除改查,也配合倒排表实现检索、过滤、读取等功能.
+作为核心数据结构,Table必须支持频繁的字段读取和各类型的正排过滤,需要高效和紧凑的实现.
+- 一个简单的例子
+![](https://upload-images.jianshu.io/upload_images/4685968-9eefc4167af02662.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![正排存储结构](https://upload-images.jianshu.io/upload_images/4685968-c5a077870087b328.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+为支持按 docID 的随机访问,把Table设计为一个大数组结构（data区）.
+每个 doc 是数组的一个元素且长度固定,变长字段存储在扩展区（ext区）,仅在 doc 中存储其在扩展区的偏移量和长度.
+与大部分搜索引擎的列存储不同,将data区按行存储,这样可针对业务场景,尽可能利用CPU与内存之间的缓存来提高访问效率.
+
+此外，针对NoSQL场景，可通过HashMap实现主键到docID的映射（idx文件），这样就可支持主键到文档的随机访问.由于倒排索引的docID列表可以直接访问正排表，因此倒排检索并不会使用该idx.
+
+
+- 小结
+这种组织方法在建立索引的时候结构比较简单，建立比较方便且易于维护.
+    - 因为索引是基于文档建立的，若是有新的文档加入，直接为该文档建立一个新的索引块，挂接在原来索引文件的后面
+    - 若是有文档删除，则直接找到该文档号文档对应的索引信息，将其直接删除.
+
+但是在查询的时候需对所有的文档进行扫描以确保没有遗漏，这样就使得检索时间大大延长，检索效率低下,尽管正排表的工作原理非常的简单，但是由于其检索效率太低，除非在特定情况下，否则实用性价值不大.
+
+## 1.2 倒排索引（Inverted Index）
+![](https://upload-images.jianshu.io/upload_images/4685968-f89659fd0fb6cbeb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+即通过关键词（Keyword）检索到文档内容.
+为支持复杂的业务场景，如遍历索引表时的算法粗排逻辑，在此抽象了索引器接口Indexer.
+![索引器接口定义](https://upload-images.jianshu.io/upload_images/4685968-4b7568d42e599cc2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+倒排表以字或词为关键字进行索引,表中关键字所对应的[记录表](https://www.baidu.com/s?wd=%E8%AE%B0%E5%BD%95%E8%A1%A8&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd)项记录了出现这个字或词的所有文档,一个表项就是一个字表段,它记录该文档的ID和字符在该文档中出现的位置情况.
+
+由于每个字或词对应的文档数量在动态变化，所以倒排表的建立和维护都较为复杂，但是在查询的时候由于可以一次得到查询关键字所对应的所有文档，所以效率高于正排表。在全文检索中，检索的快速响应是一个最为关键的性能，而索引建立由于在后台进行，尽管效率相对低一些，但不会影响整个搜索引擎的效率.
+![倒排存储结构](https://upload-images.jianshu.io/upload_images/4685968-50415ac81071110f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+>正排索引是从文档到关键字的映射（已知文档求关键字）
+倒排索引是从关键字到文档的映射（已知关键字求文档）
+
+- 一个简单的例子
+![](https://upload-images.jianshu.io/upload_images/4685968-982e507c5c307dd9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 在检索系统中的应用
+核心用途是对各个维度限制的"整理"
+![](https://upload-images.jianshu.io/upload_images/4685968-f9ada75f3f25406f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-f8b6867b7cf485ef.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-57aa86eb657c2fef.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2 广告数据索引维护
+## 全量索引 + 增量索引
+![](https://upload-images.jianshu.io/upload_images/4685968-af117308d4858e72.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-dcde5cd1175dfa63.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+ # 3 推广计划索引对象定义与服务实现
+- 索引接口
+![](https://upload-images.jianshu.io/upload_images/4685968-e45d77813cc07128.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 4 推广单元索引对象定义与服务实现
+![](https://upload-images.jianshu.io/upload_images/4685968-de431292e139ae19.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 5 关键词索引对象定义与服务实现
+![](https://upload-images.jianshu.io/upload_images/4685968-84c5955717518bee.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 6 兴趣索引对象定义与服务实现
+![](https://upload-images.jianshu.io/upload_images/4685968-a2bfca9ad07528ea.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 7 地域索引对象定义与服务实现
+![](https://upload-images.jianshu.io/upload_images/4685968-5aee7b92743585eb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 8 创意索引对象定义与服务实现
+![](https://upload-images.jianshu.io/upload_images/4685968-a8a064a4bc753589.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 9 创意与推广单元关联索引对象定义与服务实现
+![](https://upload-images.jianshu.io/upload_images/4685968-8828c5edcd193661.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 10 索引服务类缓存的实现
+![](https://upload-images.jianshu.io/upload_images/4685968-8ea5a78e7f08dc57.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 参考
+https://coding.imooc.com/class/chapter/310.html#Anchor
+https://tech.meituan.com/2018/05/11/adp-rtidx-ls.html
+https://blog.csdn.net/zhangzeyuaaa/article/details/48676775
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\233\233)---\346\212\225\346\224\276\347\263\273\347\273\237\347\232\204\345\274\200\345\217\221.md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\233\233)---\346\212\225\346\224\276\347\263\273\347\273\237\347\232\204\345\274\200\345\217\221.md"
new file mode 100644
index 0000000000..406091bb1d
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\345\256\236\346\210\230(\345\233\233)---\346\212\225\346\224\276\347\263\273\347\273\237\347\232\204\345\274\200\345\217\221.md"	
@@ -0,0 +1,96 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-6a8b28d2fd95e8b7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题") 
+1.[Java开发技术交流Q群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+
+2.[完整博客链接](http://www.shishusheng.com)
+
+3.[个人知乎](http://www.zhihu.com/people/shi-shu-sheng-)
+
+4.[gayhub](https://github.com/Wasabi1234)
+
+# [相关源码](https://github.com/Wasabi1234/JavaEdge-Ad-Spring-Cloud)
+
+# 1 Spring IoC和 MVC 基础
+![Spring IoC 原理拆解](https://upload-images.jianshu.io/upload_images/4685968-a23dae2955d87ee7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![Spring MVC模块解析](https://upload-images.jianshu.io/upload_images/4685968-3e674f86544bf8bd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2 SpringBoot 常用功能特性介绍
+![](https://upload-images.jianshu.io/upload_images/4685968-aeee928c93cf7d97.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 2.1 [应用启动入口](https://www.jianshu.com/p/b46f859c84d5)
+
+## 2.2 容器启动后执行的操作
+![](https://upload-images.jianshu.io/upload_images/4685968-664fb0a183ca2a80.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-01f674ced21066e5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 默认,ApplicationRunner优先于CommandLineRunner
+![](https://upload-images.jianshu.io/upload_images/4685968-6d82bb71b0528910.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 但是只要加了该注解
+![](https://upload-images.jianshu.io/upload_images/4685968-980a3b73bd480fcf.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c4dc3af770bd9fdc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 2.3 Profile 环境配置
+![](https://upload-images.jianshu.io/upload_images/4685968-594afbef680380fa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 2.4 配置信息封装成实体类
+![](https://upload-images.jianshu.io/upload_images/4685968-66c25bce64cc7256.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 2.5 定时任务
+![](https://upload-images.jianshu.io/upload_images/4685968-5ad8db41b440fd76.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d2e011632d5315d7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 3 数据表设计
+![](https://upload-images.jianshu.io/upload_images/4685968-0f54947e2c5875a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-eedd69542ea66953.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-17f8e40aad18835f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d421cde710321133.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3a290367578c4ba8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ab4065b35e3f335a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-f323c763b00eb5e3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0e40706c4432bc5d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-df3f90ac4afbfe76.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 4 创建子模块
+![](https://upload-images.jianshu.io/upload_images/4685968-884ce9e511581be6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0c59340159c13087.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-b9973a37b3876971.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-4c521fc99246bbc5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ecb3a3037a748fdd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 5 数据表实体类定义
+- 创建启动类
+![](https://upload-images.jianshu.io/upload_images/4685968-ff9363f3e0fa3b90.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- User 类
+![](https://upload-images.jianshu.io/upload_images/4685968-3ff2cffe86aa3eff.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 推广计划
+![](https://upload-images.jianshu.io/upload_images/4685968-be57964fab682cee.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 推广单元
+![](https://upload-images.jianshu.io/upload_images/4685968-829153207533a0eb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 关键词限制
+![](https://upload-images.jianshu.io/upload_images/4685968-78abdbc88af41a6f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 兴趣限制
+![](https://upload-images.jianshu.io/upload_images/4685968-f114925754f3b189.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 地区限制
+![](https://upload-images.jianshu.io/upload_images/4685968-b76e10d155ea3216.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 创意物料种类枚举
+![](https://upload-images.jianshu.io/upload_images/4685968-248624b938a286ca.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- dao层代码
+![](https://upload-images.jianshu.io/upload_images/4685968-fbe5fdebdd3f780b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 6 用户账户服务功能实现
+![](https://upload-images.jianshu.io/upload_images/4685968-7e8029d668cc5d9d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 7 推广计划服务功能实现
+![](https://upload-images.jianshu.io/upload_images/4685968-c05d5793d5d1c076.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 8 创意与推广单元关联服务功能实现
+![](https://upload-images.jianshu.io/upload_images/4685968-64f767bfe5930ed6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 9 服务Controller的编写
+![](https://upload-images.jianshu.io/upload_images/4685968-de231996cc4afea3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 10 投放系统在网关中的配置
+![](https://upload-images.jianshu.io/upload_images/4685968-db630ddd6b0ff692.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 11 数据库与数据表的创建
+![](https://upload-images.jianshu.io/upload_images/4685968-db85e3dbcba15586.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-8353b21b954ea46f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260(\344\270\200)---\346\246\202\350\277\260.md" "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260(\344\270\200)---\346\246\202\350\277\260.md"
new file mode 100644
index 0000000000..62bc225c7a
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud-\345\271\277\345\221\212\347\263\273\347\273\237\350\256\276\350\256\241\344\270\216\345\256\236\347\216\260(\344\270\200)---\346\246\202\350\277\260.md"	
@@ -0,0 +1,26 @@
+# 0 联系我
+![](http://upload-images.jianshu.io/upload_images/4685968-d7307e723c8c29ad?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 "图片标题")
+1.Q群【Java开发技术交流】：[https://jq.qq.com/?_wv=1027&k=5UB4P1T](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+2.完整博客链接:[www.shishusheng.com](http://www.shishusheng.com)
+3.知乎:[http://www.zhihu.com/people/shi-shu-sheng-](http://www.zhihu.com/people/shi-shu-sheng-)
+4.gayhub:[https://github.com/Wasabi1234](https://github.com/Wasabi1234)
+
+# 1 简介
+![](https://upload-images.jianshu.io/upload_images/4685968-1f932272a04c52f8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-69217ce524f0e4dd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-20122dee0fe12f41.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-64cdb70a32dc5a55.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a85806856c31afb2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d665ee9d1eeb899c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 2.1 概览
+![](https://upload-images.jianshu.io/upload_images/4685968-f74aa926d2e029b4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-b8acb65f30e00dcd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2c3d074935a37db8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-aa42564b4f878d58.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 2.2 架构
+![](https://upload-images.jianshu.io/upload_images/4685968-9377e8249c1aa4ad.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 2.3 准备工作
+![](https://upload-images.jianshu.io/upload_images/4685968-2f599cea0b869a0d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\200)-\347\256\200\344\273\213.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\200)-\347\256\200\344\273\213.md"
new file mode 100644
index 0000000000..3fd50dcfae
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\200)-\347\256\200\344\273\213.md"	
@@ -0,0 +1,9 @@
+
+![](https://upload-images.jianshu.io/upload_images/4685968-4cc586732f88a7df.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-e28296954f8f7c0c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-4e328c2db73112ce.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-233bb762785b10c8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-959701dc95cd5dc8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-89918845ac863523.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-adb1923f8f6750f7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-8b379f12f8bef9a9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\345\274\202\346\255\245\345\222\214\346\266\210\346\201\257.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\345\274\202\346\255\245\345\222\214\346\266\210\346\201\257.md"
new file mode 100644
index 0000000000..37d948b9a8
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\345\274\202\346\255\245\345\222\214\346\266\210\346\201\257.md"	
@@ -0,0 +1,5 @@
+# 简介
+![](https://upload-images.jianshu.io/upload_images/4685968-f0d6192be4992ed0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-11a3944870df17df.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5155717d7ee21040.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 2 RabbitMQ的使用
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\346\266\210\346\201\257\346\234\215\345\212\241\345\234\250\347\224\265\345\225\206\344\270\255\347\232\204\345\256\236\350\267\265.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\346\266\210\346\201\257\346\234\215\345\212\241\345\234\250\347\224\265\345\225\206\344\270\255\347\232\204\345\256\236\350\267\265.md"
new file mode 100644
index 0000000000..c0134b42fb
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\203)-\346\266\210\346\201\257\346\234\215\345\212\241\345\234\250\347\224\265\345\225\206\344\270\255\347\232\204\345\256\236\350\267\265.md"	
@@ -0,0 +1,103 @@
+# 6 商品和订单服务中使用MQ(上)
+![](https://upload-images.jianshu.io/upload_images/4685968-130ec8c83917cfae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 6.1 同步
+![原始流程-同步流程](https://upload-images.jianshu.io/upload_images/4685968-a01dc2ce21279cc0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+在订单生成的时候直接扣库存，这是最初等的方式扣库存，这种方式比较简单，但是也有一系列的问题：
+- 会造成有很多订单把产品库存扣除而并没有支付，这就需要有一个后台脚本，将一段时间内没有支付的订单的库存释放，把订单取消掉
+- 即时扣库存，并发差
+
+1,3商品服务,操作商品服务的 db
+2,4 订单服务.操作订单服务的 db
+![避免访问不同服务的 db](https://upload-images.jianshu.io/upload_images/4685968-ee5cbb291abefa4f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 6.2  改造成基于消息队列的异步操作
+首先考虑只将第四步异步化
+分析:2,4都是操作db,第四步不再等待,
+1,2,3成功后即反馈给用户
+之后通过消息通知服务异步下单,若第4步异步下单失败了,倾向于重试操作,试图重新生成订单,消息队列的消息也是可回溯的
+![](https://upload-images.jianshu.io/upload_images/4685968-bf2668a7336a2c8c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+订单创建完成后,处于排队状态,然后服务发布一个事件`Order Created `  到消息队列中
+即订单服务向外界发送消息:我创建了一个订单
+由MQ 转发给订阅该消息的服务
+![](https://upload-images.jianshu.io/upload_images/4685968-f23a16931fccdfb6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+如果商品服务收到创建订单消息之后执行扣库存操作
+注意,这里可能因为某些不可抗因素导致扣库存失败
+无论成功与否,商品服务都会发送一个扣库存消息到 MQ 中,消息内容即扣库存的结果
+订单服务会订阅扣库存的结果,接收到该消息后
+- 如果扣库存成功,将订单的状态改为`已确认`,即下单成功
+- 如果扣库存失败,将订单的状态改为`已取消`,即下单失败
+
+欲实现上述模型要求,需要以下保证
+![](https://upload-images.jianshu.io/upload_images/4685968-6f1357bff67a92d6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+服务发出的消息,一定会被MQ收到
+![](https://upload-images.jianshu.io/upload_images/4685968-e999607abd1965e5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+前端配合排队中等界面
+
+商品/订单服务都变成异步化,适合秒杀类场景,当流量不大时,并不太适合如此改造
+# 7 异步化设计(下)
+![](https://upload-images.jianshu.io/upload_images/4685968-b571edbec36d5896.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7e66b59f62e3f349.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+对于 CAP 理论
+- zk保证 AP
+- eurake 保证 CP
+
+# 最终分析实例
+当订单支付成功后，会有一个出库过程，既然有这个过程，就有可能出库失败， 他的流程是怎么样子的呢？
+`  库存有两部分：一个缓存redis层，一个数据库mysql层  `
+
+1 当客服新增了5个库存，那么，缓存redis和数据库mysql层都需要增加5个库存，这个使用分布式事务的最终一致性来满足要么全加，要么全不加库存
+
+2 当订单生成的时候，需要扣除库存，`先扣除redis库存`，如果扣除成功，则生成订单进行支付，这个过程`不扣除mysql库存`
+
+3 当redis库存扣干净，这个产品就无法下单了，下单就会失败,就把外层的给挡住了
+
+4 在第2步`扣除redis库存成功后`，生成订单，进行支付，支付成功，返回我的订单中心， 会发现有一个出库过程
+
+5 `出库过程`
+一个MQ异步解耦的任务队列,这个过程是`扣除mysql库存`
+-  如果扣mysql库存成功，出库成功，完成下订单整个流程，进入发货状态
+- 如果扣mysql库存失败，出库失败，进行一系列的操作 
+    - 订单状态改成取消
+    - 返还redis库存
+    - 退款
+
+## redis库存和mysql库存
+支付前是`预扣`，是`扣redis库存`，是锁定库存的过程
+支付后是真正扣，`扣mysql库存`，保证库存最终一致
+
+但是，在极端情况下会存在数据不一致
+- 如果redis库存 = mysql库存，不会有问题
+- 如果redis库存 < mysql库存，不会有超卖问题，但会存在实际有库存，但是没有卖的情况
+- 如果redis库存 > mysql库存，就会超卖，超卖的订单，在出库的过程中会失败
+
+这样总体不会出问题，mysql数据库层，保证库存最终不会出问题。
+## 但是会有以下的问题：
+### 数据库库存和redis库存不一致，如何检测？
+### 如果检测出来不一致，如何同步
+没有想出来好的方案
+比较暴力的方式，就是找一个低峰期，譬如凌晨1点，周期性强行覆盖。 但是极端情况下还是会存在同步后不准确，譬如在同步的过程中，刚好有一个订单在支付，这个订单支付成功后，出库的过程中，扣除了mysql的库存，但是没有扣除redis的库存
+```
+这个就是数据库同步缓存的更新机制方面的问题
+属于一致性的逻辑设计的问题
+`缓存数 = 数据库库存数 - 待扣数`
+当然这里面也还有其它的方案，以及考虑到一致性的要求高低，可以使用简单或复杂的方案
+就看系统复杂度了，越是大系统就要拆得越细
+比如待扣数又可以放到一个队列里面，或者缓存里面，同时有计数，直接读计数就行
+比如放到mongo，已支付待出库的数量，一般也不会很大，count一下，也不会损失多少
+所以一般系统都不能完全保障数据链不出错，但一定要有补偿，就是出错了可以纠错
+要保障不出错的代价显然太大
+同步是有一套刷新机制，可以定时，也可以通过MQ，或者监控不一至同步等等。。。
+也叫做保障缓存数据的新鲜度
+一般不会太长时间，半小时，几分钟都有可能，不同场景需求不一样
+```
+# 买火车票的12306，晚上的时间都不能买票，这个时间估计是在同步库存，将数据库库存同步到redis库存中， 但是买火车票之类，在订单生成前，必须扣除实际库存，也就是要扣除mysql的库存，
+
+因为买火车票和购物不一样，购物可以付款后出库，但是买票这种，支付前就必须出库，因此，要将出库过程提前， 只有出库成功，才能生成订单，同样要引入redis库存
+
+## 先扣缓存中的库存，扣除成功后，然后才可以去扣mysql中的库存
+
+## 如果扣除缓存中的库存失败，就会挡在外面，返回库存不足，这些请求不会穿刺到mysql中，挡住了大多数的请求压力。
+
+## redis库存会和mysql库存不一致，极端情况下是肯定有的，需要进行库存同步
+- 当缓存库存比数据库库存多，那么就会出现，查询有票，但是就无法下单，下单的时候就说库存不足，这个情况下，就会造成数据库压力过大，不过12306应该有其他手段来规避这个问题，不过，我确实遇到过，查询的时候有票，但是无法下单的情况。
+
+- 当缓存库存比数据库缓存少，那么不会出问题，只会出现有票，但是没有出售的情况，等完成库存同步一下， 明天又准确了。
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\211)-\346\234\215\345\212\241\346\263\250\345\206\214\344\270\216\345\217\221\347\216\260.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\211)-\346\234\215\345\212\241\346\263\250\345\206\214\344\270\216\345\217\221\347\216\260.md"
new file mode 100644
index 0000000000..3fcf979d30
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\270\211)-\346\234\215\345\212\241\346\263\250\345\206\214\344\270\216\345\217\221\347\216\260.md"	
@@ -0,0 +1,121 @@
+- 订单服务源码
+https://github.com/Wasabi1234/SpringCloud_OrderDemo
+- 商品服务源码
+https://github.com/Wasabi1234/SpringCloud_ProductDemo
+![](https://upload-images.jianshu.io/upload_images/4685968-ad371531c6d8285c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##注册中心Eureka Server
+![新建项目](https://upload-images.jianshu.io/upload_images/4685968-5a71804525ced7aa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+使用`@EnableEurekaServer`
+![](https://upload-images.jianshu.io/upload_images/4685968-8f872f99b4f4ee78.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+就可以让应用变为Eureka服务器，这是因为spring boot封装了Eureka Server，让你可以嵌入到应用中直接使用
+直接运行成功如下
+![](https://upload-images.jianshu.io/upload_images/4685968-b71a68b2ab5fa2c5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+但是不断报异常,why?
+![](https://upload-images.jianshu.io/upload_images/4685968-ffff1cc04f1e8dae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+这是因为该应用虽然是 Server 端,但也同时是 Client 端,也需要一个注册中心将自己注册进去
+为消除其异常,修改下配置
+配置需要注册的地址,也就是往自己身上注册
+![](https://upload-images.jianshu.io/upload_images/4685968-5444a86900c252ec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+通过观察源码,知道其实是一个 map, 所以配置如下
+![](https://upload-images.jianshu.io/upload_images/4685968-a8bef88b3212cbae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+启动仍旧报错,其实正常问题,因为服务端自己又是 Server, 又是 Client, 服务端未启动完成时,客户端肯定是无法找到服务端的
+但是 eureka 的服务端/客户端采用心跳通信方式
+![](https://upload-images.jianshu.io/upload_images/4685968-8490f8c61a8437d5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+可看到地址已随配置被改变
+
+接下来配置实例名
+![](https://upload-images.jianshu.io/upload_images/4685968-b3c897df2e1a808d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![实例名被修改成功](https://upload-images.jianshu.io/upload_images/4685968-a5e87119a55b8331.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+但是该应用本身就是个注册中心,不需要将其显示在注册实例中,通过以下配置
+![](https://upload-images.jianshu.io/upload_images/4685968-4d01658c06938041.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+为防止冲突,将端口号回改为默认
+![](https://upload-images.jianshu.io/upload_images/4685968-529e7846d3eebe19.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a3f5ec7b14ad4818.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##服务中心
+![](https://upload-images.jianshu.io/upload_images/4685968-d7357881e6753775.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+为避免每次手动启动,将应用打成 war 包(jar)
+![](https://upload-images.jianshu.io/upload_images/4685968-ca3cbad66bc521ff.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![通过 java 命令启动](https://upload-images.jianshu.io/upload_images/4685968-e12123e91852144e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![启动成功效果](https://upload-images.jianshu.io/upload_images/4685968-45a0ad8761acf47f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![Mac 下 Ctrl+C 退出服务](https://upload-images.jianshu.io/upload_images/4685968-f6dc9b1b90c1a948.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![后台执行](https://upload-images.jianshu.io/upload_images/4685968-4ddcc8bd748bf6b5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![查看其相关进程信息](https://upload-images.jianshu.io/upload_images/4685968-5c4b493f78c0dd91.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+如此该应用就方便了我们,不需要每次都去手动启动应用,在后台会重启,若想杀死进程直接 kill
+![](https://upload-images.jianshu.io/upload_images/4685968-16b1e4b0e40b0199.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 3.3 Eureka Client的使用
+![](https://upload-images.jianshu.io/upload_images/4685968-ee8af491e5a312a5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- `@EnableDiscoveryClient`注解
+这通过`META-INF/spring.factories`查找`DiscoveryClient`接口的实现
+Discovery Client的实现将在`org.springframework.cloud.client.discovery.EnableDiscoveryClient`键下的`spring.factories`中添加一个配置类。
+`DiscoveryClient`实现的示例是[Spring Cloud Netflix Eureka](http://cloud.spring.io/spring-cloud-netflix/)，[Spring Cloud Consul发现](http://cloud.spring.io/spring-cloud-consul/)和[Spring Cloud Zookeeper发现](http://cloud.spring.io/spring-cloud-zookeeper/)。
+
+默认情况下，`DiscoveryClient`的实现将使用远程发现服务器自动注册本地Spring Boot服务器。可以通过在`@EnableDiscoveryClient`中设置`autoRegister=false`来禁用此功能。
+
+启动Server, 再启动 Client
+![发现并没有注册成功实例](https://upload-images.jianshu.io/upload_images/4685968-9da416ccd633c799.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+因为没有配置注册目标地址信息
+![](https://upload-images.jianshu.io/upload_images/4685968-197f5e1401d5a4ed.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+之后再次重启,依旧无法注册成功,几经勘察,添加以下依赖后,成功运行,注册到服务器
+![](https://upload-images.jianshu.io/upload_images/4685968-dab3e741646d87da.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+再指定 client 名字
+![](https://upload-images.jianshu.io/upload_images/4685968-77b7e08397aab65e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+发现成功注册
+![](https://upload-images.jianshu.io/upload_images/4685968-447ae3cea24861ce.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+此为 client 应用ip 地址
+![](https://upload-images.jianshu.io/upload_images/4685968-393a5ff147bfb1f1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+但其实可以自定义
+![](https://upload-images.jianshu.io/upload_images/4685968-ab9f1d0f812c5310.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+接着点击进入那个链接,URL如下
+![](https://upload-images.jianshu.io/upload_images/4685968-9cc1d2a8e2e5772a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- Eureka保证AP
+有时会发现如下红色警戒!
+![](https://upload-images.jianshu.io/upload_images/4685968-273265cd6cea62c2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+Eureka看明白了这一点，因此在设计时就优先保证可用性。我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。
+如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个 Eureka节点会进入“自我保护模式”，同时保留那些“心跳死亡”的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于“死亡”的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出“自我保护模式”。Eureka的哲学是，同时保留“好数据”与“坏数据”总比丢掉任何数据要更好。
+在开发模式,最好关闭该模式(默认是开启的),仅能在开发环境关闭!,生产环境禁止关闭!!!
+![](https://upload-images.jianshu.io/upload_images/4685968-a04f2186501ce1a3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 3.4 Eureka的高可用
+如果一台 eureka宕机了咋办呢,为了实现高可用,如果直接加一台服务器并无任何卵用,考虑将两台 eureka 互相注册
+![](https://upload-images.jianshu.io/upload_images/4685968-d12648840d93b02b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+复制得到两份 eureka,并以端口区分
+![](https://upload-images.jianshu.io/upload_images/4685968-20facd35bb36e065.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+将 eureka1注册到 eureka2上并启动
+![](https://upload-images.jianshu.io/upload_images/4685968-7efb11a69e156076.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+将 eureka2注册到 eureka1上并启动
+![](https://upload-images.jianshu.io/upload_images/4685968-7aaa1fa687b23a84.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-cb47b9201d61c0c0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0da2ce887cb5af39.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+发现 client 在1,2同时都注册成功了!
+假如此时 eureka1宕机了,会发生什么呢?
+![](https://upload-images.jianshu.io/upload_images/4685968-8cce7c085770d214.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+我们来将1给关闭
+![](https://upload-images.jianshu.io/upload_images/4685968-643a84de83f0d6b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-592e41cb42871f9e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-1d6610d19c76af99.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+发现2依旧存活,并且 client 还在连接
+
+若此时再 client 端重启又会发生什么呢?
+![](https://upload-images.jianshu.io/upload_images/4685968-c0f3fd2b929bd58d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+因为无法注册,自然报错了,E2上也没有 client 端再连接了
+![](https://upload-images.jianshu.io/upload_images/4685968-e944f363b9c4fbc7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+那么问题来了,怎么才能保证 E1宕机后, client 仍能注册在 E2上呢?只要保持每次都同时往两个 E 注册
+![](https://upload-images.jianshu.io/upload_images/4685968-8642b72f32139f60.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+同理可得,当有3个 E 时,如此相互注册
+![](https://upload-images.jianshu.io/upload_images/4685968-0ded453fe1710c1e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-77be07292929c33f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a13abb86e126efb8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+新建 E3
+![](https://upload-images.jianshu.io/upload_images/4685968-ad37a6853df9330d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-343fbe2ac6417892.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-92f2e16d47fc8154.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+对于我们的开发环境,部署一个 E 即可,不再集群
+## 3.5 Eureka总结
+![](https://upload-images.jianshu.io/upload_images/4685968-c768943eef432bcd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 3.6 分布式下服务注册的地位和原理
+![](https://upload-images.jianshu.io/upload_images/4685968-c6b9c15c3c66fa36.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-8354a578001f2386.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+A 类比青楼中的嫖客, B 类比青楼女子,注册中心呢就相当于青楼中的妈咪
+一般 嫖客服务一来,就肯定直接点名春花还是秋月呀,直接问妈咪要花魁就行
+![](https://upload-images.jianshu.io/upload_images/4685968-62be3e8cab095c1b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ecfee658cd5a50b8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\272\214)-\345\276\256\346\234\215\345\212\241\344\273\213\347\273\215.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\272\214)-\345\276\256\346\234\215\345\212\241\344\273\213\347\273\215.md"
new file mode 100644
index 0000000000..9248d366b1
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\344\272\214)-\345\276\256\346\234\215\345\212\241\344\273\213\347\273\215.md"	
@@ -0,0 +1,18 @@
+![](https://upload-images.jianshu.io/upload_images/4685968-bb15b1ab6180f3a1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2c5b132a3ebcb130.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-54fea72e7b70d618.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5accc6d02ac4b3bc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-70c4f71cbf48ce4d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-4aaf4da3142c057b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-94718e55e2fef2a6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9f2a0225c4968c09.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ab9695f64bedbf0f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-4d07f4a95486bdc7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ac7131bb5c054c72.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+分布式是多节点的
+各节点通过消息通信
+![简单的微服务架构](https://upload-images.jianshu.io/upload_images/4685968-609531f9c404bdb8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![微服务架构的基础框架/组件](https://upload-images.jianshu.io/upload_images/4685968-df01f956b0234a9d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![仔细观察](https://upload-images.jianshu.io/upload_images/4685968-b5722142d2cee75d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![两大派系](https://upload-images.jianshu.io/upload_images/4685968-e53cc9d445f3446b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![SpringCloud是什么](https://upload-images.jianshu.io/upload_images/4685968-a95b46eb67682fb6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\205\255)-\347\273\237\344\270\200\351\205\215\347\275\256\344\270\255\345\277\203.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\205\255)-\347\273\237\344\270\200\351\205\215\347\275\256\344\270\255\345\277\203.md"
new file mode 100644
index 0000000000..a470667b2a
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\205\255)-\347\273\237\344\270\200\351\205\215\347\275\256\344\270\255\345\277\203.md"	
@@ -0,0 +1,41 @@
+# 1 统一配置中心概述
+##为什么需要统一配置中心
+![](https://upload-images.jianshu.io/upload_images/4685968-f0f3d011837db423.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-643d79fbceb00776.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 2 Config Server
+![](https://upload-images.jianshu.io/upload_images/4685968-0fad7b5dca0b3a38.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7e711c92c0453468.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+直接运行报错,因为会从 git拉取配置文件
+![](https://upload-images.jianshu.io/upload_images/4685968-9cc4e0bef5893fae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+在 Git 建立新仓库存放配置文件
+![](https://upload-images.jianshu.io/upload_images/4685968-420d649f55c1b7a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![配置 Git 信息后,重启成功,无报错](https://upload-images.jianshu.io/upload_images/4685968-7852959592bd1918.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![访问配置文件yml 格式](https://upload-images.jianshu.io/upload_images/4685968-5b7951651045396f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![properties格式](https://upload-images.jianshu.io/upload_images/4685968-423951f19ae6b435.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![json格式](https://upload-images.jianshu.io/upload_images/4685968-5814672f3cb205c4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+若故意将 yml 格式写错,则会报错
+![](https://upload-images.jianshu.io/upload_images/4685968-489cc6a257433f45.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+两种配置文件访问路径
+```
+/{name}-{profiles}.yml
+/{label}/{name}-{profiles}.properties]
+```
+name  服务名
+profiles 环境
+label 分支( branch)
+
+新建一个分支
+![](https://upload-images.jianshu.io/upload_images/4685968-6c4062f69c2a9b3e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+修改下配置文件,以示区别
+![](https://upload-images.jianshu.io/upload_images/4685968-264e6d807eb94200.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+访问成功
+![](https://upload-images.jianshu.io/upload_images/4685968-38b3d9837b956ce7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+git默认存放路径
+![](https://upload-images.jianshu.io/upload_images/4685968-c91e79e187a22836.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+亦可自定义路径
+![](https://upload-images.jianshu.io/upload_images/4685968-26a5431fa67a0b63.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 3 Config Client
+![在 order 添加 config-client 依赖](https://upload-images.jianshu.io/upload_images/4685968-15bf14c76ab8ceb0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![配置文件修改,删除多余信息](https://upload-images.jianshu.io/upload_images/4685968-f4c7b53b65e4a4c2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 4 SpringCloud Bus 自动刷新配置
+![架构图](https://upload-images.jianshu.io/upload_images/4685968-9578a72bb05c0772.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\215\201)-Hystrix.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\215\201)-Hystrix.md"
new file mode 100644
index 0000000000..59fe136e3a
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\215\201)-Hystrix.md"	
@@ -0,0 +1,5 @@
+# 服务容错和Hystrix
+![](https://upload-images.jianshu.io/upload_images/4685968-56b21e0f5033e24f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d64a3a1f42eb453f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-3b2dd7d937cd45b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-b38694354256c4f4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\233\233)-\345\276\256\346\234\215\345\212\241\344\270\255\347\232\204\346\234\215\345\212\241\346\213\206\345\210\206.md" "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\233\233)-\345\276\256\346\234\215\345\212\241\344\270\255\347\232\204\346\234\215\345\212\241\346\213\206\345\210\206.md"
new file mode 100644
index 0000000000..9d1dc8a9a8
--- /dev/null
+++ "b/Java/Spring Cloud/SpringCloud\345\276\256\346\234\215\345\212\241\345\256\236\346\210\230(\345\233\233)-\345\276\256\346\234\215\345\212\241\344\270\255\347\232\204\346\234\215\345\212\241\346\213\206\345\210\206.md"	
@@ -0,0 +1,95 @@
+- 订单服务源码
+https://github.com/Wasabi1234/SpringCloud_OrderDemo
+- 商品服务源码
+https://github.com/Wasabi1234/SpringCloud_ProductDemo
+- 商品服务模块全部源码
+https://github.com/Wasabi1234/productdemo
+## 4.1  微服务拆分的起点
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550369_4685968-042925eaab82e84a.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550303_4685968-ee59d11b5c06ba9f.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550754_4685968-7755a50293d64677.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550672_4685968-e1b4504fce5b99d3.png)
+## 4.2 康威定律和微服务
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550403_4685968-4977f90ef22568ae.png)
+![沟通的问题会影响系统的设计](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550884_4685968-611b2b3a9be72a8a.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634554120_4685968-ca9e7694aa5668c5.png)
+## 4.3 点餐业务服务拆分分析
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550226_4685968-2ed4805c9a22c35f.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550308_4685968-dbd9517212234eed.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550629_4685968-b3bd5fc2abab46c0.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550333_4685968-268b330ce9941318.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550308_4685968-3c84846025265eab.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550912_4685968-92f834b0a81bc5cd.png)
+## 4.4 商品服务API和SQL介绍
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550501_4685968-af53eac30a627264.png)
+## 4.5 商品服务编码实战(上)
+在 IDEA 中新建项目
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550294_4685968-1ba94b0fc18b4e83.png)
+![项目初始化 pom 文件](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550470_4685968-efb57c6681d98c53.png)
+- web 和 webflux
+旧版只有web一种模式，默认使用web。新版需指定，新增依赖
+`org.springframework.boot.spring-boot-starter-web`
+![为启动类添加该注解](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550697_4685968-36f40111d07834da.png)
+![基本配置信息](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550709_4685968-7bb4f8757e15f554.png)
+启动该类,将此服务注册到 eureka 上去
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550475_4685968-4684dc0feba86fd1.png)
+![添加所需依赖](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550393_4685968-b6019061b87c1a0d.png)
+![业务需求](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550285_4685968-ea2fe3d00fbc3789.png)
+![配置数据库相关信息](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550233_4685968-bca5fdd15a0de806.png)
+![添加 lombok 依赖](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550529_4685968-600733e1222d69df.png)
+![编写dto类](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550194_4685968-c5055963719ceb46.png)
+开始单元测试
+![编写测试类](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550337_4685968-7fead72de82acae6.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550280_4685968-2f2cbfb1b431666e.png)
+![必须要有此二注解,否则空指针异常](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550245_4685968-9574d3e17fcc40ac.png)
+![测试通过](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551786_4685968-bdb429749dd14cbd.png)
+开始编码第二个功能
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550375_4685968-cdb5d879d524cf2d.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550315_4685968-c75b5f17c12858e3.png)
+![测试通过](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551507_4685968-744d6d64bf2f4c74.png)
+## 4.6 商品服务编码实战(中)
+![编写service 层](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550567_4685968-618732d8f313184e.png)
+编码技巧,测试类可以直接继承启动类的测试类,减少注解个数,做到了最大可能的解耦
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550135_4685968-4a779983daf3a290.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550684_4685968-422d8b5809ead622.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550891_4685968-d2d5eef590dddd0c.png)
+编写 vo 包下的类
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551360_4685968-8d204aab16a0b1ea.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550602_4685968-008ea5c882904275.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551485_4685968-d936ba762101c693.png)
+## 4.7 商品服务编码实战(下)
+完成 controller 类
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550508_4685968-08f7050bcbe1c156.png)
+启动程序
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550739_4685968-22fc27466c21bfa8.png)
+![优化返回值](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550426_4685968-0678768ce9bd50ae.png)
+## 4.8 订单服务API和sql介绍
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550305_4685968-2c29041de939222f.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551339_4685968-c5571c7e6de78f4c.png)
+![业务需求](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550273_4685968-c1a272c93df12340.png)
+## 4.9 订单服务dao
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550901_4685968-fb687616f460a5bb.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550194_4685968-f2344ed092db163c.png)
+
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550396_4685968-dbdead19800e1e4a.png)
+启动
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550310_4685968-571197a3e1205212.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550194_4685968-401d9ffad64e74c8.png)
+![配置数据库信息并正常启动](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551903_4685968-8e70bf3a79d10ad9.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550194_4685968-f16ed29a3f925786.png)
+![save数据成功](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550307_4685968-df4f3b15853cb2ed.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550385_4685968-8d13f2046978010a.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550544_4685968-ec8fc1251bf7bd76.png)
+## 4.10 订单服务service
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550105_4685968-ff62c86da0d988ec.png)
+## 4.11 订单服务controller
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550336_4685968-d26cb5b5951655c7.png)
+![自定义异常](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551253_4685968-cd39d18f248fcef1.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550788_4685968-a3997dfdac5fd451.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551678_4685968-37a30452b7c48f43.png)
+![sb 引用了 gson, 所以不需要指定版本](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550290_4685968-582538d15a29edff.png)
+![测试接口](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550307_4685968-dce317cdd1542039.png)
+
+## 4.12 再看拆数据
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634550303_4685968-1e57f113611b8686.png)
+![](https://uploadfiles.nowcoder.com/files/20190616/5088755_1560634551175_4685968-7d2ae008cd9d0665.png)
diff --git "a/Java/Spring/@Autowired-\344\270\216@Resource\344\271\213\344\272\211.md" "b/Java/Spring/@Autowired-\344\270\216@Resource\344\271\213\344\272\211.md"
new file mode 100644
index 0000000000..aed93a2df1
--- /dev/null
+++ "b/Java/Spring/@Autowired-\344\270\216@Resource\344\271\213\344\272\211.md"
@@ -0,0 +1,236 @@
+# 1  共同点
+- 都可以用来装配bean.
+- 都可以写在字段上
+- 或写在setter方法上
+
+
+# 2 @Autowired 默认按 类型 装配（该注解是属Spring）
+默认要求依赖对象必须存在，如果要允许`null`值，可以设置它的`required`属性为`false`
+```
+@Autowired(required=false) 
+```
+
+若我们想使用名称装配可以结合`@Qualifier`注解一起食用，如下：
+```
+@Autowired() @Qualifier("baseDao")    
+private BaseDao baseDao;
+```
+
+# 3 @Resource 默认按 名称 装配(JDK1.6开始支持的注解)
+## 名称可以通过name属性进行指定
+若没有指定`name`属性
+- 当注解写在字段上时，默认取字段名，按照名称查找
+- 如果注解写在setter方法上默认取属性名进行装配
+- 当找不到与名称匹配的bean时才按照类型进行装配
+
+> name属性一旦指定，就只会按照名称进行装配。
+
+只不过注解处理器我们使用的是Spring提供的，是一样的，无所谓解耦不解耦的说法，两个在便利程度上是等同的。
+```
+@Resource(name="baseDao")    
+private BaseDao baseDao; 
+
+```
+
+> **byName** 通过参数名自动装配，如果一个bean的name 和另外一个bean的 property 相同，就自动装配
+**byType** 通过参数的数据类型自动自动装配，如果一个bean的数据类型和另外一个bean的property属性的数据类型兼容，就自动装配
+
+-----------------------------------------------------------------------------------------------------------------------------------------
+
+# 4 实例
+我们可以通过 @Autowired / @Resource 在 Bean 类中使用自动注入功能
+但是 Bean 一般还是需要在 XML 文件中通过 <bean> 进行定义 —— 也就是说，在 XML 配置文件中定义 Bean，通过@Autowired 或 @Resource 为 Bean 的成员变量、方法入参或构造函数入参提供自动注入的功能。
+
+- 比如下面的beans.xml
+![](https://upload-images.jianshu.io/upload_images/16782311-33b1fe625f560db1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/16782311-bdeeb0703bbb23c1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+定义了三个bean对象，但是没有了我们所述的的ref指向的内容,如下
+![](https://upload-images.jianshu.io/upload_images/16782311-418ad4fdc7435ca7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+-------------------------------------------------------------------------------------------------------
+
+# 5 区别
+spring2.5提供了基于注解的配置，可以通过注解的方式来完成注入依赖
+在Java代码中可以使用 `@Resource`或者`@Autowired`注解方式来进行注入
+
+但它们之间是有区别的
+
+## 5.1 首先来看一下：
+- @Resource默认是按照名称来装配注入的，只有当找不到与名称匹配的bean才会按照类型来装配注入
+- @Autowired默认是按照类型装配注入的，如果想按照名称来转配注入，则需要结合`@Qualifier`一起使用
+- @Resource注解是由JDK提供，而@Autowired是由Spring提供
+- @Resource和@Autowired都可以书写标注在字段或者该字段的setter方法之上
+
+## 5.2 使用注解的方式
+- 我们需要修改spring配置文件的头信息
+![](https://upload-images.jianshu.io/upload_images/16782311-7f4ed6eba0ca5725.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+
+
+- 在基于注解方式配置Spring的配置文件中，你可能会见到
+![](https://upload-images.jianshu.io/upload_images/16782311-3f2f1c60a46edb16.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 他的作用是式地向 Spring 容器注册
+```
+AutowiredAnnotationBeanPostProcessor
+CommonAnnotationBeanPostProcessor
+PersistenceAnnotationBeanPostProcessor
+RequiredAnnotationBeanPostProcessor
+```
+
+注册这4个BeanPostProcessor的作用，就是为了你的系统能够识别相应的注解。
+
+例如：
+
+要使用@Autowired，就必须事先在 Spring 容器中声明 `AutowiredAnnotationBeanPostProcessor Bean`
+
+传统声明方式如下
+```
+<bean class="org.springframework.beans.factory.annotation. AutowiredAnnotationBeanPostProcessor "/> 
+```
+
+要使用@ Resource 、@ PostConstruct、@ PreDestroy等注解就必须声明`CommonAnnotationBeanPostProcessor`
+```
+<bean class="org.springframework.beans.factory.annotation. CommonAnnotationBeanPostProcessor"/> 
+```
+
+要使用@PersistenceContext注解，就必须声明`PersistenceAnnotationBeanPostProcessor`的
+```
+<bean class="org.springframework.beans.factory.annotation.PersistenceAnnotationBeanPostProcessor"/> 
+```
+
+要使用 @Required的注解，就必须声明`RequiredAnnotationBeanPostProcessor`
+```
+<bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/> 
+```
+
+一般来说，这些注解我们还是比较常用，尤其是`Antowired`，在自动注入的时候更是经常使用，所以如果总是需要按照传统的方式一条一条配置显得有些繁琐和没有必要
+于是spring给我们提供`<context:annotation-config/>`的简化配置方式，自动帮你完成声明
+
+不过,都2019了,我们一般都会配置`包扫描路径`选项
+```
+<context:component-scan base-package=”XX.XX”/>
+```
+该配置项其实也包含了自动注入上述processor的功能，可以将 `<context:annotation-config/> `移除了.
+
+**比如：**
+
+```
+<context:component-scan base-package="carPoolingController, carPoolingService, carPoolingDao" />
+
+```
+就把controller包下 service包下 dao包下的注解全部扫描了
+
+
+## 5.3 修改以上配置文件的头信息后，我们就可以在Java代码通过注解方式来注入bean
+看下面代码
+### 5.3.1 @Resource
+
+```
+public class StudentService3 implements IStudentService {
+    //@Resource(name="studentDao")放在此处也是可行的
+    private IStudentDao studentDao;
+
+    private String id;
+
+    public void setId(String id) {
+    this.id = id;
+    }
+}
+```
+
+@Resource(name="studentDao") // 通过此注解完成从spring配置文件中查找名称为studentDao的bean来装配字段studentDao，如果spring配置文件中不存在 studentDao名称的bean则转向按照bean类型进行查找
+```
+public void setStudentDao(IStudentDao studentDao) {
+        this.studentDao = studentDao;
+}
+public void saveStudent() {
+        studentDao.saveStudent();
+        System.out.print(",ID 为："+id);
+}
+```
+
+配置文件添加如下信息
+
+```
+<bean id="studentDao" class="com.sss.dao.impl.StudentDao"></bean>
+<bean id="studentService3" class="com.sss.service.impl.StudentService3"></bean>
+
+```
+
+### 5.3.2 @Autowired
+
+```
+public class StudentService3 implements IStudentService {
+  //@Autowired放在此处也是可行的
+  private IStudentDao studentDao;
+
+  private String id;
+
+  public void setId(String id) {
+       this.id = id;
+   }
+
+```
+通过此注解完成从spring配置文件中 查找满足studentDao类型的bean
+@Qualifier("studentDao")则按照名称经行来查找转配的
+
+```
+ public void setStudentDao(IStudentDao studentDao) {
+       this.studentDao = studentDao;
+  }
+
+  public void saveStudent() {
+       studentDao.saveStudent();
+       System.out.print(",ID 为："+id);
+  }
+}
+
+```
+
+配置文件添加如下信息
+
+```
+<bean id="studentDao" class="com.wch.dao.impl.StudentDao"></bean>
+<bean id="studentService3" class="com.wch.service.impl.StudentService3" />
+
+```
+--------------------------
+
+> 当我们在xml里面为类配置注入对象时，会发现xml文件会越来越臃肿，维护起来很麻烦
+这时候我们可以使用注解这种机制来为类配置注入对象。
+
+**原生java为我们提供了 javax.annotation.Resource这个注解。**
+
+**spring框架提供了org.springframework.beans.factory.annotation.Autowired。**
+
+一般情况下我们使用 javax.annotation.Resource这个注解，因为这样我们就能实现和spring框架的解藕（不过注解处理器还是Spring提供的）。
+
+# @Resource可以作用于字段和函数上
+## 当作用于字段上的时候
+如果我们只是简单的这样写
+
+```
+@Resource
+PersonDao  p;
+
+```
+
+这时候spring注入p的过程是 
+- 查找xml中是否有id为p的元素
+- 如果没有找到，则看是否有name属性（@Resource name=“”），有则查找name
+- 否则查找PersonDao类型的元素
+
+## @Resource可作用于set函数上。
+例如：
+```
+@Resource
+public void setP(PersonDao p) {
+  this.p = p;
+}
+
+```
+@Autowired注解是根据类型进行查找，比如PersonDao p，他会去xml文件里查找类型为PersonDao的元素
diff --git "a/Java/Spring/Spring--Http\346\272\220\347\240\201.md" "b/Java/Spring/Spring--Http\346\272\220\347\240\201.md"
new file mode 100644
index 0000000000..ac65c21c7e
--- /dev/null
+++ "b/Java/Spring/Spring--Http\346\272\220\347\240\201.md"
@@ -0,0 +1,541 @@
+/*
+ * Copyright 2002-2017 the original author or authors.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.springframework.http;
+
+/**
+ * Enumeration of HTTP status codes.
+ *
+ * <p>The HTTP status code series can be retrieved via {@link #series()}.
+ *
+ * @author Arjen Poutsma
+ * @author Sebastien Deleuze
+ * @author Brian Clozel
+ * @since 3.0
+ * @see HttpStatus.Series
+ * @see <a href="http://www.iana.org/assignments/http-status-codes">HTTP Status Code Registry</a>
+ * @see <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes">List of HTTP status codes - Wikipedia</a>
+ */
+public enum HttpStatus {
+
+	// 1xx Informational
+
+	/**
+	 * {@code 100 Continue}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.2.1">HTTP/1.1: Semantics and Content, section 6.2.1</a>
+	 */
+	CONTINUE(100, "Continue"),
+	/**
+	 * {@code 101 Switching Protocols}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.2.2">HTTP/1.1: Semantics and Content, section 6.2.2</a>
+	 */
+	SWITCHING_PROTOCOLS(101, "Switching Protocols"),
+	/**
+	 * {@code 102 Processing}.
+	 * @see <a href="http://tools.ietf.org/html/rfc2518#section-10.1">WebDAV</a>
+	 */
+	PROCESSING(102, "Processing"),
+	/**
+	 * {@code 103 Checkpoint}.
+	 * @see <a href="http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal">A proposal for supporting
+	 * resumable POST/PUT HTTP requests in HTTP/1.0</a>
+	 */
+	CHECKPOINT(103, "Checkpoint"),
+
+	// 2xx Success
+
+	/**
+	 * {@code 200 OK}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.3.1">HTTP/1.1: Semantics and Content, section 6.3.1</a>
+	 */
+	OK(200, "OK"),
+	/**
+	 * {@code 201 Created}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.3.2">HTTP/1.1: Semantics and Content, section 6.3.2</a>
+	 */
+	CREATED(201, "Created"),
+	/**
+	 * {@code 202 Accepted}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.3.3">HTTP/1.1: Semantics and Content, section 6.3.3</a>
+	 */
+	ACCEPTED(202, "Accepted"),
+	/**
+	 * {@code 203 Non-Authoritative Information}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.3.4">HTTP/1.1: Semantics and Content, section 6.3.4</a>
+	 */
+	NON_AUTHORITATIVE_INFORMATION(203, "Non-Authoritative Information"),
+	/**
+	 * {@code 204 No Content}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.3.5">HTTP/1.1: Semantics and Content, section 6.3.5</a>
+	 */
+	NO_CONTENT(204, "No Content"),
+	/**
+	 * {@code 205 Reset Content}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.3.6">HTTP/1.1: Semantics and Content, section 6.3.6</a>
+	 */
+	RESET_CONTENT(205, "Reset Content"),
+	/**
+	 * {@code 206 Partial Content}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7233#section-4.1">HTTP/1.1: Range Requests, section 4.1</a>
+	 */
+	PARTIAL_CONTENT(206, "Partial Content"),
+	/**
+	 * {@code 207 Multi-Status}.
+	 * @see <a href="http://tools.ietf.org/html/rfc4918#section-13">WebDAV</a>
+	 */
+	MULTI_STATUS(207, "Multi-Status"),
+	/**
+	 * {@code 208 Already Reported}.
+	 * @see <a href="http://tools.ietf.org/html/rfc5842#section-7.1">WebDAV Binding Extensions</a>
+	 */
+	ALREADY_REPORTED(208, "Already Reported"),
+	/**
+	 * {@code 226 IM Used}.
+	 * @see <a href="http://tools.ietf.org/html/rfc3229#section-10.4.1">Delta encoding in HTTP</a>
+	 */
+	IM_USED(226, "IM Used"),
+
+	// 3xx Redirection
+
+	/**
+	 * {@code 300 Multiple Choices}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.4.1">HTTP/1.1: Semantics and Content, section 6.4.1</a>
+	 */
+	MULTIPLE_CHOICES(300, "Multiple Choices"),
+	/**
+	 * {@code 301 Moved Permanently}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.4.2">HTTP/1.1: Semantics and Content, section 6.4.2</a>
+	 */
+	MOVED_PERMANENTLY(301, "Moved Permanently"),
+	/**
+	 * {@code 302 Found}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.4.3">HTTP/1.1: Semantics and Content, section 6.4.3</a>
+	 */
+	FOUND(302, "Found"),
+	/**
+	 * {@code 302 Moved Temporarily}.
+	 * @see <a href="http://tools.ietf.org/html/rfc1945#section-9.3">HTTP/1.0, section 9.3</a>
+	 * @deprecated in favor of {@link #FOUND} which will be returned from {@code HttpStatus.valueOf(302)}
+	 */
+	@Deprecated
+	MOVED_TEMPORARILY(302, "Moved Temporarily"),
+	/**
+	 * {@code 303 See Other}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.4.4">HTTP/1.1: Semantics and Content, section 6.4.4</a>
+	 */
+	SEE_OTHER(303, "See Other"),
+	/**
+	 * {@code 304 Not Modified}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7232#section-4.1">HTTP/1.1: Conditional Requests, section 4.1</a>
+	 */
+	NOT_MODIFIED(304, "Not Modified"),
+	/**
+	 * {@code 305 Use Proxy}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.4.5">HTTP/1.1: Semantics and Content, section 6.4.5</a>
+	 * @deprecated due to security concerns regarding in-band configuration of a proxy
+	 */
+	@Deprecated
+	USE_PROXY(305, "Use Proxy"),
+	/**
+	 * {@code 307 Temporary Redirect}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.4.7">HTTP/1.1: Semantics and Content, section 6.4.7</a>
+	 */
+	TEMPORARY_REDIRECT(307, "Temporary Redirect"),
+	/**
+	 * {@code 308 Permanent Redirect}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7238">RFC 7238</a>
+	 */
+	PERMANENT_REDIRECT(308, "Permanent Redirect"),
+
+	// --- 4xx Client Error ---
+
+	/**
+	 * {@code 400 Bad Request}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.1">HTTP/1.1: Semantics and Content, section 6.5.1</a>
+	 */
+	BAD_REQUEST(400, "Bad Request"),
+	/**
+	 * {@code 401 Unauthorized}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7235#section-3.1">HTTP/1.1: Authentication, section 3.1</a>
+	 */
+	UNAUTHORIZED(401, "Unauthorized"),
+	/**
+	 * {@code 402 Payment Required}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.2">HTTP/1.1: Semantics and Content, section 6.5.2</a>
+	 */
+	PAYMENT_REQUIRED(402, "Payment Required"),
+	/**
+	 * {@code 403 Forbidden}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.3">HTTP/1.1: Semantics and Content, section 6.5.3</a>
+	 */
+	FORBIDDEN(403, "Forbidden"),
+	/**
+	 * {@code 404 Not Found}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.4">HTTP/1.1: Semantics and Content, section 6.5.4</a>
+	 */
+	NOT_FOUND(404, "Not Found"),
+	/**
+	 * {@code 405 Method Not Allowed}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.5">HTTP/1.1: Semantics and Content, section 6.5.5</a>
+	 */
+	METHOD_NOT_ALLOWED(405, "Method Not Allowed"),
+	/**
+	 * {@code 406 Not Acceptable}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.6">HTTP/1.1: Semantics and Content, section 6.5.6</a>
+	 */
+	NOT_ACCEPTABLE(406, "Not Acceptable"),
+	/**
+	 * {@code 407 Proxy Authentication Required}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7235#section-3.2">HTTP/1.1: Authentication, section 3.2</a>
+	 */
+	PROXY_AUTHENTICATION_REQUIRED(407, "Proxy Authentication Required"),
+	/**
+	 * {@code 408 Request Timeout}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.7">HTTP/1.1: Semantics and Content, section 6.5.7</a>
+	 */
+	REQUEST_TIMEOUT(408, "Request Timeout"),
+	/**
+	 * {@code 409 Conflict}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.8">HTTP/1.1: Semantics and Content, section 6.5.8</a>
+	 */
+	CONFLICT(409, "Conflict"),
+	/**
+	 * {@code 410 Gone}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.9">HTTP/1.1: Semantics and Content, section 6.5.9</a>
+	 */
+	GONE(410, "Gone"),
+	/**
+	 * {@code 411 Length Required}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.10">HTTP/1.1: Semantics and Content, section 6.5.10</a>
+	 */
+	LENGTH_REQUIRED(411, "Length Required"),
+	/**
+	 * {@code 412 Precondition failed}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7232#section-4.2">HTTP/1.1: Conditional Requests, section 4.2</a>
+	 */
+	PRECONDITION_FAILED(412, "Precondition Failed"),
+	/**
+	 * {@code 413 Payload Too Large}.
+	 * @since 4.1
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.11">HTTP/1.1: Semantics and Content, section 6.5.11</a>
+	 */
+	PAYLOAD_TOO_LARGE(413, "Payload Too Large"),
+	/**
+	 * {@code 413 Request Entity Too Large}.
+	 * @see <a href="http://tools.ietf.org/html/rfc2616#section-10.4.14">HTTP/1.1, section 10.4.14</a>
+	 * @deprecated in favor of {@link #PAYLOAD_TOO_LARGE} which will be returned from {@code HttpStatus.valueOf(413)}
+	 */
+	@Deprecated
+	REQUEST_ENTITY_TOO_LARGE(413, "Request Entity Too Large"),
+	/**
+	 * {@code 414 URI Too Long}.
+	 * @since 4.1
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.12">HTTP/1.1: Semantics and Content, section 6.5.12</a>
+	 */
+	URI_TOO_LONG(414, "URI Too Long"),
+	/**
+	 * {@code 414 Request-URI Too Long}.
+	 * @see <a href="http://tools.ietf.org/html/rfc2616#section-10.4.15">HTTP/1.1, section 10.4.15</a>
+	 * @deprecated in favor of {@link #URI_TOO_LONG} which will be returned from {@code HttpStatus.valueOf(414)}
+	 */
+	@Deprecated
+	REQUEST_URI_TOO_LONG(414, "Request-URI Too Long"),
+	/**
+	 * {@code 415 Unsupported Media Type}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.13">HTTP/1.1: Semantics and Content, section 6.5.13</a>
+	 */
+	UNSUPPORTED_MEDIA_TYPE(415, "Unsupported Media Type"),
+	/**
+	 * {@code 416 Requested Range Not Satisfiable}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7233#section-4.4">HTTP/1.1: Range Requests, section 4.4</a>
+	 */
+	REQUESTED_RANGE_NOT_SATISFIABLE(416, "Requested range not satisfiable"),
+	/**
+	 * {@code 417 Expectation Failed}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.5.14">HTTP/1.1: Semantics and Content, section 6.5.14</a>
+	 */
+	EXPECTATION_FAILED(417, "Expectation Failed"),
+	/**
+	 * {@code 418 I'm a teapot}.
+	 * @see <a href="http://tools.ietf.org/html/rfc2324#section-2.3.2">HTCPCP/1.0</a>
+	 */
+	I_AM_A_TEAPOT(418, "I'm a teapot"),
+	/**
+	 * @deprecated See <a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-webdav-protocol-06.txt">WebDAV Draft Changes</a>
+	 */
+	@Deprecated
+	INSUFFICIENT_SPACE_ON_RESOURCE(419, "Insufficient Space On Resource"),
+	/**
+	 * @deprecated See <a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-webdav-protocol-06.txt">WebDAV Draft Changes</a>
+	 */
+	@Deprecated
+	METHOD_FAILURE(420, "Method Failure"),
+	/**
+	 * @deprecated See <a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-webdav-protocol-06.txt">WebDAV Draft Changes</a>
+	 */
+	@Deprecated
+	DESTINATION_LOCKED(421, "Destination Locked"),
+	/**
+	 * {@code 422 Unprocessable Entity}.
+	 * @see <a href="http://tools.ietf.org/html/rfc4918#section-11.2">WebDAV</a>
+	 */
+	UNPROCESSABLE_ENTITY(422, "Unprocessable Entity"),
+	/**
+	 * {@code 423 Locked}.
+	 * @see <a href="http://tools.ietf.org/html/rfc4918#section-11.3">WebDAV</a>
+	 */
+	LOCKED(423, "Locked"),
+	/**
+	 * {@code 424 Failed Dependency}.
+	 * @see <a href="http://tools.ietf.org/html/rfc4918#section-11.4">WebDAV</a>
+	 */
+	FAILED_DEPENDENCY(424, "Failed Dependency"),
+	/**
+	 * {@code 426 Upgrade Required}.
+	 * @see <a href="http://tools.ietf.org/html/rfc2817#section-6">Upgrading to TLS Within HTTP/1.1</a>
+	 */
+	UPGRADE_REQUIRED(426, "Upgrade Required"),
+	/**
+	 * {@code 428 Precondition Required}.
+	 * @see <a href="http://tools.ietf.org/html/rfc6585#section-3">Additional HTTP Status Codes</a>
+	 */
+	PRECONDITION_REQUIRED(428, "Precondition Required"),
+	/**
+	 * {@code 429 Too Many Requests}.
+	 * @see <a href="http://tools.ietf.org/html/rfc6585#section-4">Additional HTTP Status Codes</a>
+	 */
+	TOO_MANY_REQUESTS(429, "Too Many Requests"),
+	/**
+	 * {@code 431 Request Header Fields Too Large}.
+	 * @see <a href="http://tools.ietf.org/html/rfc6585#section-5">Additional HTTP Status Codes</a>
+	 */
+	REQUEST_HEADER_FIELDS_TOO_LARGE(431, "Request Header Fields Too Large"),
+	/**
+	 * {@code 451 Unavailable For Legal Reasons}.
+	 * @see <a href="https://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-04">
+	 * An HTTP Status Code to Report Legal Obstacles</a>
+	 * @since 4.3
+	 */
+	UNAVAILABLE_FOR_LEGAL_REASONS(451, "Unavailable For Legal Reasons"),
+
+	// --- 5xx Server Error ---
+
+	/**
+	 * {@code 500 Internal Server Error}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.6.1">HTTP/1.1: Semantics and Content, section 6.6.1</a>
+	 */
+	INTERNAL_SERVER_ERROR(500, "Internal Server Error"),
+	/**
+	 * {@code 501 Not Implemented}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.6.2">HTTP/1.1: Semantics and Content, section 6.6.2</a>
+	 */
+	NOT_IMPLEMENTED(501, "Not Implemented"),
+	/**
+	 * {@code 502 Bad Gateway}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.6.3">HTTP/1.1: Semantics and Content, section 6.6.3</a>
+	 */
+	BAD_GATEWAY(502, "Bad Gateway"),
+	/**
+	 * {@code 503 Service Unavailable}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.6.4">HTTP/1.1: Semantics and Content, section 6.6.4</a>
+	 */
+	SERVICE_UNAVAILABLE(503, "Service Unavailable"),
+	/**
+	 * {@code 504 Gateway Timeout}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.6.5">HTTP/1.1: Semantics and Content, section 6.6.5</a>
+	 */
+	GATEWAY_TIMEOUT(504, "Gateway Timeout"),
+	/**
+	 * {@code 505 HTTP Version Not Supported}.
+	 * @see <a href="http://tools.ietf.org/html/rfc7231#section-6.6.6">HTTP/1.1: Semantics and Content, section 6.6.6</a>
+	 */
+	HTTP_VERSION_NOT_SUPPORTED(505, "HTTP Version not supported"),
+	/**
+	 * {@code 506 Variant Also Negotiates}
+	 * @see <a href="http://tools.ietf.org/html/rfc2295#section-8.1">Transparent Content Negotiation</a>
+	 */
+	VARIANT_ALSO_NEGOTIATES(506, "Variant Also Negotiates"),
+	/**
+	 * {@code 507 Insufficient Storage}
+	 * @see <a href="http://tools.ietf.org/html/rfc4918#section-11.5">WebDAV</a>
+	 */
+	INSUFFICIENT_STORAGE(507, "Insufficient Storage"),
+	/**
+	 * {@code 508 Loop Detected}
+	 * @see <a href="http://tools.ietf.org/html/rfc5842#section-7.2">WebDAV Binding Extensions</a>
+ 	 */
+	LOOP_DETECTED(508, "Loop Detected"),
+	/**
+	 * {@code 509 Bandwidth Limit Exceeded}
+ 	 */
+	BANDWIDTH_LIMIT_EXCEEDED(509, "Bandwidth Limit Exceeded"),
+	/**
+	 * {@code 510 Not Extended}
+	 * @see <a href="http://tools.ietf.org/html/rfc2774#section-7">HTTP Extension Framework</a>
+	 */
+	NOT_EXTENDED(510, "Not Extended"),
+	/**
+	 * {@code 511 Network Authentication Required}.
+	 * @see <a href="http://tools.ietf.org/html/rfc6585#section-6">Additional HTTP Status Codes</a>
+	 */
+	NETWORK_AUTHENTICATION_REQUIRED(511, "Network Authentication Required");
+
+
+	private final int value;
+
+	private final String reasonPhrase;
+
+
+	HttpStatus(int value, String reasonPhrase) {
+		this.value = value;
+		this.reasonPhrase = reasonPhrase;
+	}
+
+
+	/**
+	 * Return the integer value of this status code.
+	 */
+	public int value() {
+		return this.value;
+	}
+
+	/**
+	 * Return the reason phrase of this status code.
+	 */
+	public String getReasonPhrase() {
+		return this.reasonPhrase;
+	}
+
+	/**
+	 * Whether this status code is in the HTTP series
+	 * {@link org.springframework.http.HttpStatus.Series#INFORMATIONAL}.
+	 * This is a shortcut for checking the value of {@link #series()}.
+	 */
+	public boolean is1xxInformational() {
+		return Series.INFORMATIONAL.equals(series());
+	}
+
+	/**
+	 * Whether this status code is in the HTTP series
+	 * {@link org.springframework.http.HttpStatus.Series#SUCCESSFUL}.
+	 * This is a shortcut for checking the value of {@link #series()}.
+	 */
+	public boolean is2xxSuccessful() {
+		return Series.SUCCESSFUL.equals(series());
+	}
+
+	/**
+	 * Whether this status code is in the HTTP series
+	 * {@link org.springframework.http.HttpStatus.Series#REDIRECTION}.
+	 * This is a shortcut for checking the value of {@link #series()}.
+	 */
+	public boolean is3xxRedirection() {
+		return Series.REDIRECTION.equals(series());
+	}
+
+
+	/**
+	 * Whether this status code is in the HTTP series
+	 * {@link org.springframework.http.HttpStatus.Series#CLIENT_ERROR}.
+	 * This is a shortcut for checking the value of {@link #series()}.
+	 */
+	public boolean is4xxClientError() {
+		return Series.CLIENT_ERROR.equals(series());
+	}
+
+	/**
+	 * Whether this status code is in the HTTP series
+	 * {@link org.springframework.http.HttpStatus.Series#SERVER_ERROR}.
+	 * This is a shortcut for checking the value of {@link #series()}.
+	 */
+	public boolean is5xxServerError() {
+		return Series.SERVER_ERROR.equals(series());
+	}
+
+	/**
+	 * Returns the HTTP status series of this status code.
+	 * @see HttpStatus.Series
+	 */
+	public Series series() {
+		return Series.valueOf(this);
+	}
+
+	/**
+	 * Return a string representation of this status code.
+	 */
+	@Override
+	public String toString() {
+		return Integer.toString(this.value);
+	}
+
+
+	/**
+	 * Return the enum constant of this type with the specified numeric value.
+	 * @param statusCode the numeric value of the enum to be returned
+	 * @return the enum constant with the specified numeric value
+	 * @throws IllegalArgumentException if this enum has no constant for the specified numeric value
+	 */
+	public static HttpStatus valueOf(int statusCode) {
+		for (HttpStatus status : values()) {
+			if (status.value == statusCode) {
+				return status;
+			}
+		}
+		throw new IllegalArgumentException("No matching constant for [" + statusCode + "]");
+	}
+
+
+	/**
+	 * Enumeration of HTTP status series.
+	 * <p>Retrievable via {@link HttpStatus#series()}.
+	 */
+	public enum Series {
+
+		INFORMATIONAL(1),
+		SUCCESSFUL(2),
+		REDIRECTION(3),
+		CLIENT_ERROR(4),
+		SERVER_ERROR(5);
+
+		private final int value;
+
+		Series(int value) {
+			this.value = value;
+		}
+
+		/**
+		 * Return the integer value of this status series. Ranges from 1 to 5.
+		 */
+		public int value() {
+			return this.value;
+		}
+
+		public static Series valueOf(int status) {
+			int seriesCode = status / 100;
+			for (Series series : values()) {
+				if (series.value == seriesCode) {
+					return series;
+				}
+			}
+			throw new IllegalArgumentException("No matching constant for [" + status + "]");
+		}
+
+		public static Series valueOf(HttpStatus status) {
+			return valueOf(status.value);
+		}
+	}
+
+}
diff --git "a/Java/Spring/Spring-5-0\344\270\255\346\226\207\347\211\210-3-9.md" "b/Java/Spring/Spring-5-0\344\270\255\346\226\207\347\211\210-3-9.md"
new file mode 100644
index 0000000000..7d17d999e3
--- /dev/null
+++ "b/Java/Spring/Spring-5-0\344\270\255\346\226\207\347\211\210-3-9.md"
@@ -0,0 +1,697 @@
+### 3.9 基于注解的容器配置
+
+> **在配置Spring时注解是否比XML更好？**
+> 
+> 基于注解配置的引入引出了一个问题——这种方式是否比基于XML的配置更好。简短的回答是视情况而定。长一点的回答是每种方法都有它的优点和缺点，通常是由开发者决定哪一种策略更适合他们。由于注解的定义方式，注解在它们的声明中提供了许多上下文，导致配置更简短更简洁。然而，XML擅长连接组件而不必接触源代码或重新编译它们。一些开发者更喜欢接近源代码，而另一些人则认为基于注解的类不再是POJOs，此外，配置变的去中心化，而且更难控制。
+> 
+> 无论选择是什么，Spring都能容纳这两种风格，甚至可以将它们混合在一起。值得指出的是，通过它的Java配置选项，Spring允许注解以一种非入侵的方式使用，不触碰目标组件源码和那些工具，所有的配置风格由Spring工具套件支持。
+
+基于注解的配置提供了一种XML设置的可替代方式，它依赖于字节码元数据来连接组件，而不是用尖括号声明的方式。代替使用XML来描述bean连接，开发者通过将注解使用在相关的类，方法或字段声明中，将配置移动到了组件类本身的内部。正如在“Example: The RequiredAnnotationBeanPostProcessor”那节提到的那样，使用`BeanPostProcessor`与注解结合是扩展Spring IoC容器的的常见方法。例如，Spring 2.0引入了`@Required`注解来执行需要的属性的可能性。Spring 2.5使以同样地通用方法来驱动Spring的依赖注入变为可能。本质上来说，`@Autowired`提供了如3.4.5小节描述的同样的能力。“Autowiring collaborators”但更细粒度的控制和更广的应用性。Spring 2.5也添加对JSR-250注解的支持，例如，`@PostConstruct`和`@PreDestroy` 
+。Spring 3.0添加了对JSR-330，包含在`javax.inject`包内的注解（Java的依赖注入）的支持，例如`@Inject`和`@Named`。关于这些注解的细节可以在相关的小节找到。
+
+> 注解注入在XML注入之前进行，因此对于通过两种方法进行组装的属性后者的配置会覆盖前者。
+
+跟以前一样，你可以作为单独的bean定义来注册它们，但也可以通过在一个基于XML的Spring配置（注入包含上下文命名空间）中包含下面的标签来隐式的注册它们：
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xmlns:context="http://www.springframework.org/schema/context"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans
+        http://www.springframework.org/schema/beans/spring-beans.xsd
+        http://www.springframework.org/schema/context
+        http://www.springframework.org/schema/context/spring-context.xsd">
+
+    <context:annotation-config/>
+
+</beans>
+```
+
+（隐式注册的后处理器包括 `AutowiredAnnotationBeanPostProcessor`，`CommonAnnotationBeanPostProcessor`，`PersistenceAnnotationBeanPostProcessor`和前面提到的`RequiredAnnotationBeanPostProcessor`。）
+
+> `<context:annotation-config/>`仅在定义它的同样的应用上下文中寻找注解的beans。这意味着，如果你在一个为`DispatcherServlet`服务的`WebApplicationContext`中放置了`<context:annotation-config/>`，它只能在你的控制器中寻找`@Autowired`注解的beans，而不是在你的服务层中。更多信息请看18.2小节，“The DispatcherServlet”。
+
+#### 3.9.1 @Required
+
+`@Required`注解应用到bean属性的setter方法上，例子如下：
+
+```
+public class SimpleMovieLister {
+
+    private MovieFinder movieFinder;
+
+    @Required
+    public void setMovieFinder(MovieFinder movieFinder) {
+        this.movieFinder = movieFinder;
+    }
+
+    // ...
+
+}
+```
+
+这个注解仅仅是表明受影响的bean属性必须在配置时通过显式的bean定义或自动组装填充。如果受影响的bean属性没有填充，容器会抛出一个异常，这允许及早明确的失败，避免`NullPointerExceptions`或后面出现类似的情况。仍然建议你在bean类本身加入断言，例如，加入到初始化方法中。这样做可以强制这些需要的引用和值，甚至是你在容器外部使用这个类的时候。
+
+#### 3.9.2 @Autowired
+
+> 在下面的例子中JSR 330的`@Inject`注解可以用来代替Spring的`@Autowired`注解。
+
+你可以将`@Autowired`注解应用到构造函数上。
+
+```
+public class MovieRecommender {
+
+    private final CustomerPreferenceDao customerPreferenceDao;
+
+    @Autowired
+    public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
+        this.customerPreferenceDao = customerPreferenceDao;
+    }
+
+    // ...
+
+}
+```
+
+> 从Spring框架4.3起，如果目标bena仅定义了一个构造函数，那么`@Autowired`注解的构造函数不再是必要的。如果一些构造函数是可获得的，至少有一个必须要加上注解，以便于告诉容器使用哪一个。
+
+正如预料的那样，你也可以将`@Autowired`注解应用到“传统的”setter方法上：
+
+```
+public class SimpleMovieLister {
+
+    private MovieFinder movieFinder;
+
+    @Autowired
+    public void setMovieFinder(MovieFinder movieFinder) {
+        this.movieFinder = movieFinder;
+    }
+
+    // ...
+
+}
+```
+
+你也可以应用注解到具有任何名字和/或多个参数的方法上：
+
+```
+public class MovieRecommender {
+
+    private MovieCatalog movieCatalog;
+
+    private CustomerPreferenceDao customerPreferenceDao;
+
+    @Autowired
+    public void prepare(MovieCatalog movieCatalog,
+            CustomerPreferenceDao customerPreferenceDao) {
+        this.movieCatalog = movieCatalog;
+        this.customerPreferenceDao = customerPreferenceDao;
+    }
+
+    // ...
+
+}
+```
+
+你也可以应用`@Autowired`到字段上，甚至可以与构造函数混合用：
+
+```
+public class MovieRecommender {
+
+    private final CustomerPreferenceDao customerPreferenceDao;
+
+    @Autowired
+    private MovieCatalog movieCatalog;
+
+    @Autowired
+    public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
+        this.customerPreferenceDao = customerPreferenceDao;
+    }
+
+    // ...
+
+}
+```
+
+通过给带有数组的字段或方法添加`@Autowired`注解，也可以从`ApplicationContext`中提供一组特定类型的bean：
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    private MovieCatalog[] movieCatalogs;
+
+    // ...
+
+}
+```
+
+同样也可以应用到具有同一类型的集合上：
+
+```
+public class MovieRecommender {
+
+    private Set<MovieCatalog> movieCatalogs;
+
+    @Autowired
+    public void setMovieCatalogs(Set<MovieCatalog> movieCatalogs) {
+        this.movieCatalogs = movieCatalogs;
+    }
+
+    // ...
+
+}
+```
+
+> 如果你希望数组或列表中的项按指定顺序排序，你的bean可以实现`org.springframework.core.Ordered`接口，或使用`@Order`或标准`@Priority`注解。
+
+只要期望的key是`String`，那么类型化的Maps就可以自动组装。Map的值将包含所有期望类型的beans，key将包含对应的bean名字：
+
+```
+public class MovieRecommender {
+
+    private Map<String, MovieCatalog> movieCatalogs;
+
+    @Autowired
+    public void setMovieCatalogs(Map<String, MovieCatalog> movieCatalogs) {
+        this.movieCatalogs = movieCatalogs;
+    }
+
+    // ...
+
+}
+```
+
+默认情况下，当没有候选beans可获得时，自动组装会失败；默认的行为是将注解的方法，构造函数和字段看作指明了需要的依赖。这个行为也可以通过下面的方式去改变。
+
+```
+public class SimpleMovieLister {
+
+    private MovieFinder movieFinder;
+
+    @Autowired(required=false)
+    public void setMovieFinder(MovieFinder movieFinder) {
+        this.movieFinder = movieFinder;
+    }
+
+    // ...
+
+}
+```
+
+> 每个类只有一个构造函数可以标记为必需的，但可以注解多个非必需的构造函数。在这种情况下，会考虑这些候选者中的每一个，Spring使用最贪婪的构造函数，即依赖最满足的构造函数，具有最大数目的参数。
+> 
+> 建议在`@Required`注解之上使用`@Autowired`的`required`特性。`required`特性表明这个属性自动装配是不需要的，如果这个属性不能被自动装配，它会被忽略。另一方面`@Required`是更强大的，在它强制这个属性被任何容器支持的bean设置。如果没有值注入，会抛出对应的异常。
+
+你也可以对那些已知的具有可解析依赖的接口使用`@Autowired`：`BeanFactory`，`ApplicationContext`，`Environment`, `ResourceLoader`，`ApplicationEventPublisher`和`MessageSource`。这些接口和它们的扩展接口，例如`ConfigurableApplicationContext`或`ResourcePatternResolver`，可以自动解析，不需要特别的设置。
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    private ApplicationContext context;
+
+    public MovieRecommender() {
+    }
+
+    // ...
+
+}
+```
+
+> `@Autowired`，`@Inject`，`@Resource`和`@Value`注解是通过Spring `BeanPostProcessor`实现处理，这反过来意味着你不能在你自己的`BeanPostProcessor`或`BeanFactoryPostProcessor`中应用这些注解（如果有的话）。这些类型必须显式的通过XML或使用Spring的`@Bean`方法来’wired up’。
+
+#### 3.9.3 用@Primary微调基于注解的自动装配
+
+因为根据类型的自动装配可能会导致多个候选目标，所以在选择过程中进行更多的控制经常是有必要的。一种方式通过Spring的`@Primary`注解来完成。当有个多个候选bean要组装到一个单值的依赖时，`@Primary`表明指定的bean应该具有更高的优先级。如果确定一个’primary’ bean位于候选目标中间，它将是那个自动装配的值。
+
+假设我们具有如下配置，将`firstMovieCatalog`定义为主要的`MovieCatalog`。
+
+```
+@Configuration
+public class MovieConfiguration {
+
+    @Bean
+    @Primary
+    public MovieCatalog firstMovieCatalog() { ... }
+
+    @Bean
+    public MovieCatalog secondMovieCatalog() { ... }
+
+    // ...
+
+}
+```
+
+根据这样的配置，下面的`MovieRecommender`将用`firstMovieCatalog`进行自动装配。
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    private MovieCatalog movieCatalog;
+
+    // ...
+
+}
+```
+
+对应的bean定义如下：
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xmlns:context="http://www.springframework.org/schema/context"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans
+        http://www.springframework.org/schema/beans/spring-beans.xsd
+        http://www.springframework.org/schema/context
+        http://www.springframework.org/schema/context/spring-context.xsd">
+
+    <context:annotation-config/>
+
+    <bean class="example.SimpleMovieCatalog" primary="true">
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean class="example.SimpleMovieCatalog">
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean id="movieRecommender" class="example.MovieRecommender"/>
+
+</beans>
+```
+
+#### 3.9.4 微调基于注解且带有限定符的自动装配
+
+当有多个实例需要确定一个主要的候选对象时，`@Primary`是一种按类型自动装配的有效方式。当需要在选择过程中进行更多的控制时，可以使用Spring的`@Qualifier`注解。为了给每个选择一个特定的bean，你可以将限定符的值与特定的参数联系在一起，减少类型匹配集合。在最简单的情况下，这是一个纯描述性值:
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    @Qualifier("main")
+    private MovieCatalog movieCatalog;
+
+    // ...
+
+}
+```
+
+`@Qualifier`注解也可以指定单个构造函数参数或方法参数：
+
+```
+public class MovieRecommender {
+
+    private MovieCatalog movieCatalog;
+
+    private CustomerPreferenceDao customerPreferenceDao;
+
+    @Autowired
+    public void prepare(@Qualifier("main")MovieCatalog movieCatalog,
+            CustomerPreferenceDao customerPreferenceDao) {
+        this.movieCatalog = movieCatalog;
+        this.customerPreferenceDao = customerPreferenceDao;
+    }
+
+    // ...
+
+}
+```
+
+对应的bean定义如下。限定符值为”main”的bean被组装到有相同值的构造函数参数中。
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xmlns:context="http://www.springframework.org/schema/context"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans
+        http://www.springframework.org/schema/beans/spring-beans.xsd
+        http://www.springframework.org/schema/context
+        http://www.springframework.org/schema/context/spring-context.xsd">
+
+    <context:annotation-config/>
+
+    <bean class="example.SimpleMovieCatalog">
+        <qualifier value="main"/>
+
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean class="example.SimpleMovieCatalog">
+        <qualifier value="action"/>
+
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean id="movieRecommender" class="example.MovieRecommender"/>
+
+</beans>
+```
+
+对于回退匹配，bean名字被认为是默认的限定符值。因此你可以定义一个id为`main`的bean来代替内嵌的限定符元素，会有同样的匹配结果。然而，尽管你可以使用这个约定根据名字引用特定的beans，但是`@Autowired`从根本上来讲是使用可选的语义限定符来进行类型驱动注入的。这意味着限定符的值，即使回退到bean名称，总是缩小语义类型匹配的集合；它们没有从语义上将一个引用表达为一个唯一的bean id。好的限定符值是”main”或”EMEA”或”persistent”，表达一个特定组件的性质，这个组件是独立于bean `id`的，即使前面例子中像这个bean一样的匿名bean会自动生成id。
+
+正如前面讨论的那样，限定符也可以应用到类型结合上，例如，`Set<MovieCatalog>`。在这个例子中，根据声明的限定符匹配的所有beans作为一个集合进行注入。这意味着限定符不必是唯一的；它们只是构成过滤标准。例如，你可以定义多个具有同样限定符值”action”的`MovieCatalog`，所有的这些都将注入到带有注解`@Qualifier("action")`的`Set<MovieCatalog>`中。
+
+> 如果你想通过名字表达注解驱动的注入，不要主要使用`@Autowired`，虽然在技术上能通过`@Qualifier`值引用一个bean名字。作为可替代产品，可以使用JSR-250 `@Resource`注解，它在语义上被定义为通过组件唯一的名字来识别特定的目标组件，声明的类型与匹配过程无关。`@Autowired`有不同的语义：通过类型选择候选beans，特定的`String`限定符值被认为只在类型选择的候选目标中，例如，在那些标记为具有相同限定符标签的beans中匹配一个”account”限定符。
+> 
+> 对于那些本身定义在集合/映射或数组类型中的beans来说，`@Resource`是一个很好的解决方案，适用于特定的集合或通过唯一名字区分的数组bean。也就是说，自Spring 4.3起，集合/映射和数组类型中也可以通过Spring的`@Autowired`类型匹配算法进行匹配，只要元素类型信息在`@Bean`中保留，返回类型签名或集合继承体系。在这种情况下，限定符值可以用来在相同类型的集合中选择，正如在前一段中概括的那样。
+> 
+> 自Spring 4.3起，`@Autowired`也考虑自引用注入，例如，引用返回当前注入的bean。注意自注入是备用；普通对其它组件的依赖关系总是优先的。在这个意义上，自引用不参与普通的候选目标选择，因此尤其是从不是主要的；恰恰相反，它们最终总是最低的优先级。在实践中，自引用只是作为最后的手段，例如，通过bean的事务代理调用同一实例的其它方法：在考虑抽出受影响的方法来分隔代理bean的场景中。或者，使用`@Resource`通过它的唯一名字可能得到一个返回当前bean的代理。
+> 
+> `@Autowired`可以应用到字段，构造函数和多参数方法上，允许通过限定符注解在参数层面上缩减候选目标。相比之下，`@Resource`仅支持字段和bean属性的带有单个参数的setter方法。因此，如果你的注入目标是一个构造函数或一个多参数的方法，坚持使用限定符。
+
+你可以创建自己的定制限定符注解。简单定义一个注解，在你自己的定义中提供`@Qualifier`注解：
+
+```
+@Target({ElementType.FIELD, ElementType.PARAMETER})
+@Retention(RetentionPolicy.RUNTIME)
+@Qualifier
+public @interface Genre {
+
+    String value();
+}
+```
+
+然后你可以在自动装配的字段和参数上提供定制的限定符：
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    @Genre("Action")
+    private MovieCatalog actionCatalog;
+    private MovieCatalog comedyCatalog;
+
+    @Autowired
+    public void setComedyCatalog(@Genre("Comedy") MovieCatalog comedyCatalog) {
+        this.comedyCatalog = comedyCatalog;
+    }
+
+    // ...
+
+}
+```
+
+接下来，提供候选bean定义的信息。你可以添加`<qualifier/>`标记作为`<bean/>`标记的子元素，然后指定匹配你的定制限定符注解的类型和值。类型用来匹配注解的全限定类名称。或者，如果没有名称冲突的风险，为了方便，你可以使用简写的类名称。下面的例子证实了这些方法。
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xmlns:context="http://www.springframework.org/schema/context"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans
+        http://www.springframework.org/schema/beans/spring-beans.xsd
+        http://www.springframework.org/schema/context
+        http://www.springframework.org/schema/context/spring-context.xsd">
+
+    <context:annotation-config/>
+
+    <bean class="example.SimpleMovieCatalog">
+        <qualifier type="Genre" value="Action"/>
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean class="example.SimpleMovieCatalog">
+        <qualifier type="example.Genre" value="Comedy"/>
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean id="movieRecommender" class="example.MovieRecommender"/>
+
+</beans>
+```
+
+在3.10小节，“类路径扫描和管理组件”中，你将看到一个基于注解的替代方法，在XML中提供限定符元数据。特别地，看3.10.8小节，“用注解提供限定符元数据”。
+
+在某些情况下，使用没有值的注解就是足够的。当注解为了通用的目的时，这是非常有用的，可以应用到跨几个不同类型的依赖上。例如，当网络不可用时，你可以提供一个要搜索的离线目录。首先定义一个简单的注解：
+
+```
+@Target({ElementType.FIELD, ElementType.PARAMETER})
+@Retention(RetentionPolicy.RUNTIME)
+@Qualifier
+public @interface Offline {
+
+}
+```
+
+然后将注解添加到要自动装配的字段或属性上：
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    @Offline
+    private MovieCatalog offlineCatalog;
+
+    // ...
+
+}
+```
+
+现在bean定义只需要一个限定符类型：
+
+```
+<bean class="example.SimpleMovieCatalog">
+    <qualifier type="Offline"/>
+    <!-- inject any dependencies required by this bean -->
+</bean>
+```
+
+你也可以定义接收命名属性之外的定制限定符注解或代替简单的值属性。如果要注入的字段或参数指定了多个属性值，bean定义必须匹配所有的属性值才会被认为是一个可自动装配的候选目标。作为一个例子，考虑下面的注解定义：
+
+```
+@Target({ElementType.FIELD, ElementType.PARAMETER})
+@Retention(RetentionPolicy.RUNTIME)
+@Qualifier
+public @interface MovieQualifier {
+
+    String genre();
+
+    Format format();
+
+}
+```
+
+这种情况下`Format`是枚举类型：
+
+```
+public enum Format {
+    VHS, DVD, BLURAY
+}
+```
+
+要自动装配的字段使用定制限定符进行注解，并且包含了两个属性值：`genre`和`format`。
+
+```
+public class MovieRecommender {
+
+    @Autowired
+    @MovieQualifier(format=Format.VHS, genre="Action")
+    private MovieCatalog actionVhsCatalog;
+
+    @Autowired
+    @MovieQualifier(format=Format.VHS, genre="Comedy")
+    private MovieCatalog comedyVhsCatalog;
+
+    @Autowired
+    @MovieQualifier(format=Format.DVD, genre="Action")
+    private MovieCatalog actionDvdCatalog;
+
+    @Autowired
+    @MovieQualifier(format=Format.BLURAY, genre="Comedy")
+    private MovieCatalog comedyBluRayCatalog;
+
+    // ...
+
+}
+```
+
+最后，bean定义应该包含匹配的限定符值。这个例子也证实了bean元属性可以用来代替`<qualifier/>`子元素。如果可获得`<qualifier/>`，它和它的属性优先级更高，如果当前没有限定符，自动装配机制会将`<meta/>`内的值作为备用，正如下面的例子中的最后两个bean定义。
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xmlns:context="http://www.springframework.org/schema/context"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans
+        http://www.springframework.org/schema/beans/spring-beans.xsd
+        http://www.springframework.org/schema/context
+        http://www.springframework.org/schema/context/spring-context.xsd">
+
+    <context:annotation-config/>
+
+    <bean class="example.SimpleMovieCatalog">
+        <qualifier type="MovieQualifier">
+            <attribute key="format" value="VHS"/>
+            <attribute key="genre" value="Action"/>
+        </qualifier>
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean class="example.SimpleMovieCatalog">
+        <qualifier type="MovieQualifier">
+            <attribute key="format" value="VHS"/>
+            <attribute key="genre" value="Comedy"/>
+        </qualifier>
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean class="example.SimpleMovieCatalog">
+        <meta key="format" value="DVD"/>
+        <meta key="genre" value="Action"/>
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+    <bean class="example.SimpleMovieCatalog">
+        <meta key="format" value="BLURAY"/>
+        <meta key="genre" value="Comedy"/>
+        <!-- inject any dependencies required by this bean -->
+    </bean>
+
+</beans>
+```
+
+#### 3.9.5 使用泛型作为自动装配限定符
+
+除了`@Qualifier`注解外，也可以使用Java的泛型类型作为限定符的一种暗示方式。例如，假设你有如下配置：
+
+```
+@Configuration
+public class MyConfiguration {
+
+    @Bean
+    public StringStore stringStore() {
+        return new StringStore();
+    }
+
+    @Bean
+    public IntegerStore integerStore() {
+        return new IntegerStore();
+    }
+
+}
+```
+
+假设上面的beans实现了一个泛型接口，例如，`Store<String>`和`Store<Integer>`，你可以`@Autowire` `Store`接口，泛型将作为限定符使用：
+
+```
+@Autowired
+private Store<String> s1; // <String> qualifier, injects the stringStore bean
+
+@Autowired
+private Store<Integer> s2; // <Integer> qualifier, injects the integerStore bean
+```
+
+当自动装配`Lists`，`Maps`和`Arrays`时，也会应用泛型限定符：
+
+```
+// Inject all Store beans as long as they have an <Integer> generic
+// Store<String> beans will not appear in this list
+@Autowired
+private List<Store<Integer>> s;
+```
+
+#### 3.9.6 CustomAutowireConfigurer
+
+`CustomAutowireConfigurer`是一个能使你注册自己的定制限定符注解类型的`BeanFactoryPostProcessor`，即使它们不使用Spring的`@Qualifier`注解进行注解。
+
+```
+<bean id="customAutowireConfigurer"
+        class="org.springframework.beans.factory.annotation.CustomAutowireConfigurer">
+    <property name="customQualifierTypes">
+        <set>
+            <value>example.CustomQualifier</value>
+        </set>
+    </property>
+</bean>
+```
+
+`AutowireCandidateResolver`通过下面的方式决定自动装配的候选目标：
+
+*   每个bean定义的`autowire-candidate`
+
+*   在`<beans/>`元素可获得的任何`default-autowire-candidates`模式
+
+*   存在`@Qualifier`注解和任何在`CustomAutowireConfigurer`中注册的定制注解
+
+当多个beans符合条件成为自动装配的候选目标时，”primary” bean的决定如下：如果在候选目标中某个确定的bean中的`primary`特性被设为`true`，它将被选为目标bean。
+
+#### 3.9.7 @Resource
+
+Spring也支持使用JSR-250 `@Resource`对字段或bean属性setter方法进行注入。这是在Java EE 5和6中的一种通用模式，例如在JSF 1.2管理的beans或JAX-WS 2.0的端点。Spring对它管理的对象也支持这种模式。
+
+`@Resource`采用名字属性，默认情况下Spring将名字值作为要注入的bean的名字。换句话说，它遵循*by-name*语义，下面的例子证实了这一点：
+
+```
+public class SimpleMovieLister {
+
+    private MovieFinder movieFinder;
+
+    @Resource(name="myMovieFinder")
+    public void setMovieFinder(MovieFinder movieFinder) {
+        this.movieFinder = movieFinder;
+    }
+
+}
+```
+
+如果没有显式的指定名字，默认名字从字段名或setter方法中取得。在字段情况下，它采用字段名称；在setter方法情况下，它采用bean的属性名。因此下面的例子将名字为`movieFinder`的bean注入到它的setter方法中：
+
+```
+public class SimpleMovieLister {
+
+    private MovieFinder movieFinder;
+
+    @Resource
+    public void setMovieFinder(MovieFinder movieFinder) {
+        this.movieFinder = movieFinder;
+    }
+
+}
+```
+
+> 注解提供的名字被`CommonAnnotationBeanPostProcessor`感知的`ApplicationContext`解析为bean名字。如果你显式地配置了Spring的`SimpleJndiBeanFactory`，名字会通过JNDI解析。但是建议你依赖默认行为，简单使用Spring的JNDI查找功能保护间接查找级别。
+
+在`@Resource`特有的没有显式名字指定的情况下，类似于`@Autowired`，`@Resource`会进行主要的匹配类型来代替指定名字的bean并解析已知的可解析依赖：`BeanFactory`，`ApplicationContext`，`ResourceLoader`，`ApplicationEventPublisher`和`MessageSource`接口。
+
+因此在下面的例子中，`customerPreferenceDao`字段首先查找名字为`customerPreferenceDao`的bean，然后回退到主要的类型为`CustomerPreferenceDao`的类型匹配。”context”字段会注入基于已知的可解析依赖类型`ApplicationContext`。
+
+```
+public class MovieRecommender {
+
+    @Resource
+    private CustomerPreferenceDao customerPreferenceDao;
+
+    @Resource
+    private ApplicationContext context;
+
+    public MovieRecommender() {
+    }
+
+    // ...
+
+}
+```
+
+#### 3.9.8 @PostConstruct和@PreDestroy
+`CommonAnnotationBeanPostProcessor`不仅识别`@Resource`注解，而且识别JSR-250生命周期注解。在Spring 2.5引入了对这些注解的支持，也提供了在初始化回调函数和销毁回调函数中描述的那些注解的一种可替代方式。假设`CommonAnnotationBeanPostProcessor`在Spring的`ApplicationContext`中注册，执行这些注解的方法在生命周期的同一点被调用，作为对应的Spring生命周期接口方法或显式声明的回调方法。在下面的例子中，缓存会预先放置接近初始化之前，并在销毁之前清除。
+
+```
+public class CachingMovieLister {
+
+    @PostConstruct
+    public void populateMovieCache() {
+        // populates the movie cache upon initialization...
+    }
+
+    @PreDestroy
+    public void clearMovieCache() {
+        // clears the movie cache upon destruction...
+    }
+
+}
+```
diff --git "a/Java/Spring/Spring-Bean\347\232\204\344\275\234\347\224\250\345\237\237\347\256\241\347\220\206.md" "b/Java/Spring/Spring-Bean\347\232\204\344\275\234\347\224\250\345\237\237\347\256\241\347\220\206.md"
new file mode 100644
index 0000000000..ac52a7dfa8
--- /dev/null
+++ "b/Java/Spring/Spring-Bean\347\232\204\344\275\234\347\224\250\345\237\237\347\256\241\347\220\206.md"
@@ -0,0 +1,172 @@
+ Spring框架支持5种作用域，有三种作用域是当开发者使用基于web的`ApplicationContext`的时候才生效的
+
+下面就是Spring内置支持的作用域
+
+| 作用域 | 描述 |
+| --- | --- |
+| 单例(singleton)   | （默认）每一个Spring IoC容器都拥有唯一的一个实例对象 |
+| 原型(prototype) | 一个Bean定义可以创建任意多个实例对象 |
+| 请求（request） | 一个HTTP请求会产生一个Bean对象，也就是说，每一个HTTP请求都有自己的Bean实例。只在基于web的Spring `ApplicationContext`中可用 |
+| 会话（session） | 限定一个Bean的作用域为HTTP`session`的生命周期。同样，只有基于web的Spring `ApplicationContext`才能使用 |
+| 全局会话(global session） | 限定一个Bean的作用域为全局HTTP`Session`的生命周期。通常用于门户网站场景，同样，只有基于web的Spring `ApplicationContext`可用 |
+| 应用(application) | 限定一个Bean的作用域为`ServletContext`的生命周期。同样，只有基于web的Spring `ApplicationContext`可用 |
+
+> 在Spring 3.0中，*线程作用域*是可用的，但不是默认注册的
+
+#1.  singleton
+全局只有一个共享的实例,所有将单例Bean作为依赖的情况下,容器返回将是同一个实例
+
+换言之，当开发者定义一个Bean的作用域为单例时，Spring IoC容器只会根据Bean定义来创建该Bean的唯一实例。这些唯一的实例会缓存到容器中，后续针对单例Bean的请求和引用，都会从这个缓存中拿到这个唯一的实例
+![](http://upload-images.jianshu.io/upload_images/4685968-0c56982970cc16e6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 1.1 单例Bean和单例模式
+- 单例模式是将一个对象的作用域硬编码，一个ClassLoader只有唯一的一个实例 
+- 而Spring的单例作用域，是`基于每个容器`，每个Bean只有一个实例
+这意味着，如果开发者根据一个类定义了一个Bean在单个的Spring容器中，那么Spring容器会根据Bean定义创建一个唯一的Bean实例。默认情况下，它们为每个给定的org.springframework.context.ApplicationContext实例存在唯一的一个bean (有点别扭，也就是可以有多个Spring容器，每一个容器内存在唯一bean实例).这意味着如果你有两个或更多上下文，所有这些上下文都由同一Java的类加载器管理(因为在同一个jvm环境中)，则可能会有多个给定bean的实例。唯一需要做到的是必须在每个上下文中定义此bean.
+
+所以你可以看到，bean只是`一个上下文的单例`
+你不应该将Spring的单例概念与设计模式中的的单例混淆
+
+ *单例作用域是Spring的默认作用域*，下面的例子是在基于XML的配置中配置单例模式的Bean。
+
+```
+<bean id="accountService" class="com.sss.DefaultAccountService"/>
+
+<!-- the following is equivalent, though redundant (singleton scope is the default) -->
+<bean id="accountService" class="com.sss.DefaultAccountService" scope="singleton"/>
+
+```
+#2. prototype
+每次请求Bean实例时，返回的都是新实例的Bean对象
+也就是说，每次注入到另外的Bean或者通过调用`getBean()`来获得的Bean都将是全新的实例。 
+这是基于线程安全性的考虑，如果使用有状态的Bean对象用prototype 作用域，而无状态的Bean对象用singleton 作用域。
+
+下面的例子说明了Spring的原型作用域。DAO通常不会配置为原型对象，因为典型的DAO是不会有任何的状态的。
+![](http://upload-images.jianshu.io/upload_images/4685968-0a35694b27f5a359.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+下面的例子展示了XML中如何定义一个原型的Bean：
+```
+<bean id="accountService" class="com.sss.DefaultAccountService" scope="prototype"/>
+```
+与其他的作用域相比，Spring不会完全管理原型Bean的生命周期：
+Spring容器只会初始化配置以及装载这些Bean，传递给Client。
+但是之后就不会再去管原型Bean之后的动作了。
+ 
+也就是说，初始化生命周期回调方法在所有作用域的Bean是都会调用的，但是销毁生命周期回调方法在原型Bean是不会调用的
+
+所以，客户端代码必须注意清理原型Bean以及释放原型Bean所持有的一些资源。
+ 可以通过使用自定义的`bean post-processor`来让Spring释放掉原型Bean所持有的资源。
+
+在某些方面来说，Spring容器的角色就是取代了Java的`new`操作符，所有的生命周期的控制需要由客户端来处理。
+## 2-1 Singleton beans with prototype-bean dependencies
+###在原型bean中放置单例
+如果注入的单例对象真的是一个单例的bean(没有状态)，这个真的没一点问题
+想象一下，对于我们的购物车，我们需要注入产品服务。此服务只会检查添加到购物车的产品是否库存。由于服务没有状态，并且会基于在方法签名中所传递的对象进行验证，因此不存在风险
+
+当使用单例Bean的时候，而该单例Bean的依赖是原型Bean时，需要注意的是**依赖的解析都是在初始化的阶段**
+因此，如果将原型Bean注入到单例的Bean之中，只会请求一次原型Bean，然后注入到单例Bean中。这个依赖的原型Bean仍然属于只有一个实例的。
+
+然而，假设你需要单例Bean对原型的Bean的依赖
+需要每次在运行时都请求一个新的实例，那么你就不能够将一个原型的Bean来注入到一个单例的Bean当中了，因为依赖注入只会进行*一次* 
+当Spring容器在实例化单例Bean的时候，就会解析以及注入它所需的依赖
+如果实在需要每次都请求一个新的实例，可以通过bean工厂手动获取实例,也可以参考[Dependencies](http://blog.didispace.com/books/spring-framework-4-reference/III.%20Core%20Technologies/Dependencies.html)中的**方法注入**部分。
+##使用单例还是原型？
+- Singleton适用于无状态的bean,比如一个service，DAO或者controller
+他们都没有自己的状态(举个简单的例子，一个函数sin(x)，这个函数本身就是无状态的，所以我们现在喜欢的函数式编程也遵循这个理念)。而是根据传输的参数执行一些操作(作为HTTP请求参数)。
+- 另一方面，我们可以通过状态bean管理一些状态。比如购物车bean，假如它是一个单例，那么两个不同消费者购买的产品将被放置在同一个对象上。而如果其中一个消费者想要删除一个产品，另一个消费者就铁定不高兴。这也就是状态类对象应该是原型
+#3.  Request
+Spring容器会在每次用到`loginAction`来处理每个HTTP请求的时候都会创建一个新的`LoginAction`实例。也就是说，`loginAction`Bean的作用域是HTTP`Request`级别的。 开发者可以随意改变实例的状态，因为其他通过`loginAction`请求来创建的实例根本看不到开发者改变的实例状态，所有创建的Bean实例都是根据独立的请求来的。当请求处理完毕，这个Bean也会销毁。
+![](http://upload-images.jianshu.io/upload_images/4685968-49d6648d6c3d9556.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+每个请求初始化具有此作用域的Bean注解。这听起来像是原型作用域的描述，但它们有一些差异。
+- 原型作用域在Spring的上下文中可用。而请求作用域仅适用于Web应用程序
+- 原型bean根据需求进行初始化，而请求bean是在每个请求下构建的
+
+需要说的是，request作用域bean在其作用域内有且仅有一个实例。而你可以拥有一个或多个原型作用域bean实例
+
+在以下代码中，你可以看到请求作用域bean的示例：
+```java
+<bean id="shoppingCartRequest" class="com.sss.scope.ShoppingCartRequest" scope="request">
+    <aop:scoped-proxy/> 
+</bean>
+```
+当使用注解驱动组件或Java Config时，@RequestScope注解可以用于将一个组件分配给request作用域。
+```java
+@RequestScope
+@Component
+public class ShoppingCartRequest {
+	// ...
+}
+// request bean
+ 
+// injection sample
+@Controller
+public class TestController {
+    @Autowired
+    private ShoppingCartRequest shoppingCartRequest;
+     
+    @RequestMapping(value = "/test", method = RequestMethod.GET)
+    public String test(HttpServletRequest request) {
+        LOGGER.debug("shoppingCartRequest is :"+shoppingCartRequest);
+        // ...
+    }
+}
+```
+请注意<bean>定义内存在的<aop: scoped-proxy />标签。这代表着使用代理对象。所以实际上，TestController持有的是代理对象的引用。我们所有的调用该对象都会转发到真正的ShoppingCartRequest对象。
+
+有时我们需要使用DispatcherServlet的另一个servlet来处理请求。在这种情况下，我们必须确保Spring中所有请求都可用(否则可以抛出与下面类似的异常)。为此，我们需要在web.xml中定义一个监听器:
+```java
+<listener>   
+  <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
+</listener>
+```
+
+调用/测试URL后，你应该能在日志中的发现以下信息:
+```java
+shoppingCartRequest is :com.migo.scope.ShoppingCartRequest@2586b11c
+shoppingCartRequest is :com.migo.scope.ShoppingCartRequest@3bd5b945
+```
+如果我们尝试在单例bean中使用request作用域的bean，则会在应用程序上下文加载阶段抛出一个BeanCreationException
+ #4. session
+参考如下的Bean定义：
+
+```
+<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
+
+```
+
+Spring容器会在每次调用到`userPreferences`在一个单独的HTTP会话周期来创建一个新的`UserPreferences`实例。换言之，`userPreferences`Bean的作用域是HTTP`Session`级别的。 在`request-scoped`作用域的Bean上，开发者可以随意的更改实例的状态，同样，其他的HTTP`Session`基本的实例在每个Session都会请求`userPreferences`来创建新的实例，所以开发者更改Bean的状态，对于其他的Bean仍然是不可见的。当HTTP`Session`销毁了，那么根据这个`Session`来创建的Bean也就销毁了。
+
+![](http://upload-images.jianshu.io/upload_images/4685968-e219a491ac3e8710.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+Session作用域的bean与request 作用域的bean没有太大不同。它们也与纯Web应用程序上下文相关联。注解为Session作用域的Bean对于每个用户的会话仅创建一次。他们在会话结束时被破坏销毁掉。
+
+由Session作用域限制的Bean可以被认为是面向Web的单例，因为给定环境(用户会话)仅存在一个实例。但请记住，你无法在Web应用程序上下文中使用它们(说个好理解点的，就是一个函数内部自定义变量所在的作用域，函数执行完就销毁了，没有什么逃逸)。
+
+想知道Session作用域bean在Spring中的操作，我们需要在配置文件中定义一个bean:
+```java
+<bean id="shoppingCartRequest" class="com.migo.scope.ShoppingCartSession" scope="session">
+
+    <aop:scoped-proxy/> 
+
+</bean>
+```
+通过`@Autowired`注解，查找这个bean的方式与request 作用域的bean相同。可以看到以下结果:
+你可以看到，前5个打印输出代表相同的对象。最后一个是不同的。这是什么意思 ?简单来说，这代表 着一个新的用户使用自动注入的Session作用域访问该页面。我们可以通过打开两个浏览器的测试页(/test)来观察它。每个都将初始化一个新的会话Session，因此也就创建新的`ShoppingCartSession bean`实例。
+#5. global session
+> 该部分主要是描述`portlet`的，详情可以Google更多关于`portlet`的相关信息。
+
+参考如下的Bean定义：
+
+```
+<bean id="userPreferences" class="com.foo.UserPreferences" scope="globalSession"/>
+
+```
+
+`global session`作用域比较类似之前提到的标准的HTTP`Session`，这种作用域是只应用于基于门户（portlet-based）的web应用的上下之中的。门户的Spec中定义的`global session`的意义：`global session`被所有构成门户的web应用所共享。定义为`global session`作用域的Bean是作用在全局门户`Session`的声明周期的。
+
+如果在使用标准的基于Servlet的Web应用，而且定义了`global session`作用域的Bean，那么只是会使用标准的HTTP`Session`作用域，不会报错。
+![](http://upload-images.jianshu.io/upload_images/4685968-100da62584121eeb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+关于全局会话作用域(Global session scope)属于4.3x的范畴了，Spring5已经没有了，Spring5文档是去掉了因为4的存在所以还是说两句，它保留给portlet应用程序。 是不是一脸懵逼，so，来解释一下portlet是什么。Portlet是能够生成语义代码(例如：HTML)片段的小型Java Web插件。它们基于portlet容器，可以像servlet一样处理HTTP请求。但是，与servlet不同，每个portlet都有不同的会话。在这种情况下，Spring提供了一个名为`global-session`的作用域。通过它，一个bean可以通过应用程序中的多个portlet共享。
+
+至此，我们解释了请求和面向会话的作用域。第一个的作用是在每个request请求上创建新的bean。第二个在Session会话开始的时候初始化bean。
+
diff --git "a/Java/Spring/Spring-Bean\347\232\204\347\224\237\345\221\275\345\221\250\346\234\237.md" "b/Java/Spring/Spring-Bean\347\232\204\347\224\237\345\221\275\345\221\250\346\234\237.md"
new file mode 100644
index 0000000000..9ddb180e00
--- /dev/null
+++ "b/Java/Spring/Spring-Bean\347\232\204\347\224\237\345\221\275\345\221\250\346\234\237.md"
@@ -0,0 +1,24 @@
+#Spring简介
+- 轻量级的容器，提供集中式，自动配置与装配应用业务对象功能
+- 提供了统一的事务管理抽象，基于插件式的事务管理(声明性事务管理)能够很容易的实现事务层管理,而无需了解各种底层事务实现
+- 提供了统一的数据访问抽象，包括简单和有效率的JDBC框架，极大的改进了效率(大大减少了开发的代码量)并且减少了可能的错误
+- Spring的数据访问层集成了Toplink,Hibernate,JDO,and iBATIS SQL Maps等O/R mapping解决方案，其目的是提供统一的DAO支持类实现和事务管理策略
+- Spring提供了一个用标准Java编写的AOP框架(也能集成AspectJ)，提供基于POJOs的声明式的事务管理和其他企业事务
+- 提供可以与IoC容器集成的强大而灵活的MVCWeb框架 
+![](http://upload-images.jianshu.io/upload_images/4685968-4afc0eb0315a40aa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+#bean对象生命周期管理
+![生命周期](http://upload-images.jianshu.io/upload_images/4685968-dba902b1479a7e82.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+1.Spring对Bean进行实例化（相当于程序中的new Class())
+2.Spring将值和Bean的引用注入进Bean对应的属性中
+3.如果Bean实现了BeanNameAware接口，Spring将Bean的ID传递给setBeanName()方法（实现BeanNameAware主要是为了通过Bean的引用来获得Bean的ID，一般业务中是很少有用到Bean的ID的）
+4.如果Bean实现了BeanFactoryAware接口，Spring将调用setBeanDactory(BeanFactory bf)方法并把BeanFactory容器实例作为参数传入（实现BeanFactoryAware 主要目的是为了获取Spring容器，如Bean通过Spring容器发布事件等）
+5.如果Bean实现了ApplicationContextAwaer接口，Spring容器将调用setApplicationContext(ApplicationContext ctx)方法，把应用上下文作为参数传入(作用与BeanFactory类似都是为了获取Spring容器，不同的是Spring容器在调用setApplicationContext方法时会把它自己作为setApplicationContext 的参数传入，而Spring容器在调用setBeanDactory前需要程序员自己指定（注入）setBeanDactory里的参数BeanFactory )
+6.如果Bean实现了BeanPostProcess接口，Spring将调用它们的postProcessBeforeInitialization（预初始化）方法（作用是在Bean实例创建成功后对进行增强处理，如对Bean进行修改，增加某个功能）
+7.如果Bean实现了InitializingBean接口，Spring将调用它们的afterPropertiesSet方法，作用与在配置文件中对Bean使用init-method声明初始化的作用一样，都是在Bean的全部属性设置成功后执行的初始化方法。
+8.如果Bean实现了BeanPostProcess接口，Spring将调用它们的postProcessAfterInitialization（后初始化）方法（作用与6的一样，只不过6是在Bean初始化前执行的，而这个是在Bean初始化后执行的，时机不同 )
+9.经过以上的工作后，Bean将一直驻留在应用上下文中给应用使用，直到应用上下文被销毁
+10.如果Bean实现了DispostbleBean接口，Spring将调用它的destory方法，作用与在配置文件中对Bean使用destory-method属性的作用一样，都是在Bean实例销毁前执行的方法
+
+
+
diff --git "a/Java/Spring/Spring-\344\272\213\345\212\241\347\256\241\347\220\206.md" "b/Java/Spring/Spring-\344\272\213\345\212\241\347\256\241\347\220\206.md"
new file mode 100644
index 0000000000..f24f8e4bd6
--- /dev/null
+++ "b/Java/Spring/Spring-\344\272\213\345\212\241\347\256\241\347\220\206.md"
@@ -0,0 +1,42 @@
+# 1 目标
+![](https://upload-images.jianshu.io/upload_images/4685968-eed053d251275855.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 2事务回顾
+## 什么是事务
+![](https://upload-images.jianshu.io/upload_images/4685968-83d81f1c7b75ae07.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 具体案例
+![](https://upload-images.jianshu.io/upload_images/4685968-1028f8592a327682.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![钱转了,李四却没收到!!!](https://upload-images.jianshu.io/upload_images/4685968-ce870c99003f98c5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![需要事务!!!](https://upload-images.jianshu.io/upload_images/4685968-a102d0e9734d4216.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 事务的特性
+![](https://upload-images.jianshu.io/upload_images/4685968-3a6300f87c2a1953.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![原子性](https://upload-images.jianshu.io/upload_images/4685968-6cc65f05555dd413.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![一致性](https://upload-images.jianshu.io/upload_images/4685968-f76d2f7cab3ca00c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-889156dab97b9c97.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-226a7bf9ea65ab08.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ec18c46d3c08b495.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 3 事务的API
+## Spring 接口介绍
+![](https://upload-images.jianshu.io/upload_images/4685968-96ed77d556799458.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-01dd1056fff16546.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2172687122971173.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5c61cb9956587e6e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## PlatformTransactionManager
+![](https://upload-images.jianshu.io/upload_images/4685968-e13c0def9040a4c9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## TransactionDefinition
+![](https://upload-images.jianshu.io/upload_images/4685968-d7ca52c82a556b36.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 脏读
+![](https://upload-images.jianshu.io/upload_images/4685968-d722077c8547ab50.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 不可重复读
+![](https://upload-images.jianshu.io/upload_images/4685968-c78a6f53c4ec2014.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 幻读
+![](https://upload-images.jianshu.io/upload_images/4685968-c3a2b2720333ad2b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+### 事务隔离级别
+![](https://upload-images.jianshu.io/upload_images/4685968-d7e2033751124d7b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-133d4393a443117a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-738039998b94ad7f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## TransactionDefinition事务传播行为
+![](https://upload-images.jianshu.io/upload_images/4685968-937d0ca6d13ec7d9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## TransactionStatus
+
+# 4 环境搭建
+![](https://upload-images.jianshu.io/upload_images/4685968-d705cb27a349cc84.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring/Spring-\345\256\236\346\210\230---IoC\345\256\271\345\231\250\347\232\204\344\276\235\350\265\226\346\263\250\345\205\245.md" "b/Java/Spring/Spring-\345\256\236\346\210\230---IoC\345\256\271\345\231\250\347\232\204\344\276\235\350\265\226\346\263\250\345\205\245.md"
new file mode 100644
index 0000000000..2a196ea8f0
--- /dev/null
+++ "b/Java/Spring/Spring-\345\256\236\346\210\230---IoC\345\256\271\345\231\250\347\232\204\344\276\235\350\265\226\346\263\250\345\205\245.md"
@@ -0,0 +1,593 @@
+初始化的过程,主要完成的工作是在容器中建立 BeanDefinition 数据映射,并没有看到容器对Bean依赖关系进行注入
+
+假设当前IoC容器已经载入用户定义的Bean信息,依赖注入主要发生在两个阶段
+- 正常情况下,由用户第一次向 IoC 容器索要 bean 时触发
+- 可在 `BeanDefinition` 信息中通过控制 `lazy-init` 属性
+![](https://upload-images.jianshu.io/upload_images/4685968-61440d86719257a3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+来让容器完成对Bean的预实例化;
+即在初始化的过程中就完成某些Bean的依赖注入的过程.
+
+# 1 getBean触发的依赖注入
+`BeanFactory` 是最原始的 ioc 容器，有以下方法 
+1.getBean
+2.判断是否有 Bean，containsBean
+3.判断是否单例 isSingleton
+
+BeanFactory 只对 ioc 容器最基本的行为作了定义,不关心 Bean 是怎样定义和加载的;
+如果我们想要知道一个工厂具体产生对象的过程,则要看这个接口的实现类.
+
+在基本的容器接口 `BeanFactory` 中;
+有一个 `getBean `接口,这个接口的实现就是触发依赖注入发生的地方.
+为进一步了解该依赖注入的过程,我们从 `DefaultListableBeanFactory `的基类` AbstractBeanFactory `入手去看看`getBean`的实现
+
+>这里是对 BeanFactory 接口的实现,比如getBean接口
+
+```
+	public <T> T getBean(String name, Class<T> requiredType, Object... args) throws BeansException {
+        // 这些 getBean 接口最终都是通过调用 doGetBean 实现
+		return doGetBean(name, requiredType, args, false);
+	}
+```
+![](https://upload-images.jianshu.io/upload_images/4685968-9fee95ac391dc178.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+```
+
+    // 实际取得 Bean 的地方,即触发依赖注入
+	@SuppressWarnings("unchecked")
+	protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
+			throws BeansException {
+
+		final String beanName = transformedBeanName(name);
+		Object bean;
+
+        //急切检查单例模式缓存手动注册的单例
+        //先从缓存中取得Bean,处理那些已经被创建过的单例Bean,这种Bean不要重复创建
+		Object sharedInstance = getSingleton(beanName);
+```
+
+顺道看看getSingleton()的实现
+![DefaultSingletonBeanRegistry # getSingleton(String beanName)](https://upload-images.jianshu.io/upload_images/4685968-2374a16031b2878b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![方法描述](https://upload-images.jianshu.io/upload_images/4685968-f34d70f4d10bb010.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+protected Object getSingleton(String beanName, boolean allowEarlyReference) {
+		Object singletonObject = this.singletonObjects.get(beanName);
+		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
+			synchronized (this.singletonObjects) {
+				singletonObject = this.earlySingletonObjects.get(beanName);
+				if (singletonObject == null && allowEarlyReference) {
+					ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
+					if (singletonFactory != null) {
+						singletonObject = singletonFactory.getObject();
+						this.earlySingletonObjects.put(beanName, singletonObject);
+						this.singletonFactories.remove(beanName);
+					}
+				}
+			}
+		}
+		return (singletonObject != NULL_OBJECT ? singletonObject : null);
+	}
+```
+回过头继续看工厂实现
+```
+		if (sharedInstance != null && args == null) {
+		    
+            ...
+
+            //以取得 FactoryBean 的相关处理及生产结果
+			bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
+		}
+```
+来看看该 getObjectForBeanInstance 方法的实现,和FactoryBean有何关系呢
+![AbstractBeanFactory # getObjectForBeanInstance(Object beanInstance, String name,String beanName, RootBeanDefinition mbd)](https://upload-images.jianshu.io/upload_images/4685968-941dffd0a41e6ab8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+	protected Object getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd) {
+
+		// Don't let calling code try to dereference the factory if the bean isn't a factory.
+		if (BeanFactoryUtils.isFactoryDereference(name) && !(beanInstance instanceof FactoryBean)) {
+			throw new BeanIsNotAFactoryException(transformedBeanName(name), beanInstance.getClass());
+		}
+
+		// Now we have the bean instance, which may be a normal bean or a FactoryBean.
+		// If it's a FactoryBean, we use it to create a bean instance, unless the
+		// caller actually wants a reference to the factory.
+		if (!(beanInstance instanceof FactoryBean) || BeanFactoryUtils.isFactoryDereference(name)) {
+			return beanInstance;
+		}
+
+		Object object = null;
+		if (mbd == null) {
+			object = getCachedObjectForFactoryBean(beanName);
+		}
+		if (object == null) {
+			// Return bean instance from factory.
+			FactoryBean<?> factory = (FactoryBean<?>) beanInstance;
+			// Caches object obtained from FactoryBean if it is a singleton.
+			if (mbd == null && containsBeanDefinition(beanName)) {
+				mbd = getMergedLocalBeanDefinition(beanName);
+			}
+			boolean synthetic = (mbd != null && mbd.isSynthetic());
+			object = getObjectFromFactoryBean(factory, beanName, !synthetic);
+		}
+		return object;
+	}
+```
+继续回过头
+```
+
+		else {
+			// 若早已创建该 bean 实例则会失败进入到此
+			// 假设处在引用循环依赖中
+			if (isPrototypeCurrentlyInCreation(beanName)) {
+				throw new BeanCurrentlyInCreationException(beanName);
+			}
+
+            // 检查 bean 定义是否存在于该工厂
+			BeanFactory parentBeanFactory = getParentBeanFactory();
+			if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
+				// 没有找到,即不存在 -> 检查父类
+				String nameToLookup = originalBeanName(name);
+				if (args != null) {
+					// 有更精确的参数 -> 委托给父类
+					return (T) parentBeanFactory.getBean(nameToLookup, args);
+				}
+				else {
+					// 无参数 -> 委托给标准的 getBean 方法
+					return parentBeanFactory.getBean(nameToLookup, requiredType);
+				}
+			}
+
+			if (!typeCheckOnly) {
+				markBeanAsCreated(beanName);
+			}
+
+			try {
+                //根据 Bean 名取得 BeanDefinition  
+				final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
+				checkMergedBeanDefinition(mbd, beanName, args);
+
+				
+                //递归获得当前 Bean 依赖的所有Bean,确保它们的初始化
+				String[] dependsOn = mbd.getDependsOn();
+				if (dependsOn != null) {
+					for (String dep : dependsOn) {
+						if (isDependent(beanName, dep)) {
+							throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+									"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
+						}
+						registerDependentBean(dep, beanName);
+						getBean(dep);
+					}
+				}
+  
+                // 创建 singleton bean 的地方
+				if (mbd.isSingleton()) {
+					sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
+						@Override
+						public Object getObject() throws BeansException {
+							try {
+                                // 调用 createBean 创建单例 bean实例
+								return createBean(beanName, mbd, args);
+							}
+							catch (BeansException ex) {
+								// Explicitly remove instance from singleton cache: It might have been put there
+								// eagerly by the creation process, to allow for circular reference resolution.
+								// Also remove any beans that received a temporary reference to the bean.
+								destroySingleton(beanName);
+								throw ex;
+							}
+						}
+					});
+					bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
+				}
+
+                // 创建 prototype bean 的地方
+				else if (mbd.isPrototype()) {
+					// It's a prototype -> create a ne w instance.
+					Object prototypeInstance = null;
+					try {
+						beforePrototypeCreation(beanName);
+						prototypeInstance = createBean(beanName, mbd, args);
+					}
+					finally {
+						afterPrototypeCreation(beanName);
+					}
+					bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
+				}
+
+				else {
+					String scopeName = mbd.getScope();
+					final Scope scope = this.scopes.get(scopeName);
+					if (scope == null) {
+						throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
+					}
+					try {
+						Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {
+							@Override
+							public Object getObject() throws BeansException {
+								beforePrototypeCreation(beanName);
+								try {
+									return createBean(beanName, mbd, args);
+								}
+								finally {
+									afterPrototypeCreation(beanName);
+								}
+							}
+						});
+						bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
+					}
+					catch (IllegalStateException ex) {
+						throw new BeanCreationException(beanName,
+								"Scope '" + scopeName + "' is not active for the current thread; consider " +
+								"defining a scoped proxy for this bean if you intend to refer to it from a singleton",
+								ex);
+					}
+				}
+			}
+			catch (BeansException ex) {
+				cleanupAfterBeanCreationFailure(beanName);
+				throw ex;
+			}
+		}
+
+		// Check if required type matches the type of the actual bean instance.
+        // 这里对创建的Bean进行类型检查,如果没有问题,就返回这个新创建的Bean,这个Bean已经是包含了依赖关系的Bean
+		if (requiredType != null && bean != null && !requiredType.isAssignableFrom(bean.getClass())) {
+			try {
+				return getTypeConverter().convertIfNecessary(bean, requiredType);
+			}
+			catch (TypeMismatchException ex) {
+				if (logger.isDebugEnabled()) {
+					logger.debug("Failed to convert bean '" + name + "' to required type '" +
+							ClassUtils.getQualifiedName(requiredType) + "'", ex);
+				}
+				throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+			}
+		}
+		return (T) bean;
+	}
+```
+
+依赖注入的发生是在容器中的 `BeanDefinition` 数据已经建立好的前提下进行的.
+
+
+# 2 依赖注入过程
+![依赖注入的过程](http://upload-images.jianshu.io/upload_images/4685968-474abfacb196d345.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)  
+getBean() 是依赖注入的起点;
+之后会调用`AbstractAutowireCapableBeanFactory`中的`createBean`来生产需要的Bean;
+还对Bean初始化进行了处理,比如实现了在BeanDefinition中的init-method属性定义,Bean后置处理器等.
+
+来看看createBean
+```
+	@Override 
+	protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {
+	    ...
+		RootBeanDefinition mbdToUse = mbd;
+
+		// Make sure bean class is actually resolved at this point, and
+		// clone the bean definition in case of a dynamically resolved Class
+		// which cannot be stored in the shared merged bean definition.
+        // 判断需要创建的 Bean 是否可被实例化,该类是否可通过类加载器来载入
+		Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
+		if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
+			mbdToUse = new RootBeanDefinition(mbd);
+			mbdToUse.setBeanClass(resolvedClass);
+		}
+
+		// Prepare method overrides.
+		try {
+			mbdToUse.prepareMethodOverrides();
+		}
+	    ...
+		try {			
+            //给 BeanPostProcessor一个机会返回的是一个Proxy代理而不是目标 bean 的实例
+			Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
+			if (bean != null) {
+				return bean;
+			}
+		}
+		...
+		try {
+			Object beanInstance = doCreateBean(beanName, mbdToUse, args);
+			...
+			return beanInstance;
+		}
+		...
+	}
+```
+### doCreateBean 源码解析
+接着到 doCreateBean 中去看看Bean是怎样生成的
+```
+    protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
+		// Instantiate the bean.
+        //用来持有创建出来的Bean对象
+		BeanWrapper instanceWrapper = null;
+                //如果是单例,则先把缓存中的同名Bean清除
+		if (mbd.isSingleton()) {
+			instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
+		}
+                //这里是创建Bean的地方,由createBeanInstance来完成
+		if (instanceWrapper == null) {
+                       //根据指定bean使用对应的策略创建新的实例,如:工厂方法,构造函数自动注入,简单初始化
+			instanceWrapper =  createBeanInstance(beanName, mbd, args);
+		}
+		final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
+		Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
+
+		// Allow post-processors to modify the merged bean definition.
+		synchronized (mbd.postProcessingLock) {
+			if (!mbd.postProcessed) {
+				applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
+				mbd.postProcessed = true;
+			}
+		}
+
+		// Eagerly cache singletons to be able to resolve circular references
+		// even when triggered by lifecycle interfaces like BeanFactoryAware.
+                //是否需要提前曝光:单例&允许循环依赖&当前bean正在创建中,检测循环依赖
+		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
+				isSingletonCurrentlyInCreation(beanName));
+		if (earlySingletonExposure) {
+			if (logger.isDebugEnabled()) {
+				logger.debug("Eagerly caching bean '" + beanName +
+						"' to allow for resolving potential circular references");
+			}
+                       //为避免后期循环依赖,可以在bean初始化完成前将创建实例的ObjectFactory加入工厂
+			addSingletonFactory(beanName, new ObjectFactory<Object>() {
+				@Override
+				public Object getObject() throws BeansException {
+                                        //对bean再次依赖引用,主要应用SMartInstantialiationAware BeanPostProcessor,
+                                       //其中我们熟知的AOP就是在这里将advice动态织入bean中,若无则直接返回bean,不做任何处理
+					return getEarlyBeanReference(beanName, mbd, bean);
+				}
+			});
+		}
+
+		// Initialize the bean instance.
+                //这里是对Bean的初始化,依赖注入往往在这里发生,这个exposedObject在初始化处理完后悔返回作为依赖注入完成后的Bean
+		Object exposedObject = bean;
+		try {
+                       //对bean进行填充,将各个属性值注入,其中可能存在依赖于其他bean的属性,则会递归初始化依赖bean
+			populateBean(beanName, mbd, instanceWrapper);
+			if (exposedObject != null) {
+                                //调用初始化方法,比如init-method
+				exposedObject = initializeBean(beanName, exposedObject, mbd);
+			}
+		}
+		catch (Throwable ex) {
+			if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
+				throw (BeanCreationException) ex;
+			}
+			else {
+				throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
+			}
+		}
+
+		if (earlySingletonExposure) {
+			Object earlySingletonReference = getSingleton(beanName, false);
+                        // earlySingletonReference 只有在检测到有循环依赖的情况下才会非空
+			if (earlySingletonReference != null) {
+				if (exposedObject == bean) {
+                                        //如果exposedObject 没有在初始化方法中被改变,也就是没有被增强
+					exposedObject = earlySingletonReference;
+				}
+				else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
+					String[] dependentBeans = getDependentBeans(beanName);
+					Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
+					for (String dependentBean : dependentBeans) {
+                                               //检测依赖
+						if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
+							actualDependentBeans.add(dependentBean);
+						}
+					}
+                                        //因为bean创建后其所依赖的bean一定是已经创建的,actualDependentBeans非空则表示当前bean创建后其依赖的bean却没有全部创建完,也就是说存在循环依赖
+					if (!actualDependentBeans.isEmpty()) {
+						throw new BeanCurrentlyInCreationException(beanName,
+								"Bean with name '" + beanName + "' has been injected into other beans [" +
+								StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
+								"] in its raw version as part of a circular reference, but has eventually been " +
+								"wrapped. This means that said other beans do not use the final version of the " +
+								"bean. This is often the result of over-eager type matching - consider using " +
+								"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
+					}
+				}
+			}
+		}
+	       // Register bean as disposable.
+		try {
+                        //根据scope注册bean
+			registerDisposableBeanIfNecessary(beanName, bean, mbd);
+		}
+		catch (BeanDefinitionValidationException ex) {
+			throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
+		}
+
+		return exposedObject;
+	}
+```
+
+## 小结
+依赖注入其实包括两个主要过程
+- 生产 Bean 所包含的Java对象
+- Bean 对象生成之后,把这些 Bean 对象的依赖关系设置好
+
+我们从上可以看到与依赖注入关系特别密切的方法
+ - `createBeanInstance` 
+生成Bean包含的Java对象
+- `populateBean`.
+处理对各种Bean对象的属性进行处理的过程（即依赖关系处理的过程）
+
+###  createBeanInstance 源码解析
+ ![方法描述](https://upload-images.jianshu.io/upload_images/4685968-3fe67a36af125c99.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+	protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {
+        // 确认需要创建的Bean实例的类可以实例化
+		Class<?> beanClass = resolveBeanClass(mbd, beanName);
+
+		if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {
+			throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+					"Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
+		}
+
+		Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
+		if (instanceSupplier != null) {
+			return obtainFromSupplier(instanceSupplier, beanName);
+		}
+
+        //若工厂方法非空,则使用工厂方法策略对Bean进行实例化
+		if (mbd.getFactoryMethodName() != null)  {
+			return instantiateUsingFactoryMethod(beanName, mbd, args);
+		}
+
+		// Shortcut when re-creating the same bean...
+		boolean resolved = false;
+		boolean autowireNecessary = false;
+		if (args == null) {
+			synchronized (mbd.constructorArgumentLock) {
+                //一个类有多个构造函数,每个构造函数都有不同的参数,所以调用前需要先根据参数锁定构造函数或对应的工厂方法
+				if (mbd.resolvedConstructorOrFactoryMethod != null) {
+					resolved = true;
+					autowireNecessary = mbd.constructorArgumentsResolved;
+				}
+			}
+		}
+                //如果已经解析过则使用解析好的构造函数方法不需要再次锁定
+		if (resolved) {
+			if (autowireNecessary) {
+                                //构造函数自动注入
+				return autowireConstructor(beanName, mbd, null, null);
+			}
+			else {
+                               //使用默认构造函数构造
+				return instantiateBean(beanName, mbd);
+			}
+		}
+
+                 // 使用构造函数对Bean进行实例化
+		Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
+		if (ctors != null ||
+				mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
+				mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
+			return autowireConstructor(beanName, mbd, ctors, args);
+		}
+
+		// No special handling: simply use no-arg constructor.
+               //使用默认的构造函数对Bean进行实例化
+		return instantiateBean(beanName, mbd);
+	}
+
+        //最常见的实例化过程instantiateBean
+	protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
+                 //使用默认的实例化策略对Bean进行实例化,默认的实例化策略是
+       //CglibSubclassingInstantiationStrategy,也就是使用CGLIB实例化Bean 
+		try {
+			Object beanInstance;
+			final BeanFactory parent = this;
+			if (System.getSecurityManager() != null) {
+				beanInstance = AccessController.doPrivileged(new PrivilegedAction<Object>() {
+					@Override
+					public Object run() {
+						return getInstantiationStrategy().instantiate(mbd, beanName, parent);
+					}
+				}, getAccessControlContext());
+			}
+			else {
+				beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
+			}
+			BeanWrapper bw = new BeanWrapperImpl(beanInstance);
+			initBeanWrapper(bw);
+			return bw;
+		}
+		catch (Throwable ex) {
+			throw new BeanCreationException(
+					mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
+		}
+	}
+```
+这里使用了CGLIB对Bean进行实例化
+
+在Spring AOP中也使用CGLIB对Java的字节码进行增强.
+## 使用CGLIB来生成Bean对象
+需要看一下`SimpleInstantiationStrategy`类;
+它是 Spring 用来生成Bean对象的默认类;
+它提供了两种实例化Bean对象的方法
+- BeanUtils,使用Java原生的反射功能
+- CGLIB
+
+```
+public class SimpleInstantiationStrategy implements InstantiationStrategy {
+    @Override
+	public Object instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner) {
+		// Don't override the class with CGLIB if no overrides.
+		if (bd.getMethodOverrides().isEmpty()) {
+            //这里取得指定的构造器或者生成对象的工厂方法来对Bean进行实例化
+			Constructor<?> constructorToUse;
+			synchronized (bd.constructorArgumentLock) {
+				constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
+				if (constructorToUse == null) {
+					final Class<?> clazz = bd.getBeanClass();
+					if (clazz.isInterface()) {
+						throw new BeanInstantiationException(clazz, "Specified class is an interface");
+					}
+					try {
+						if (System.getSecurityManager() != null) {
+							constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() {
+								@Override
+								public Constructor<?> run() throws Exception {
+									return clazz.getDeclaredConstructor((Class[]) null);
+								}
+							});
+						}
+						else {
+							constructorToUse =	clazz.getDeclaredConstructor((Class[]) null);
+						}
+						bd.resolvedConstructorOrFactoryMethod = constructorToUse;
+					}
+					catch (Throwable ex) {
+						throw new BeanInstantiationException(clazz, "No default constructor found", ex);
+					}
+				}
+			}
+            //通过BeanUtils进行实例化，这个BeanUtils的实例化通过Constructor来实例化Bean,在BeanUtils中可以看到具体的调用ctor.newInstance(args)
+			return BeanUtils.instantiateClass(constructorToUse);
+		}
+		else {		
+            // 使用CGLIB来实例化对象
+			return instantiateWithMethodInjection(bd, beanName, owner);
+		}
+	}
+}
+```
+
+# 4 Bean之间依赖关系的处理
+依赖关系处理的入口是前面提到的`populateBean`方法;
+由其涉及面广,仅简要介绍依赖关系处理的流程:
+在populateBean方法中
+- 首先取得在`BeanDefinition`中设置的`property`值,然后开始依赖注入的过程
+- 首先处理`Autowire`的注入,可以by Name/Type,之后对属性进行注入
+- 接着需要对Bean Reference进行解析
+在对ManageList、ManageSet、ManageMap等进行解析完之后，就已经为依赖注入准备好了条件;
+这是真正把Bean对象设置到它所依赖的另一个Bean属性中去的地方.
+- 依赖注入发生在BeanWrapper的setPropertyValues中
+具体的完成却是在BeanWrapper的子类BeanWrapperImpl中实现;
+它会完成Bean的属性值的注入，其中包括对Array的注入、对List等集合类以及对非集合类的域进行注入
+
+经过一系列的注入，这样就完成了对各种Bean属性的依赖注入过程
+
+在Bean的创建和对象依赖注入的过程中，需要依据`BeanDefinition`中的信息来递归地完成依赖注入
+
+从前面的几个递归过程中可以看到，这些递归都是以`getBean`为入口
+- 一个递归是在上下文中查找需要的Bean和创建Bean的递归调用
+- 另一个递归是在依赖注入时，通过递归调用容器的getBean方法，得到当前Bean的依赖Bean，同时也触发对依赖Bean的创建和注入。
+
+在对Bean的属性进行依赖注入时，解析也是一个递归的过程
+根据依赖关系，层层完成Bean的创建和注入，直到最后完成当前Bean的创建
+有了这个顶层Bean的创建和对它属性依赖注入的完成，意味着和当前Bean相关的整个依赖链的注入也就完成了
+
+在Bean创建和依赖注入完成后,在容器中建立起一系列依靠依赖关系联系起来的Bean，这个Bean已经不再是简单的Java对象了;
+该Bean系列以及Bean之间的依赖关系建立完成之后，通过IoC的相关接口方法，就可以非常方便地供上层应用使用了。
+
+# 5 lazy-init属性和预实例化
+在前面的`refresh`中，可看到调用了`finishBeanFactoryInitialization`来对配置了`lazy-init`的Bean进行处理
+其实在这个方法中,封装了对`lazy-init`属性的处理,实际的处理是在`DefaultListableBeanFactory`这个基本容器的`preInstantiateSingleton`方法中完成的
+该方法对单例Bean完成预实例化，这个预实例化的完成巧妙地委托给了容器来实现
+如果需要预实例化,那么就直接在这里采用`getBean`去触发依赖注入
diff --git a/Java/Spring/SpringBean.md b/Java/Spring/SpringBean.md
new file mode 100755
index 0000000000..892cdecfe1
--- /dev/null
+++ b/Java/Spring/SpringBean.md
@@ -0,0 +1,449 @@
+<!-- MarkdownTOC -->
+
+- [前言](#前言)
+- [一  bean的作用域](#一-bean的作用域)
+  - [1. singleton——唯一 bean 实例](#1-singleton——唯一-bean-实例)
+  - [2. prototype——每次请求都会创建一个新的 bean 实例](#2-prototype——每次请求都会创建一个新的-bean-实例)
+  - [3. request——每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效](#3-request——每一次http请求都会产生一个新的bean，该bean仅在当前http-request内有效)
+  - [4. session——每一次HTTP请求都会产生一个新的 bean，该bean仅在当前 HTTP session 内有效](#4-session——每一次http请求都会产生一个新的-bean，该bean仅在当前-http-session-内有效)
+  - [5. globalSession](#5-globalsession)
+- [二  bean的生命周期](#二-bean的生命周期)
+  - [initialization 和 destroy](#initialization-和-destroy)
+  - [实现*Aware接口 在Bean中使用Spring框架的一些对象](#实现aware接口-在bean中使用spring框架的一些对象)
+  - [BeanPostProcessor](#beanpostprocessor)
+  - [总结](#总结)
+  - [单例管理的对象](#单例管理的对象)
+  - [非单例管理的对象](#非单例管理的对象)
+- [三 说明](#三-说明)
+
+<!-- /MarkdownTOC -->
+
+# 前言 
+在 Spring 中，那些组成应用程序的主体及由 Spring IOC 容器所管理的对象，被称之为 bean。简单地讲，bean 就是由 IOC 容器初始化、装配及管理的对象，除此之外，bean 就与应用程序中的其他对象没有什么区别了。而 bean 的定义以及 bean 相互间的依赖关系将通过配置元数据来描述。
+
+**Spring中的bean默认都是单例的，这些单例Bean在多线程程序下如何保证线程安全呢？** 例如对于Web应用来说，Web容器对于每个用户请求都创建一个单独的Sevlet线程来处理请求，引入Spring框架之后，每个Action都是单例的，那么对于Spring托管的单例Service Bean，如何保证其安全呢？ **Spring的单例是基于BeanFactory也就是Spring容器的，单例Bean在此容器内只有一个，Java的单例是基于 JVM，每个 JVM 内只有一个实例。**
+
+# 一  bean的作用域
+
+创建一个bean定义，其实质是用该bean定义对应的类来创建真正实例的“配方”。把bean定义看成一个配方很有意义，它与class很类似，只根据一张“处方”就可以创建多个实例。不仅可以控制注入到对象中的各种依赖和配置值，还可以控制该对象的作用域。这样可以灵活选择所建对象的作用域，而不必在Java Class级定义作用域。Spring Framework支持五种作用域，分别阐述如下表。
+
+
+![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-17/1188352.jpg)
+
+五种作用域中，**request、session** 和 **global session** 三种作用域仅在基于web的应用中使用（不必关心你所采用的是什么web应用框架），只能用在基于 web 的 Spring ApplicationContext 环境。
+
+
+
+### 1. singleton——唯一 bean 实例
+
+**当一个 bean 的作用域为 singleton，那么Spring IoC容器中只会存在一个共享的 bean 实例，并且所有对 bean 的请求，只要 id 与该 bean 定义相匹配，则只会返回bean的同一实例。** singleton 是单例类型(对应于单例模式)，就是在创建起容器时就同时自动创建了一个bean的对象，不管你是否使用，但我们可以指定Bean节点的 `lazy-init=”true”` 来延迟初始化bean，这时候，只有在第一次获取bean时才会初始化bean，即第一次请求该bean时才初始化。 每次获取到的对象都是同一个对象。注意，singleton 作用域是Spring中的缺省作用域。要在XML中将 bean 定义成 singleton ，可以这样配置：
+
+```xml
+<bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" scope="singleton">
+```
+
+也可以通过 `@Scope` 注解（它可以显示指定bean的作用范围。）的方式
+
+```java
+@Service
+@Scope("singleton")
+public class ServiceImpl{
+
+}
+```
+
+### 2. prototype——每次请求都会创建一个新的 bean 实例
+
+**当一个bean的作用域为 prototype，表示一个 bean 定义对应多个对象实例。** **prototype 作用域的 bean 会导致在每次对该 bean 请求**（将其注入到另一个 bean 中，或者以程序的方式调用容器的 getBean() 方法**）时都会创建一个新的 bean 实例。prototype 是原型类型，它在我们创建容器的时候并没有实例化，而是当我们获取bean的时候才会去创建一个对象，而且我们每次获取到的对象都不是同一个对象。根据经验，对有状态的 bean 应该使用 prototype 作用域，而对无状态的 bean 则应该使用 singleton 作用域。**  在 XML 中将 bean 定义成 prototype ，可以这样配置：
+
+```java
+<bean id="account" class="com.foo.DefaultAccount" scope="prototype"/>  
+ 或者
+<bean id="account" class="com.foo.DefaultAccount" singleton="false"/> 
+```
+通过 `@Scope` 注解的方式实现就不做演示了。
+
+### 3. request——每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效
+
+**request只适用于Web程序，每一次 HTTP 请求都会产生一个新的bean，同时该bean仅在当前HTTP request内有效，当请求结束后，该对象的生命周期即告结束。** 在 XML 中将 bean 定义成 request ，可以这样配置：
+
+```java
+<bean id="loginAction" class=cn.csdn.LoginAction" scope="request"/>
+```
+
+### 4. session——每一次HTTP请求都会产生一个新的 bean，该bean仅在当前 HTTP session 内有效
+
+**session只适用于Web程序，session 作用域表示该针对每一次 HTTP 请求都会产生一个新的 bean，同时该 bean 仅在当前 HTTP session 内有效.与request作用域一样，可以根据需要放心的更改所创建实例的内部状态，而别的 HTTP session 中根据 userPreferences 创建的实例，将不会看到这些特定于某个 HTTP session 的状态变化。当HTTP session最终被废弃的时候，在该HTTP session作用域内的bean也会被废弃掉。**
+
+```xml
+<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
+```
+
+### 5. globalSession
+
+global session 作用域类似于标准的 HTTP session 作用域，不过仅仅在基于 portlet 的 web 应用中才有意义。Portlet 规范定义了全局 Session 的概念，它被所有构成某个 portlet web 应用的各种不同的 portle t所共享。在global session 作用域中定义的 bean 被限定于全局portlet Session的生命周期范围内。
+
+```xml
+<bean id="user" class="com.foo.Preferences "scope="globalSession"/>
+```
+
+# 二  bean的生命周期
+
+Spring Bean是Spring应用中最最重要的部分了。所以来看看Spring容器在初始化一个bean的时候会做那些事情，顺序是怎样的，在容器关闭的时候，又会做哪些事情。
+
+> spring版本：4.2.3.RELEASE
+鉴于Spring源码是用gradle构建的，我也决定舍弃我大maven，尝试下洪菊推荐过的gradle。运行beanLifeCycle模块下的junit test即可在控制台看到如下输出，可以清楚了解Spring容器在创建，初始化和销毁Bean的时候依次做了那些事情。
+
+```
+Spring容器初始化
+=====================================
+调用GiraffeService无参构造函数
+GiraffeService中利用set方法设置属性值
+调用setBeanName:: Bean Name defined in context=giraffeService
+调用setBeanClassLoader,ClassLoader Name = sun.misc.Launcher$AppClassLoader
+调用setBeanFactory,setBeanFactory:: giraffe bean singleton=true
+调用setEnvironment
+调用setResourceLoader:: Resource File Name=spring-beans.xml
+调用setApplicationEventPublisher
+调用setApplicationContext:: Bean Definition Names=[giraffeService, org.springframework.context.annotation.CommonAnnotationBeanPostProcessor#0, com.giraffe.spring.service.GiraffeServicePostProcessor#0]
+执行BeanPostProcessor的postProcessBeforeInitialization方法,beanName=giraffeService
+调用PostConstruct注解标注的方法
+执行InitializingBean接口的afterPropertiesSet方法
+执行配置的init-method
+执行BeanPostProcessor的postProcessAfterInitialization方法,beanName=giraffeService
+Spring容器初始化完毕
+=====================================
+从容器中获取Bean
+giraffe Name=李光洙
+=====================================
+调用preDestroy注解标注的方法
+执行DisposableBean接口的destroy方法
+执行配置的destroy-method
+Spring容器关闭
+```
+
+先来看看，Spring在Bean从创建到销毁的生命周期中可能做得事情。
+
+
+### initialization 和 destroy
+
+有时我们需要在Bean属性值set好之后和Bean销毁之前做一些事情，比如检查Bean中某个属性是否被正常的设置好值了。Spring框架提供了多种方法让我们可以在Spring Bean的生命周期中执行initialization和pre-destroy方法。
+
+**1.实现InitializingBean和DisposableBean接口**
+
+这两个接口都只包含一个方法。通过实现InitializingBean接口的afterPropertiesSet()方法可以在Bean属性值设置好之后做一些操作，实现DisposableBean接口的destroy()方法可以在销毁Bean之前做一些操作。
+
+例子如下：
+
+```java
+public class GiraffeService implements InitializingBean,DisposableBean {
+    @Override
+    public void afterPropertiesSet() throws Exception {
+        System.out.println("执行InitializingBean接口的afterPropertiesSet方法");
+    }
+    @Override
+    public void destroy() throws Exception {
+        System.out.println("执行DisposableBean接口的destroy方法");
+    }
+}
+```
+这种方法比较简单，但是不建议使用。因为这样会将Bean的实现和Spring框架耦合在一起。
+
+**2.在bean的配置文件中指定init-method和destroy-method方法**
+
+Spring允许我们创建自己的 init 方法和 destroy 方法，只要在 Bean 的配置文件中指定 init-method 和 destroy-method 的值就可以在 Bean 初始化时和销毁之前执行一些操作。
+
+例子如下：
+
+```java
+public class GiraffeService {
+    //通过<bean>的destroy-method属性指定的销毁方法
+    public void destroyMethod() throws Exception {
+        System.out.println("执行配置的destroy-method");
+    }
+    //通过<bean>的init-method属性指定的初始化方法
+    public void initMethod() throws Exception {
+        System.out.println("执行配置的init-method");
+    }
+}
+```
+
+配置文件中的配置：
+
+```
+<bean name="giraffeService" class="com.giraffe.spring.service.GiraffeService" init-method="initMethod" destroy-method="destroyMethod">
+</bean>
+```
+
+需要注意的是自定义的init-method和post-method方法可以抛异常但是不能有参数。
+
+这种方式比较推荐，因为可以自己创建方法，无需将Bean的实现直接依赖于spring的框架。
+
+**3.使用@PostConstruct和@PreDestroy注解**
+
+除了xml配置的方式，Spring 也支持用 `@PostConstruct`和 `@PreDestroy`注解来指定 `init` 和 `destroy` 方法。这两个注解均在`javax.annotation` 包中。为了注解可以生效，需要在配置文件中定义org.springframework.context.annotation.CommonAnnotationBeanPostProcessor或context:annotation-config
+
+例子如下：
+
+```java
+public class GiraffeService {
+    @PostConstruct
+    public void initPostConstruct(){
+        System.out.println("执行PostConstruct注解标注的方法");
+    }
+    @PreDestroy
+    public void preDestroy(){
+        System.out.println("执行preDestroy注解标注的方法");
+    }
+}
+```
+
+配置文件：
+
+```xml
+  
+<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor" />
+
+```
+
+### 实现*Aware接口 在Bean中使用Spring框架的一些对象
+
+有些时候我们需要在 Bean 的初始化中使用 Spring 框架自身的一些对象来执行一些操作，比如获取 ServletContext 的一些参数，获取 ApplicaitionContext 中的 BeanDefinition 的名字，获取 Bean 在容器中的名字等等。为了让 Bean 可以获取到框架自身的一些对象，Spring 提供了一组名为*Aware的接口。
+
+这些接口均继承于`org.springframework.beans.factory.Aware`标记接口，并提供一个将由 Bean 实现的set*方法,Spring通过基于setter的依赖注入方式使相应的对象可以被Bean使用。
+网上说，这些接口是利用观察者模式实现的，类似于servlet listeners，目前还不明白，不过这也不在本文的讨论范围内。
+介绍一些重要的Aware接口：
+
+- **ApplicationContextAware**: 获得ApplicationContext对象,可以用来获取所有Bean definition的名字。
+- **BeanFactoryAware**:获得BeanFactory对象，可以用来检测Bean的作用域。
+- **BeanNameAware**:获得Bean在配置文件中定义的名字。
+- **ResourceLoaderAware**:获得ResourceLoader对象，可以获得classpath中某个文件。
+- **ServletContextAware**:在一个MVC应用中可以获取ServletContext对象，可以读取context中的参数。
+- **ServletConfigAware**： 在一个MVC应用中可以获取ServletConfig对象，可以读取config中的参数。
+
+```java
+public class GiraffeService implements   ApplicationContextAware,
+        ApplicationEventPublisherAware, BeanClassLoaderAware, BeanFactoryAware,
+        BeanNameAware, EnvironmentAware, ImportAware, ResourceLoaderAware{
+         @Override
+    public void setBeanClassLoader(ClassLoader classLoader) {
+        System.out.println("执行setBeanClassLoader,ClassLoader Name = " + classLoader.getClass().getName());
+    }
+    @Override
+    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
+        System.out.println("执行setBeanFactory,setBeanFactory:: giraffe bean singleton=" +  beanFactory.isSingleton("giraffeService"));
+    }
+    @Override
+    public void setBeanName(String s) {
+        System.out.println("执行setBeanName:: Bean Name defined in context="
+                + s);
+    }
+    @Override
+    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
+        System.out.println("执行setApplicationContext:: Bean Definition Names="
+                + Arrays.toString(applicationContext.getBeanDefinitionNames()));
+    }
+    @Override
+    public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
+        System.out.println("执行setApplicationEventPublisher");
+    }
+    @Override
+    public void setEnvironment(Environment environment) {
+        System.out.println("执行setEnvironment");
+    }
+    @Override
+    public void setResourceLoader(ResourceLoader resourceLoader) {
+        Resource resource = resourceLoader.getResource("classpath:spring-beans.xml");
+        System.out.println("执行setResourceLoader:: Resource File Name="
+                + resource.getFilename());
+    }
+    @Override
+    public void setImportMetadata(AnnotationMetadata annotationMetadata) {
+        System.out.println("执行setImportMetadata");
+    }
+}
+```
+
+### BeanPostProcessor
+
+上面的*Aware接口是针对某个实现这些接口的Bean定制初始化的过程，
+Spring同样可以针对容器中的所有Bean，或者某些Bean定制初始化过程，只需提供一个实现BeanPostProcessor接口的类即可。 该接口中包含两个方法，postProcessBeforeInitialization和postProcessAfterInitialization。 postProcessBeforeInitialization方法会在容器中的Bean初始化之前执行， postProcessAfterInitialization方法在容器中的Bean初始化之后执行。
+
+例子如下：
+
+```java
+public class CustomerBeanPostProcessor implements BeanPostProcessor {
+    @Override
+    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
+        System.out.println("执行BeanPostProcessor的postProcessBeforeInitialization方法,beanName=" + beanName);
+        return bean;
+    }
+    @Override
+    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
+        System.out.println("执行BeanPostProcessor的postProcessAfterInitialization方法,beanName=" + beanName);
+        return bean;
+    }
+}
+```
+
+要将BeanPostProcessor的Bean像其他Bean一样定义在配置文件中
+
+```xml  
+<bean class="com.giraffe.spring.service.CustomerBeanPostProcessor"/>
+```
+
+### 总结
+
+所以。。。结合第一节控制台输出的内容，Spring Bean的生命周期是这样纸的：
+
+- Bean容器找到配置文件中 Spring Bean 的定义。
+- Bean容器利用Java Reflection API创建一个Bean的实例。
+- 如果涉及到一些属性值 利用set方法设置一些属性值。
+- 如果Bean实现了BeanNameAware接口，调用setBeanName()方法，传入Bean的名字。
+- 如果Bean实现了BeanClassLoaderAware接口，调用setBeanClassLoader()方法，传入ClassLoader对象的实例。
+- 如果Bean实现了BeanFactoryAware接口，调用setBeanClassLoader()方法，传入ClassLoader对象的实例。
+- 与上面的类似，如果实现了其他*Aware接口，就调用相应的方法。
+- 如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象，执行postProcessBeforeInitialization()方法
+- 如果Bean实现了InitializingBean接口，执行afterPropertiesSet()方法。
+- 如果Bean在配置文件中的定义包含init-method属性，执行指定的方法。
+- 如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象，执行postProcessAfterInitialization()方法
+- 当要销毁Bean的时候，如果Bean实现了DisposableBean接口，执行destroy()方法。
+- 当要销毁Bean的时候，如果Bean在配置文件中的定义包含destroy-method属性，执行指定的方法。
+
+用图表示一下(图来源:http://www.jianshu.com/p/d00539babca5)：
+
+![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-17/48376272.jpg)
+
+与之比较类似的中文版本:
+
+![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-17/5496407.jpg)
+
+
+**其实很多时候我们并不会真的去实现上面说描述的那些接口，那么下面我们就除去那些接口，针对bean的单例和非单例来描述下bean的生命周期：**
+
+### 单例管理的对象
+
+当scope=”singleton”，即默认情况下，会在启动容器时（即实例化容器时）时实例化。但我们可以指定Bean节点的lazy-init=”true”来延迟初始化bean，这时候，只有在第一次获取bean时才会初始化bean，即第一次请求该bean时才初始化。如下配置：
+
+```xml
+<bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" lazy-init="true"/>  
+```
+
+如果想对所有的默认单例bean都应用延迟初始化，可以在根节点beans设置default-lazy-init属性为true，如下所示：
+
+```xml
+<beans default-lazy-init="true" …>
+```
+
+默认情况下，Spring 在读取 xml 文件的时候，就会创建对象。在创建对象的时候先调用构造器，然后调用 init-method 属性值中所指定的方法。对象在被销毁的时候，会调用 destroy-method 属性值中所指定的方法（例如调用Container.destroy()方法的时候）。写一个测试类，代码如下：
+
+```java
+public class LifeBean {
+    private String name;  
+
+    public LifeBean(){  
+        System.out.println("LifeBean()构造函数");  
+    }  
+    public String getName() {  
+        return name;  
+    }  
+
+    public void setName(String name) {  
+        System.out.println("setName()");  
+        this.name = name;  
+    }  
+
+    public void init(){  
+        System.out.println("this is init of lifeBean");  
+    }  
+
+    public void destory(){  
+        System.out.println("this is destory of lifeBean " + this);  
+    }  
+}
+```
+　life.xml配置如下：
+
+```xml
+<bean id="life_singleton" class="com.bean.LifeBean" scope="singleton" 
+            init-method="init" destroy-method="destory" lazy-init="true"/>
+```
+
+测试代码：
+
+```java
+public class LifeTest {
+    @Test 
+    public void test() {
+        AbstractApplicationContext container = 
+        new ClassPathXmlApplicationContext("life.xml");
+        LifeBean life1 = (LifeBean)container.getBean("life");
+        System.out.println(life1);
+        container.close();
+    }
+}
+```
+
+运行结果：
+
+```
+LifeBean()构造函数
+this is init of lifeBean
+com.bean.LifeBean@573f2bb1
+……
+this is destory of lifeBean com.bean.LifeBean@573f2bb1
+```
+
+### 非单例管理的对象
+
+当`scope=”prototype”`时，容器也会延迟初始化 bean，Spring 读取xml 文件的时候，并不会立刻创建对象，而是在第一次请求该 bean 时才初始化（如调用getBean方法时）。在第一次请求每一个 prototype 的bean 时，Spring容器都会调用其构造器创建这个对象，然后调用`init-method`属性值中所指定的方法。对象销毁的时候，Spring 容器不会帮我们调用任何方法，因为是非单例，这个类型的对象有很多个，Spring容器一旦把这个对象交给你之后，就不再管理这个对象了。
+
+为了测试prototype bean的生命周期life.xml配置如下：
+
+```xml
+<bean id="life_prototype" class="com.bean.LifeBean" scope="prototype" init-method="init" destroy-method="destory"/>
+```
+
+测试程序：
+
+```java
+public class LifeTest {
+    @Test 
+    public void test() {
+        AbstractApplicationContext container = new ClassPathXmlApplicationContext("life.xml");
+        LifeBean life1 = (LifeBean)container.getBean("life_singleton");
+        System.out.println(life1);
+
+        LifeBean life3 = (LifeBean)container.getBean("life_prototype");
+        System.out.println(life3);
+        container.close();
+    }
+}
+```
+
+运行结果：
+
+```
+LifeBean()构造函数
+this is init of lifeBean
+com.bean.LifeBean@573f2bb1
+LifeBean()构造函数
+this is init of lifeBean
+com.bean.LifeBean@5ae9a829
+……
+this is destory of lifeBean com.bean.LifeBean@573f2bb1
+```
+
+可以发现，对于作用域为 prototype 的 bean ，其`destroy`方法并没有被调用。**如果 bean 的 scope 设为prototype时，当容器关闭时，`destroy` 方法不会被调用。对于 prototype 作用域的 bean，有一点非常重要，那就是 Spring不能对一个 prototype bean 的整个生命周期负责：容器在初始化、配置、装饰或者是装配完一个prototype实例后，将它交给客户端，随后就对该prototype实例不闻不问了。** 不管何种作用域，容器都会调用所有对象的初始化生命周期回调方法。但对prototype而言，任何配置好的析构生命周期回调方法都将不会被调用。**清除prototype作用域的对象并释放任何prototype bean所持有的昂贵资源，都是客户端代码的职责**（让Spring容器释放被prototype作用域bean占用资源的一种可行方式是，通过使用bean的后置处理器，该处理器持有要被清除的bean的引用）。谈及prototype作用域的bean时，在某些方面你可以将Spring容器的角色看作是Java new操作的替代者，任何迟于该时间点的生命周期事宜都得交由客户端来处理。
+
+**Spring 容器可以管理 singleton 作用域下 bean 的生命周期，在此作用域下，Spring 能够精确地知道bean何时被创建，何时初始化完成，以及何时被销毁。而对于 prototype 作用域的bean，Spring只负责创建，当容器创建了 bean 的实例后，bean 的实例就交给了客户端的代码管理，Spring容器将不再跟踪其生命周期，并且不会管理那些被配置成prototype作用域的bean的生命周期。**
+
+
+# 三 说明
+
+本文的完成结合了下面两篇文章，并做了相应修改：
+
+- https://blog.csdn.net/fuzhongmin05/article/details/73389779
+- https://yemengying.com/2016/07/14/spring-bean-life-cycle/
+
+由于本文非本人独立原创，所以未声明为原创！在此说明！
diff --git "a/Java/Spring/SpringMVC \345\267\245\344\275\234\345\216\237\347\220\206\350\257\246\350\247\243.md" "b/Java/Spring/SpringMVC \345\267\245\344\275\234\345\216\237\347\220\206\350\257\246\350\247\243.md"
new file mode 100755
index 0000000000..0efcd3f953
--- /dev/null
+++ "b/Java/Spring/SpringMVC \345\267\245\344\275\234\345\216\237\347\220\206\350\257\246\350\247\243.md"	
@@ -0,0 +1,269 @@
+> 本文整理自网络，原文出处暂不知，对原文做了较大的改动，在此说明！
+
+### 先来看一下什么是 MVC 模式
+
+MVC 是一种设计模式.
+
+**MVC 的原理图如下：**
+
+![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-11/60679444.jpg)
+
+
+
+### SpringMVC 简单介绍
+
+SpringMVC 框架是以请求为驱动，围绕 Servlet 设计，将请求发给控制器，然后通过模型对象，分派器来展示请求结果视图。其中核心类是 DispatcherServlet，它是一个 Servlet，顶层是实现的Servlet接口。
+
+### SpringMVC 使用
+
+需要在 web.xml 中配置 DispatcherServlet 。并且需要配置 Spring 监听器ContextLoaderListener
+
+```xml
+
+<listener>
+	<listener-class>org.springframework.web.context.ContextLoaderListener
+	</listener-class>
+</listener>
+<servlet>
+	<servlet-name>springmvc</servlet-name>
+	<servlet-class>org.springframework.web.servlet.DispatcherServlet
+	</servlet-class>
+	<!-- 如果不设置init-param标签，则必须在/WEB-INF/下创建xxx-servlet.xml文件，其中xxx是servlet-name中配置的名称。 -->
+	<init-param>
+		<param-name>contextConfigLocation</param-name>
+		<param-value>classpath:spring/springmvc-servlet.xml</param-value>
+	</init-param>
+	<load-on-startup>1</load-on-startup>
+</servlet>
+<servlet-mapping>
+	<servlet-name>springmvc</servlet-name>
+	<url-pattern>/</url-pattern>
+</servlet-mapping>
+
+```
+
+### SpringMVC 工作原理（重要）
+
+**简单来说：**
+
+客户端发送请求-> 前端控制器 DispatcherServlet 接受客户端请求 -> 找到处理器映射 HandlerMapping 解析请求对应的 Handler-> HandlerAdapter 会根据 Handler 来调用真正的处理器开处理请求，并处理相应的业务逻辑 -> 处理器返回一个模型视图 ModelAndView -> 视图解析器进行解析 -> 返回一个视图对象->前端控制器 DispatcherServlet 渲染数据（Moder）->将得到视图对象返回给用户
+
+
+
+**如下图所示：**
+![SpringMVC运行原理](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-11/49790288.jpg)
+
+上图的一个笔误的小问题：Spring MVC 的入口函数也就是前端控制器 DispatcherServlet 的作用是接收请求，响应结果。
+
+**流程说明（重要）：**
+
+（1）客户端（浏览器）发送请求，直接请求到 DispatcherServlet。
+
+（2）DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。
+
+（3）解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由 HandlerAdapter 适配器处理。
+
+（4）HandlerAdapter 会根据 Handler 来调用真正的处理器开处理请求，并处理相应的业务逻辑。
+
+（5）处理器处理完业务后，会返回一个 ModelAndView 对象，Model 是返回的数据对象，View 是个逻辑上的 View。
+
+（6）ViewResolver 会根据逻辑 View 查找实际的 View。
+
+（7）DispaterServlet 把返回的 Model 传给 View（视图渲染）。
+
+（8）把 View 返回给请求者（浏览器）
+
+
+
+### SpringMVC 重要组件说明
+
+
+**1、前端控制器DispatcherServlet（不需要工程师开发）,由框架提供（重要）**
+
+作用：**Spring MVC 的入口函数。接收请求，响应结果，相当于转发器，中央处理器。有了 DispatcherServlet 减少了其它组件之间的耦合度。用户请求到达前端控制器，它就相当于mvc模式中的c，DispatcherServlet是整个流程控制的中心，由它调用其它组件处理用户的请求，DispatcherServlet的存在降低了组件之间的耦合性。**
+
+**2、处理器映射器HandlerMapping(不需要工程师开发),由框架提供**
+
+作用：根据请求的url查找Handler。HandlerMapping负责根据用户请求找到Handler即处理器（Controller），SpringMVC提供了不同的映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等。
+
+**3、处理器适配器HandlerAdapter**
+
+作用：按照特定规则（HandlerAdapter要求的规则）去执行Handler
+通过HandlerAdapter对处理器进行执行，这是适配器模式的应用，通过扩展适配器可以对更多类型的处理器进行执行。
+
+**4、处理器Handler(需要工程师开发)**
+
+注意：编写Handler时按照HandlerAdapter的要求去做，这样适配器才可以去正确执行Handler
+Handler 是继DispatcherServlet前端控制器的后端控制器，在DispatcherServlet的控制下Handler对具体的用户请求进行处理。
+由于Handler涉及到具体的用户业务请求，所以一般情况需要工程师根据业务需求开发Handler。
+
+**5、视图解析器View resolver(不需要工程师开发),由框架提供**
+
+作用：进行视图解析，根据逻辑视图名解析成真正的视图（view）
+View Resolver负责将处理结果生成View视图，View Resolver首先根据逻辑视图名解析成物理视图名即具体的页面地址，再生成View视图对象，最后对View进行渲染将处理结果通过页面展示给用户。 springmvc框架提供了很多的View视图类型，包括：jstlView、freemarkerView、pdfView等。
+一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户，需要由工程师根据业务需求开发具体的页面。
+
+**6、视图View(需要工程师开发)**
+
+View是一个接口，实现类支持不同的View类型（jsp、freemarker、pdf...）
+
+**注意：处理器Handler（也就是我们平常说的Controller控制器）以及视图层view都是需要我们自己手动开发的。其他的一些组件比如：前端控制器DispatcherServlet、处理器映射器HandlerMapping、处理器适配器HandlerAdapter等等都是框架提供给我们的，不需要自己手动开发。**
+
+### DispatcherServlet详细解析
+
+首先看下源码：
+
+```java
+package org.springframework.web.servlet;
+ 
+@SuppressWarnings("serial")
+public class DispatcherServlet extends FrameworkServlet {
+ 
+	public static final String MULTIPART_RESOLVER_BEAN_NAME = "multipartResolver";
+	public static final String LOCALE_RESOLVER_BEAN_NAME = "localeResolver";
+	public static final String THEME_RESOLVER_BEAN_NAME = "themeResolver";
+	public static final String HANDLER_MAPPING_BEAN_NAME = "handlerMapping";
+	public static final String HANDLER_ADAPTER_BEAN_NAME = "handlerAdapter";
+	public static final String HANDLER_EXCEPTION_RESOLVER_BEAN_NAME = "handlerExceptionResolver";
+	public static final String REQUEST_TO_VIEW_NAME_TRANSLATOR_BEAN_NAME = "viewNameTranslator";
+	public static final String VIEW_RESOLVER_BEAN_NAME = "viewResolver";
+	public static final String FLASH_MAP_MANAGER_BEAN_NAME = "flashMapManager";
+	public static final String WEB_APPLICATION_CONTEXT_ATTRIBUTE = DispatcherServlet.class.getName() + ".CONTEXT";
+	public static final String LOCALE_RESOLVER_ATTRIBUTE = DispatcherServlet.class.getName() + ".LOCALE_RESOLVER";
+	public static final String THEME_RESOLVER_ATTRIBUTE = DispatcherServlet.class.getName() + ".THEME_RESOLVER";
+	public static final String THEME_SOURCE_ATTRIBUTE = DispatcherServlet.class.getName() + ".THEME_SOURCE";
+	public static final String INPUT_FLASH_MAP_ATTRIBUTE = DispatcherServlet.class.getName() + ".INPUT_FLASH_MAP";
+	public static final String OUTPUT_FLASH_MAP_ATTRIBUTE = DispatcherServlet.class.getName() + ".OUTPUT_FLASH_MAP";
+	public static final String FLASH_MAP_MANAGER_ATTRIBUTE = DispatcherServlet.class.getName() + ".FLASH_MAP_MANAGER";
+	public static final String EXCEPTION_ATTRIBUTE = DispatcherServlet.class.getName() + ".EXCEPTION";
+	public static final String PAGE_NOT_FOUND_LOG_CATEGORY = "org.springframework.web.servlet.PageNotFound";
+	private static final String DEFAULT_STRATEGIES_PATH = "DispatcherServlet.properties";
+	protected static final Log pageNotFoundLogger = LogFactory.getLog(PAGE_NOT_FOUND_LOG_CATEGORY);
+	private static final Properties defaultStrategies;
+	static {
+		try {
+			ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
+			defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
+		}
+		catch (IOException ex) {
+			throw new IllegalStateException("Could not load 'DispatcherServlet.properties': " + ex.getMessage());
+		}
+	}
+ 
+	/** Detect all HandlerMappings or just expect "handlerMapping" bean? */
+	private boolean detectAllHandlerMappings = true;
+ 
+	/** Detect all HandlerAdapters or just expect "handlerAdapter" bean? */
+	private boolean detectAllHandlerAdapters = true;
+ 
+	/** Detect all HandlerExceptionResolvers or just expect "handlerExceptionResolver" bean? */
+	private boolean detectAllHandlerExceptionResolvers = true;
+ 
+	/** Detect all ViewResolvers or just expect "viewResolver" bean? */
+	private boolean detectAllViewResolvers = true;
+ 
+	/** Throw a NoHandlerFoundException if no Handler was found to process this request? **/
+	private boolean throwExceptionIfNoHandlerFound = false;
+ 
+	/** Perform cleanup of request attributes after include request? */
+	private boolean cleanupAfterInclude = true;
+ 
+	/** MultipartResolver used by this servlet */
+	private MultipartResolver multipartResolver;
+ 
+	/** LocaleResolver used by this servlet */
+	private LocaleResolver localeResolver;
+ 
+	/** ThemeResolver used by this servlet */
+	private ThemeResolver themeResolver;
+ 
+	/** List of HandlerMappings used by this servlet */
+	private List<HandlerMapping> handlerMappings;
+ 
+	/** List of HandlerAdapters used by this servlet */
+	private List<HandlerAdapter> handlerAdapters;
+ 
+	/** List of HandlerExceptionResolvers used by this servlet */
+	private List<HandlerExceptionResolver> handlerExceptionResolvers;
+ 
+	/** RequestToViewNameTranslator used by this servlet */
+	private RequestToViewNameTranslator viewNameTranslator;
+ 
+	private FlashMapManager flashMapManager;
+ 
+	/** List of ViewResolvers used by this servlet */
+	private List<ViewResolver> viewResolvers;
+ 
+	public DispatcherServlet() {
+		super();
+	}
+ 
+	public DispatcherServlet(WebApplicationContext webApplicationContext) {
+		super(webApplicationContext);
+	}
+	@Override
+	protected void onRefresh(ApplicationContext context) {
+		initStrategies(context);
+	}
+ 
+	protected void initStrategies(ApplicationContext context) {
+		initMultipartResolver(context);
+		initLocaleResolver(context);
+		initThemeResolver(context);
+		initHandlerMappings(context);
+		initHandlerAdapters(context);
+		initHandlerExceptionResolvers(context);
+		initRequestToViewNameTranslator(context);
+		initViewResolvers(context);
+		initFlashMapManager(context);
+	}
+}
+
+```
+
+DispatcherServlet类中的属性beans：
+
+- HandlerMapping：用于handlers映射请求和一系列的对于拦截器的前处理和后处理，大部分用@Controller注解。
+- HandlerAdapter：帮助DispatcherServlet处理映射请求处理程序的适配器，而不用考虑实际调用的是 哪个处理程序。- - - 
+- ViewResolver：根据实际配置解析实际的View类型。
+- ThemeResolver：解决Web应用程序可以使用的主题，例如提供个性化布局。
+- MultipartResolver：解析多部分请求，以支持从HTML表单上传文件。- 
+- FlashMapManager：存储并检索可用于将一个请求属性传递到另一个请求的input和output的FlashMap，通常用于重定向。
+
+在Web MVC框架中，每个DispatcherServlet都拥自己的WebApplicationContext，它继承了ApplicationContext。WebApplicationContext包含了其上下文和Servlet实例之间共享的所有的基础框架beans。
+
+**HandlerMapping**
+
+![HandlerMapping](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-11/96666164.jpg)
+
+HandlerMapping接口处理请求的映射HandlerMapping接口的实现类：
+
+- SimpleUrlHandlerMapping类通过配置文件把URL映射到Controller类。
+- DefaultAnnotationHandlerMapping类通过注解把URL映射到Controller类。
+
+**HandlerAdapter**
+
+
+![HandlerAdapter](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-11/91433100.jpg)
+
+HandlerAdapter接口-处理请求映射
+
+AnnotationMethodHandlerAdapter：通过注解，把请求URL映射到Controller类的方法上。
+
+**HandlerExceptionResolver**
+
+
+![HandlerExceptionResolver](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-11/50343885.jpg)
+
+HandlerExceptionResolver接口-异常处理接口
+
+- SimpleMappingExceptionResolver通过配置文件进行异常处理。
+- AnnotationMethodHandlerExceptionResolver：通过注解进行异常处理。
+
+**ViewResolver**
+
+![ViewResolver](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-10-11/49497279.jpg)
+
+ViewResolver接口解析View视图。
+
+UrlBasedViewResolver类 通过配置文件，把一个视图名交给到一个View来处理。
diff --git a/Java/Spring/SpringMVC-Restful.md b/Java/Spring/SpringMVC-Restful.md
new file mode 100644
index 0000000000..8b28cd41a4
--- /dev/null
+++ b/Java/Spring/SpringMVC-Restful.md
@@ -0,0 +1,4 @@
+#目录
+![](http://upload-images.jianshu.io/upload_images/4685968-94a97353276bdf14.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![image.png](http://upload-images.jianshu.io/upload_images/4685968-719754d3a7ef1f6b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![image.png](http://upload-images.jianshu.io/upload_images/4685968-f82e02cc4cd5cea7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/Java/Spring/SpringMVC-\347\232\204\345\244\204\347\220\206\346\213\246\346\210\252\345\231\250.md" "b/Java/Spring/SpringMVC-\347\232\204\345\244\204\347\220\206\346\213\246\346\210\252\345\231\250.md"
new file mode 100644
index 0000000000..dea63a4a11
--- /dev/null
+++ "b/Java/Spring/SpringMVC-\347\232\204\345\244\204\347\220\206\346\213\246\346\210\252\345\231\250.md"
@@ -0,0 +1,75 @@
+#0 目录
+![](http://upload-images.jianshu.io/upload_images/4685968-0e96e02f95af818c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-14563a0520de7e61.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-48c508160847ed78.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-060046ab31685f80.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ ![](http://upload-images.jianshu.io/upload_images/4685968-174b6d94bc2397c2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 1 Spring MVC拦截器流程图
+![](http://upload-images.jianshu.io/upload_images/4685968-ca4e9021f653c954.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#2 Spring Web MVC 的处理器拦截器
+![](https://upload-images.jianshu.io/upload_images/4685968-1b14ff00f1e4ab85.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+类似于Servlet 开发中的过滤器Filter，用于对处理器进行预处理和后处理
+
+HandlerInterceptor接口定义了三个方法
+##2.1  preHandle
+该方法将在**请求处理之前进行调用**,只有当该方法返回true时,才会继续调用下一个`Interceptor`的`preHandle()`,如果已是最后一个`Interceptor`就会是调用当前请求的`Controller`
+##2.2 postHandle
+该方法将在请求处理后,`DispatcherServlet`进行视图返回**渲染之前进行调用**,可以在这个方法中对`Controller`处理之后的`ModelAndView`对象进行操作(比如这里加入公用信息以便页面显示)
+##2.3 afterCompletion
+该方法也是需要当前对应的`Interceptor`的`preHandle`方法的返回值为`true`时才会执行,该方法将在整个请求结束之后,也就是在`DispatcherServlet` 渲染了对应的视图之后执行
+**用于资源清理**
+
+#3 拦截器配置
+##3.1 针对某种mapping拦截器配置
+```xml
+ <bean  
+   class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">  
+   <property name="interceptors">  
+      <list>  
+         <ref bean="handlerInterceptor1"/>  
+         <ref bean="handlerInterceptor2"/>  
+      </list>  
+   </property>  
+</bean>  
+<bean id="handlerInterceptor1"class="springmvc.intercapter.HandlerInterceptor1"/>  
+<bean id="handlerInterceptor2"class="springmvc.intercapter.HandlerInterceptor2"/> 
+```
+##3.2 针对所有mapping配置全局拦截器
+```xml
+<!--拦截器 -->  
+<mvc:interceptors>  
+   <!--多个拦截器,顺序执行 -->  
+   <mvc:interceptor>  
+      <mvc:mapping path="/**"/>  
+      <bean class="com.sss.filter.HandlerInterceptor1"></bean>  
+   </mvc:interceptor>  
+   <mvc:interceptor>  
+      <mvc:mapping path="/**"/>  
+      <bean class="com.sss.filter.HandlerInterceptor2"></bean>  
+   </mvc:interceptor>  
+</mvc:interceptors>  
+```
+#4 实践
+ 用户访问其他页面时,从Seesion中获取到用户，未登录则重定向到登录页面。
+```java
+Public class LoginInterceptor implements HandlerInterceptor{   
+    @Override  
+    Public boolean preHandle(HttpServletRequest request,  
+            HttpServletResponse response, Object handler) throws Exception {  
+  
+        //如果是登录页面则放行  
+        if(request.getRequestURI().indexOf("login.action")>=0){  
+            return true;  
+        }  
+        HttpSession session = request.getSession();  
+        //如果用户已登录也放行  
+        if(session.getAttribute("user")!=null){  
+            return true;  
+        }  
+        //用户没有登录挑战到登录页面  
+        request.getRequestDispatcher("/WEB-INF/jsp/login.jsp").forward(request, response);  
+          
+        return false;  
+    }  
+```
diff --git "a/Java/Spring/SpringMVC\344\271\213@CookieValue\346\263\250\350\247\243.md" "b/Java/Spring/SpringMVC\344\271\213@CookieValue\346\263\250\350\247\243.md"
new file mode 100644
index 0000000000..74bcb93f43
--- /dev/null
+++ "b/Java/Spring/SpringMVC\344\271\213@CookieValue\346\263\250\350\247\243.md"
@@ -0,0 +1,21 @@
+#使用**@CookieValue**注解映射**cookie**值
+***@CookieValue*** 注解能将一个方法参数与一个**HTTP cookie**的值进行绑定,即可自动解析cookie。
+看一个这样的场景：以下的这个cookie存储在一个HTTP请求中：
+
+```
+	t=4CBCBDA72BB84FC8BE0515344C6FDF46
+```
+
+下面的代码演示了拿到 t 这个cookie值的方法：
+定义@RequestMapping注解的处理方法
+
+```
+    @RequestMapping(path = "/logout/", method = {RequestMethod.GET, RequestMethod.POST})
+    @ResponseBody
+    public String logout(@CookieValue("ticket") String ticket) {
+        userService.logout(ticket);
+        return "redirect:/";
+    }
+```
+若注解的目标方法参数不是 String 类型，则类型转换会自动进行
+这个注解可以注解到处理器方法上，在Servlet环境和Portlet环境都能使用。
diff --git "a/Java/Spring/SpringMVC\344\271\213Controller\346\237\245\346\211\276(Spring4-0-3-Spring5-0-4\346\272\220\347\240\201\350\277\233\345\214\226\345\257\271\346\257\224).md" "b/Java/Spring/SpringMVC\344\271\213Controller\346\237\245\346\211\276(Spring4-0-3-Spring5-0-4\346\272\220\347\240\201\350\277\233\345\214\226\345\257\271\346\257\224).md"
new file mode 100644
index 0000000000..3c7cc7911f
--- /dev/null
+++ "b/Java/Spring/SpringMVC\344\271\213Controller\346\237\245\346\211\276(Spring4-0-3-Spring5-0-4\346\272\220\347\240\201\350\277\233\345\214\226\345\257\271\346\257\224).md"
@@ -0,0 +1,575 @@
+# 0 摘要
+*   本文从源码层面简单讲解SpringMVC的处理器映射环节，也就是查找Controller详细过程
+# 1 SpringMVC请求流程
+![](http://upload-images.jianshu.io/upload_images/4685968-eef6c5ac8e72964d..jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+* Controller查找在上图中对应的步骤1至2的过程
+![SpringMVC详细运行流程图](https://upload-images.jianshu.io/upload_images/4685968-3beebf916a013f9f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#2 SpringMVC初始化过程
+##2.1 先认识两个类
+- Handler 
+通常指用于处理request请求的实际对象，可以类比 XxxController。在Spring Mvc中并没有具体的类叫 Handler。
+1.  `RequestMappingInfo`
+封装`RequestMapping`注解
+包含HTTP请求头的相关信息
+一个实例对应一个`RequestMapping`注解
+2.  `HandlerMethod`
+封装Controller的处理请求方法
+包含该方法所属的bean对象、该方法对应的method对象、该方法的参数等
+![RequestMappingHandlerMapping的继承关系](https://upload-images.jianshu.io/upload_images/4685968-e88884b624b22a65.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![初始化调用链](https://upload-images.jianshu.io/upload_images/4685968-8b9fb142018bf8f7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+##2.2  RequestMappingHandlerMapping、AbstractHandlerMethodMapping
+`RequestMappingHandlerMapping` 实现了`InitalizingBean`
+Spring容器在启动的时候会执行`InitalizingBean.afterPropertiesSet()`方法`RequestMappingHandlerMapping`实现了这个方法，这里也是Spring MVC初始化的入口。
+然后进入`AbstractHandlerMethodMapping`的`afterPropertiesSet`
+这个方法会进入该类的`initHandlerMethods`
+负责从`applicationContext`中扫描beans,然后从bean中查找并注册处理器方法
+##2.3 真正的初始化方法initHandlerMethods()
+###Spring4.0.3版本
+```
+//Scan beans in the ApplicationContext, detect and register handler methods.
+protected void initHandlerMethods() {
+  ...
+
+  //获取applicationContext中所有的bean name
+  String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ?
+        BeanFactoryUtils.beanNamesForTypeIncludingAncestors(getApplicationContext(), Object.class) :
+        getApplicationContext().getBeanNamesForType(Object.class));
+  
+  //遍历beanName数组
+  for (String beanName : beanNames) {
+      //isHandler会根据bean来判断bean定义中是否带有Controller注解或RequestMapping注解
+      if (isHandler(getApplicationContext().getType(beanName))){
+        detectHandlerMethods(beanName);
+      }
+  }
+  handlerMethodsInitialized(getHandlerMethods());
+}
+
+```
+###Spring5.0.4版本
+```java
+   /**
+	 * Scan beans in the ApplicationContext, detect and register handler methods.
+	 */
+	protected void initHandlerMethods() {
+		if (logger.isDebugEnabled()) {
+			logger.debug("Looking for request mappings in application context: " + getApplicationContext());
+		}
+        //获取所有容器托管的 beanName
+		String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ?
+				BeanFactoryUtils.beanNamesForTypeIncludingAncestors(obtainApplicationContext(), Object.class) :
+				obtainApplicationContext().getBeanNamesForType(Object.class));
+
+		for (String beanName : beanNames) {
+			if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
+				Class<?> beanType = null;
+				try {
+                    //获取 Class 信息
+					beanType = obtainApplicationContext().getType(beanName);
+				}
+				catch (Throwable ex) {
+					// An unresolvable bean type, probably from a lazy bean - let's ignore it.
+					if (logger.isDebugEnabled()) {
+						logger.debug("Could not resolve target class for bean with name '" + beanName + "'", ex);
+					}
+				}
+                // isHandler()方法判断这个类是否有 @RequestMapping 或 @Controller
+				if (beanType != null && isHandler(beanType)) {
+                    //发现并注册 Controller @RequestMapping方法
+					detectHandlerMethods(beanName);
+				}
+			}
+		}
+        //Spring MVC框架没有实现、可以用于功能扩展
+		handlerMethodsInitialized(getHandlerMethods());
+	}
+```
+![RequestMappingHandlerMapping#isHandler](https://upload-images.jianshu.io/upload_images/4685968-3f4f724908ccf668.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+*   上图方法即判断当前bean定义是否带有Controlller注解或RequestMapping注解
+如果只有`RequestMapping`生效吗？不会的!
+因为这种情况下Spring初始化的时候不会把该类注册为Spring bean,遍历beanNames时不会遍历到这个类，所以这里把`Controller`换成`Compoent`也可以，不过一般不这么做
+##2.3 从handler中获取HandlerMethod
+当确定bean为handler后,便会从该bean中查找出具体的handler方法（即`Controller`类下的具体定义的请求处理方法）,查找代码如下
+###Spring4.0.3
+```
+   /**
+	 * Look for handler methods in a handler
+	 * @param handler the bean name of a handler or a handler instance
+	 */
+protected void detectHandlerMethods(final Object handler) {
+  //获取当前Controller bean的class对象
+  Class<?> handlerType = (handler instanceof String) ?
+        getApplicationContext().getType((String) handler) : handler.getClass();
+
+  //避免重复调用 getMappingForMethod 来重建 RequestMappingInfo 实例
+  final Map<Method, T> mappings = new IdentityHashMap<Method, T>();
+  //同上，也是该Controller bean的class对象
+  final Class<?> userType = ClassUtils.getUserClass(handlerType);
+  
+  //获取当前bean的所有handler method
+  //根据 method 定义是否带有 RequestMapping 
+  //若有则创建RequestMappingInfo实例
+  Set<Method> methods = HandlerMethodSelector.selectMethods(userType, new MethodFilter() {
+			@Override
+			public boolean matches(Method method) {
+				T mapping = getMappingForMethod(method, userType);
+				if (mapping != null) {
+					mappings.put(method, mapping);
+					return true;
+				}
+				else {
+					return false;
+				}
+			}
+  });
+
+   //遍历并注册当前bean的所有handler method
+   for (Method method : methods) {
+            //注册handler method，进入以下方法
+			registerHandlerMethod(handler, method, mappings.get(method));
+   }
+ 
+```
+###Spring5.0.4
+```java
+	/**
+	 * Look for handler methods in a handler.
+	 * @param handler the bean name of a handler or a handler instance
+	 */
+	protected void detectHandlerMethods(final Object handler) {
+		Class<?> handlerType = (handler instanceof String ?
+				obtainApplicationContext().getType((String) handler) : handler.getClass());
+
+		if (handlerType != null) {
+			final Class<?> userType = ClassUtils.getUserClass(handlerType);
+			Map<Method, T> methods = MethodIntrospector.selectMethods(userType,
+					(MethodIntrospector.MetadataLookup<T>) method -> {
+						try {
+                            //获取 RequestMappingInfo
+							return getMappingForMethod(method, userType);
+						}
+						catch (Throwable ex) {
+							throw new IllegalStateException("Invalid mapping on handler class [" +
+									userType.getName() + "]: " + method, ex);
+						}
+					});
+			if (logger.isDebugEnabled()) {
+				logger.debug(methods.size() + " request handler methods found on " + userType + ": " + methods);
+			}
+			for (Map.Entry<Method, T> entry : methods.entrySet()) {
+				Method invocableMethod = AopUtils.selectInvocableMethod(entry.getKey(), userType);
+				T mapping = entry.getValue();
+                //注册RequestMappingInfo
+				registerHandlerMethod(handler, invocableMethod, mapping);
+			}
+		}
+	}
+```
+以上代码有两个地方有调用了`getMappingForMethod`
+##2.4 创建RequestMappingInfo
+这一步会获取方法和类上的`@RequestMapping`并通过 `@RequestMaping`配置的参数生成相应的RequestMappingInfo。RequestMappingInfo中保存了很多Request需要匹配的参数。
+1、匹配请求Url PatternsRequestCondition patternsCondition;
+2、匹配请求方法 GET等 RequestMethodsRequestCondition methodsCondition;
+3、匹配参数例如@Requestmaping(Params="action=DoXxx") ParamsRequestCondition paramsCondition;
+4、匹配请求头信息 HeadersRequestCondition headersCondition;
+5、指定处理请求的提交内容类型（Content-Type），例如application/json, text/html; ConsumesRequestCondition consumesCondition;
+6、指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回ProducesRequestCondition producesCondition;
+7、用于用户定制请求条件 RequestConditionHolder customConditionHolder; 举个例子，当我们有一个需求只要请求中包含某一个参数时都可以掉这个方法处理，就可以定制这个匹配条件。
+``` 
+    //使用方法和类型级别RequestMapping注解来创建RequestMappingInfo
+	@Override
+	protected RequestMappingInfo getMappingForMethod(Method method, Class<?> handlerType) {
+		RequestMappingInfo info = null;
+        //获取method的@RequestMapping
+		RequestMapping methodAnnotation = AnnotationUtils.findAnnotation(method, RequestMapping.class);
+		if (methodAnnotation != null) {
+			RequestCondition<?> methodCondition = getCustomMethodCondition(method);
+			info = createRequestMappingInfo(methodAnnotation, methodCondition);
+            //获取method所属bean的@RequtestMapping注解
+			RequestMapping typeAnnotation = AnnotationUtils.findAnnotation(handlerType, RequestMapping.class);
+			if (typeAnnotation != null) {
+				RequestCondition<?> typeCondition = getCustomTypeCondition(handlerType);
+                //合并两个@RequestMapping注解
+				info = createRequestMappingInfo(typeAnnotation, typeCondition).combine(info);
+			}
+		}
+		return info;
+	}
+```
+###Spring5.0.4
+```java
+   /**
+	 * Uses method and type-level @{@link RequestMapping} annotations to create
+	 * the RequestMappingInfo.
+	 * @return the created RequestMappingInfo, or {@code null} if the method
+	 * does not have a {@code @RequestMapping} annotation.
+	 * @see #getCustomMethodCondition(Method)
+	 * @see #getCustomTypeCondition(Class)
+	 */
+	@Override
+	@Nullable
+	protected RequestMappingInfo getMappingForMethod(Method method, Class<?> handlerType) {
+		RequestMappingInfo info = createRequestMappingInfo(method);
+		if (info != null) {
+			RequestMappingInfo typeInfo = createRequestMappingInfo(handlerType);
+			if (typeInfo != null) {
+				info = typeInfo.combine(info);
+			}
+		}
+		return info;
+	}
+
+
+   /**
+	 * Delegates to {@link #createRequestMappingInfo(RequestMapping, RequestCondition)},
+	 * supplying the appropriate custom {@link RequestCondition} depending on whether
+	 * the supplied {@code annotatedElement} is a class or method.
+	 * @see #getCustomTypeCondition(Class)
+	 * @see #getCustomMethodCondition(Method)
+	 */
+	@Nullable
+	private RequestMappingInfo createRequestMappingInfo(AnnotatedElement element) {
+		RequestMapping requestMapping = AnnotatedElementUtils.findMergedAnnotation(element, RequestMapping.class);
+		RequestCondition<?> condition = (element instanceof Class ?
+				getCustomTypeCondition((Class<?>) element) : getCustomMethodCondition((Method) element));
+		return (requestMapping != null ? createRequestMappingInfo(requestMapping, condition) : null);
+	}
+```
+根据handler method创建`RequestMappingInfo`实例
+- 首先判断该 mehtod 是否含有  `RequestMpping`
+若有则直接根据该注解的内容创建`RequestMappingInfo`对象
+- 创建后判断当前method所属的bean是否也含有RequestMapping
+若含有则会根据该类上的注解创建一个`RequestMappingInfo`实例,然后再合并method上的`RequestMappingInfo`对象，最后返回合并后的对象。
+
+回看`detectHandlerMethods`，有两处调用了`getMappingForMethod`，个人觉得这里是可以优化的，在第一处判断method是否为handler时，创建的`RequestMappingInfo`对象可以保存起来，直接拿来后面使用，就少了一次创建`RequestMappingInfo`实例过程。
+然后紧接着进入`registerHandlerMehtod`
+##2.5  注册RequestMappingInfo
+###Spriing4.0.3版本
+```
+protected void registerHandlerMethod(Object handler, Method method, T mapping) {
+  //创建HandlerMethod
+  HandlerMethod newHandlerMethod = createHandlerMethod(handler, method);
+  HandlerMethod oldHandlerMethod = handlerMethods.get(mapping);
+  //检查配置是否存在歧义性
+  if (oldHandlerMethod != null && !oldHandlerMethod.equals(newHandlerMethod)) {
+      throw new IllegalStateException("Ambiguous mapping found. Cannot map '" + newHandlerMethod.getBean()
+            + "' bean method \n" + newHandlerMethod + "\nto " + mapping + ": There is already '"
+            + oldHandlerMethod.getBean() + "' bean method\n" + oldHandlerMethod + " mapped.");
+  }
+  this.handlerMethods.put(mapping, newHandlerMethod);
+  if (logger.isInfoEnabled()) {
+      logger.info("Mapped \"" + mapping + "\" onto " + newHandlerMethod);
+  }
+  //获取@RequestMapping注解的value，然后添加value->RequestMappingInfo映射记录至urlMap中
+  Set<String> patterns = getMappingPathPatterns(mapping);
+  for (String pattern : patterns) {
+      if (!getPathMatcher().isPattern(pattern)) {
+        this.urlMap.add(pattern, mapping);
+      }
+  }
+}
+```
+这里T的类型是`RequestMappingInfo`
+这个对象就是封装的具体Controller下的方法的`RequestMapping`注解的相关信息
+一个 ` RequestMapping  `注解对应一个`RequestMappingInfo`实例
+`HandlerMethod`和`RequestMappingInfo`类似，是对Controlelr下具体处理方法的封装。
+第一行,根据handler和mehthod创建`HandlerMethod`对象
+第二行通过handlerMethods map来获取当前mapping对应的`HandlerMethod`
+然后判断是否存在相同的RequestMapping配置。如下这种配置就会导致此处抛
+    `Invocation of init method failed; nested exception is java.lang.IllegalStateException: Ambiguous mapping found. Cannot map...`
+    异常
+##Spring5.0.4版本
+这一步 Spring Mvc 会保存 
+Map<RequestmappingInfo, HandlerMethod>
+Map<url, RequestmappingInfo>的映射关系
+DispatcherServlet.doDispatch()方法联系起来，doDispatch方法通过 url 在Map<url, RequestmappingInfo>中获取对应的 RequestMappingInfo 再根据request的信息和RequestMappingInfo的各个条件比较是否满足处理条件，如果不满足返回 404 如果满足通过RequestMappingInfo在Map<RequestmappingInfo, HandlerMethod>获取正真处理该请求的方法HandlerMathod.
+最后通过反射执行具体的方法（Controller 方法）。
+![](https://upload-images.jianshu.io/upload_images/4685968-c406b09344ec50c0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+进入register看看
+```java
+public void register(T mapping, Object handler, Method method) {
+			this.readWriteLock.writeLock().lock();
+			try {
+                //创建HandlerMethod
+				HandlerMethod handlerMethod = createHandlerMethod(handler, method);
+				assertUniqueMethodMapping(handlerMethod, mapping);
+
+				if (logger.isInfoEnabled()) {
+					logger.info("Mapped \"" + mapping + "\" onto " + handlerMethod);
+				}
+                //保存RequestMappingInfo 和 HandlerMathod的映射关系
+				this.mappingLookup.put(mapping, handlerMethod);
+
+				List<String> directUrls = getDirectUrls(mapping);
+				for (String url : directUrls) {
+                    //保存 Request Url 和 RequestMappingInfo 的对应关系
+					this.urlLookup.add(url, mapping);
+				}
+
+				String name = null;
+				if (getNamingStrategy() != null) {
+					name = getNamingStrategy().getName(handlerMethod, mapping);
+					addMappingName(name, handlerMethod);
+				}
+
+				CorsConfiguration corsConfig = initCorsConfiguration(handler, method, mapping);
+				if (corsConfig != null) {
+					this.corsLookup.put(handlerMethod, corsConfig);
+				}
+
+				this.registry.put(mapping, new MappingRegistration<>(mapping, handlerMethod, directUrls, name));
+			}
+			finally {
+				this.readWriteLock.writeLock().unlock();
+			}
+		}
+```
+```
+@Controller
+@RequestMapping("/AmbiguousTest")
+public class AmbiguousTestController {
+    @RequestMapping(value = "/test1")
+    @ResponseBody
+    public String test1(){
+        return "method test1";
+    }
+
+    @RequestMapping(value = "/test1")
+    @ResponseBody
+    public String test2(){
+        return "method test2";
+    }
+}
+
+```
+在SpingMVC启动（初始化）阶段检查RequestMapping配置是否有歧义
+确认配置正常以后会把该RequestMappingInfo和HandlerMethod对象添加至handlerMethods（LinkedHashMap）
+接着把RequestMapping注解的value和ReuqestMappingInfo对象添加至urlMap中
+## registerHandlerMethod方法总结
+- 检查`RequestMapping`注解配置是否有歧义
+- 构建`RequestMappingInfo`到`HandlerMethod`的映射map
+该map便是`AbstractHandlerMethodMapping`的成员变量handlerMethods。LinkedHashMap。
+- 构建`AbstractHandlerMethodMapping`的成员变量urlMap，MultiValueMap
+这个数据结构可以把它理解成Map。其中String类型的key存放的是处理方法上RequestMapping注解的value。就是具体的uri
+
+有如下Controller
+```
+@Controller
+@RequestMapping("/UrlMap")
+public class UrlMapController {
+
+    @RequestMapping(value = "/test1", method = RequestMethod.GET)
+    @ResponseBody
+    public String test1(){
+        return "method test1";
+    }
+
+    @RequestMapping(value = "/test1")
+    @ResponseBody
+    public String test2(){
+        return "method test2";
+    }
+
+    @RequestMapping(value = "/test3")
+    @ResponseBody
+    public String test3(){
+        return "method test3";
+    }
+}
+
+```
+*   初始化完成后，对应`AbstractHandlerMethodMapping`的urlMap的结构如下
+![](http://upload-images.jianshu.io/upload_images/4685968-31e763842ad02d43..jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+*   以上便是SpringMVC初始化的主要过程
+
+查找过程
+
+*   为了理解查找流程，带着一个问题来看，现有如下Controller
+
+```
+@Controller
+@RequestMapping("/LookupTest")
+public class LookupTestController {
+
+    @RequestMapping(value = "/test1", method = RequestMethod.GET)
+    @ResponseBody
+    public String test1(){
+        return "method test1";
+    }
+
+    @RequestMapping(value = "/test1", headers = "Referer=https://www.baidu.com")
+    @ResponseBody
+    public String test2(){
+        return "method test2";
+    }
+
+    @RequestMapping(value = "/test1", params = "id=1")
+    @ResponseBody
+    public String test3(){
+        return "method test3";
+    }
+
+    @RequestMapping(value = "/*")
+    @ResponseBody
+    public String test4(){
+        return "method test4";
+    }
+}
+
+```
+
+*   有如下请求
+
+<figure style="box-sizing: inherit; margin: 24px 0px;">![image](http://upload-images.jianshu.io/upload_images/4685968-b92869d6d8f452d1..jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+</figure>
+
+*   这个请求会进入哪一个方法？
+*   web容器（Tomcat、jetty）接收请求后，交给DispatcherServlet处理。FrameworkServlet调用对应请求方法（eg:get调用doGet），然后调用processRequest方法。进入processRequest方法后，一系列处理后，在line:936进入doService方法。然后在Line856进入doDispatch方法。在line:896获取当前请求的处理器handler。然后进入AbstractHandlerMethodMapping的lookupHandlerMethod方法。代码如下
+
+```
+protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
+  List<Match> matches = new ArrayList<Match>();
+   //根据uri获取直接匹配的RequestMappingInfos
+  List<T> directPathMatches = this.urlMap.get(lookupPath);
+  if (directPathMatches != null) {
+      addMatchingMappings(directPathMatches, matches, request);
+  }
+  //不存在直接匹配的RequetMappingInfo，遍历所有RequestMappingInfo
+  if (matches.isEmpty()) {
+      // No choice but to go through all mappings
+      addMatchingMappings(this.handlerMethods.keySet(), matches, request);
+  }
+   //获取最佳匹配的RequestMappingInfo对应的HandlerMethod
+  if (!matches.isEmpty()) {
+      Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));
+      Collections.sort(matches, comparator);
+
+      if (logger.isTraceEnabled()) {
+        logger.trace("Found " + matches.size() + " matching mapping(s) for [" + lookupPath + "] : " + matches);
+      }
+      //再一次检查配置的歧义性
+      Match bestMatch = matches.get(0);
+      if (matches.size() > 1) {
+        Match secondBestMatch = matches.get(1);
+        if (comparator.compare(bestMatch, secondBestMatch) == 0) {
+            Method m1 = bestMatch.handlerMethod.getMethod();
+            Method m2 = secondBestMatch.handlerMethod.getMethod();
+            throw new IllegalStateException(
+                  "Ambiguous handler methods mapped for HTTP path '" + request.getRequestURL() + "': {" +
+                  m1 + ", " + m2 + "}");
+        }
+      }
+
+      handleMatch(bestMatch.mapping, lookupPath, request);
+      return bestMatch.handlerMethod;
+  }
+  else {
+      return handleNoMatch(handlerMethods.keySet(), lookupPath, request);
+  }
+}
+
+```
+
+*   进入lookupHandlerMethod方法，其中lookupPath="/LookupTest/test1",根据lookupPath，也就是请求的uri。直接查找urlMap，获取直接匹配的RequestMappingInfo list。这里会匹配到3个RequestMappingInfo。如下
+
+<figure style="box-sizing: inherit; margin: 24px 0px;">![image](http://upload-images.jianshu.io/upload_images/4685968-77d93dc665b733ce..jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+</figure>
+
+*   然后进入addMatchingMappings方法
+
+```
+private void addMatchingMappings(Collection<T> mappings, List<Match> matches, HttpServletRequest request) {
+  for (T mapping : mappings) {
+      T match = getMatchingMapping(mapping, request);
+      if (match != null) {
+        matches.add(new Match(match, handlerMethods.get(mapping)));
+      }
+  }
+}
+
+```
+
+*   这个方法的职责是遍历当前请求的uri和mappings中的RequestMappingInfo能否匹配上，如果能匹配上，创建一个相同的RequestMappingInfo对象。再获取RequestMappingInfo对应的handlerMethod。然后创建一个Match对象添加至matches list中。执行完addMatchingMappings方法，回到lookupHandlerMethod。这时候matches还有3个能匹配上的RequestMappingInfo对象。接下来的处理便是对matchers列表进行排序，然后获取列表的第一个元素作为最佳匹配。返回Match的HandlerMethod。这里进入RequestMappingInfo的compareTo方法，看一下具体的排序逻辑。代码如下
+
+```
+public int compareTo(RequestMappingInfo other, HttpServletRequest request) {
+  int result = patternsCondition.compareTo(other.getPatternsCondition(), request);
+  if (result != 0) {
+      return result;
+  }
+  result = paramsCondition.compareTo(other.getParamsCondition(), request);
+  if (result != 0) {
+      return result;
+  }
+  result = headersCondition.compareTo(other.getHeadersCondition(), request);
+  if (result != 0) {
+      return result;
+  }
+  result = consumesCondition.compareTo(other.getConsumesCondition(), request);
+  if (result != 0) {
+      return result;
+  }
+  result = producesCondition.compareTo(other.getProducesCondition(), request);
+  if (result != 0) {
+      return result;
+  }
+  result = methodsCondition.compareTo(other.getMethodsCondition(), request);
+  if (result != 0) {
+      return result;
+  }
+  result = customConditionHolder.compareTo(other.customConditionHolder, request);
+  if (result != 0) {
+      return result;
+  }
+  return 0;
+}
+
+```
+
+*   代码里可以看出，匹配的先后顺序是value>params>headers>consumes>produces>methods>custom，看到这里，前面的问题就能轻易得出答案了。在value相同的情况，params更能先匹配。所以那个请求会进入test3()方法。再回到lookupHandlerMethod，在找到HandlerMethod。SpringMVC还会这里再一次检查配置的歧义性，这里检查的原理是通过比较匹配度最高的两个RequestMappingInfo进行比较。此处可能会有疑问在初始化SpringMVC有检查配置的歧义性，这里为什么还会检查一次。假如现在Controller中有如下两个方法，以下配置是能通过初始化歧义性检查的。
+
+```
+@RequestMapping(value = "/test5", method = {RequestMethod.GET, RequestMethod.POST})
+@ResponseBody
+public String test5(){
+    return "method test5";
+}
+@RequestMapping(value = "/test5", method = {RequestMethod.GET, RequestMethod.DELETE})
+@ResponseBody
+public String test6(){
+    return "method test6";
+}
+
+```
+
+*   现在执行 http://localhost:8080/SpringMVC-Demo/LookupTest/test5 请求，便会在lookupHandlerMethod方法中抛
+    `java.lang.IllegalStateException: Ambiguous handler methods mapped for HTTP path 'http://localhost:8080/SpringMVC-Demo/LookupTest/test5'`异常。这里抛该异常是因为RequestMethodsRequestCondition的compareTo方法是比较的method数。代码如下
+
+```
+public int compareTo(RequestMethodsRequestCondition other, HttpServletRequest request) {
+  return other.methods.size() - this.methods.size();
+}
+
+```
+
+*   什么时候匹配通配符？当通过urlMap获取不到直接匹配value的RequestMappingInfo时才会走通配符匹配进入addMatchingMappings方法。
+
+#总结
+Spring Mvc的初始化过程比较清晰，整个过程Spring 提供的方法很多都是 protected修饰的这样我们可以通过继承灵活的定制我们的需求。
+回顾一下整个初始化过程：
+
+
+通过Spring容器对 InitalizingBean.afterPropertiesSet()方法的支持开始初始化流程。
+
+
+获取容器中的所有 bean 通过 isHandler()方法区分是否需要处理。
+
+
+通过方法上的@RequestMapping注解创建 RequestMappingInfo
+
+
+注册、保存保存 Map<RequestmappingInfo, HandlerMethod>、Map<url, RequestmappingInfo>的映射关系方便后续调用和Request匹配。
+
diff --git "a/Java/Spring/SpringMVC\345\205\250\345\261\200\345\274\202\345\270\270.md" "b/Java/Spring/SpringMVC\345\205\250\345\261\200\345\274\202\345\270\270.md"
new file mode 100644
index 0000000000..531735702d
--- /dev/null
+++ "b/Java/Spring/SpringMVC\345\205\250\345\261\200\345\274\202\345\270\270.md"
@@ -0,0 +1,92 @@
+#目录
+![](http://upload-images.jianshu.io/upload_images/4685968-34f845d539264d16.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](http://upload-images.jianshu.io/upload_images/4685968-2dcb1f1680786bc9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#无SpringMVC全局异常时的流程图
+![](http://upload-images.jianshu.io/upload_images/4685968-11e86660294cec5c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#SpringMVC全局异常流程图
+![其实是一个ModelAndView对象](http://upload-images.jianshu.io/upload_images/4685968-29cfa37601caf919.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+#配置文件
+```java
+applicationcontext.xml
+
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
+       xmlns:tx="http://www.springframework.org/schema/tx" xmlns:jdbc="http://www.springframework.org/schema/jdbc"
+       xmlns:context="http://www.springframework.org/schema/context"
+       xmlns:task="http://www.springframework.org/schema/task"
+       xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
+     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
+     http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
+     http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task.xsd">
+
+    <context:component-scan base-package="com.mmall">
+        <!-- 扫描controller的职责交给dispatcher-servlet.xml,所以排除 -->
+        <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller" />
+    </context:component-scan>
+
+    <aop:aspectj-autoproxy/>
+
+    <!-- spring schedule -->
+    <context:property-placeholder location="classpath:datasource.properties"/>
+    <task:annotation-driven/>
+
+    <import resource="applicationContext-spring-session.xml"/>
+    <import resource="applicationContext-datasource.xml"/>
+
+</beans>
+```
+
+```java
+dispacher-servlet.xml
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
+       xmlns:context="http://www.springframework.org/schema/context"
+       xmlns:mvc="http://www.springframework.org/schema/mvc" xmlns:aop="http://www.springframework.org/schema/aop"
+       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
+	http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
+	http://www.springframework.org/schema/mvc
+	http://www.springframework.org/schema/mvc/spring-mvc.xsd">
+
+    <!-- springmvc扫描包指定到controller，防止重复扫描 -->
+    <context:component-scan base-package="com.mmall.controller" annotation-config="true" use-default-filters="false">
+        <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
+    </context:component-scan>
+
+    <mvc:annotation-driven>
+        <mvc:message-converters>
+            <bean class="org.springframework.http.converter.StringHttpMessageConverter">
+                <property name="supportedMediaTypes">
+                    <list>
+                        <value>text/plain;charset=UTF-8</value>
+                        <value>text/html;charset=UTF-8</value>
+                    </list>
+                </property>
+            </bean>
+            <bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter">
+                <property name="supportedMediaTypes">
+                    <list>
+                        <value>application/json;charset=UTF-8</value>
+                    </list>
+                </property>
+            </bean>
+        </mvc:message-converters>
+    </mvc:annotation-driven>
+    
+    <mvc:interceptors>
+        <!-- 定义在这里的，所有的都会拦截-->
+        <mvc:interceptor>
+            <!--manage/a.do  /manage/*-->
+            <!--manage/b.do  /manage/*-->
+            <!--manage/product/save.do /manage/**-->
+            <!--manage/order/detail.do /manage/**-->
+            <mvc:mapping path="/manage/**"/>
+            <!--<mvc:exclude-mapping path="/manage/user/login.do"/>-->
+            <bean class="com.mmall.controller.common.interceptor.AuthorityInterceptor" />
+        </mvc:interceptor>
+
+    </mvc:interceptors>
+</beans>
+
+```
diff --git "a/Java/Spring/SpringMVC\346\225\260\346\215\256\347\273\221\345\256\232.md" "b/Java/Spring/SpringMVC\346\225\260\346\215\256\347\273\221\345\256\232.md"
new file mode 100644
index 0000000000..e32f92e695
--- /dev/null
+++ "b/Java/Spring/SpringMVC\346\225\260\346\215\256\347\273\221\345\256\232.md"
@@ -0,0 +1,723 @@
+#定义
+百度百科定义:
+    简单绑定是将一个用户界面元素（控件）的属性绑定到一个类型（对象）实例上的某个属性的方法。
+例如，如果一个开发者有一个Customer类型的实例，那么他就可以把Customer的“Name”属性绑定到一个TextBox的“Text”属性上。“绑定”了这2个属性之后，对TextBox的Text属性的更改将“传播”到Customer的Name属性，而对Customer的Name属性的更改同样会“传播”到TextBox的Text属性。
+
+# 支持的数据绑定方式
+SpringMVC的各种参数包括对象java对象,集合,Map以及基本数据类型的绑定方式
+## 1.基本类型,包装类型的绑定
+
+###     1.1基本数据类型的绑定
+
+        基本类型的数据绑定需要注意的是:后台请求方法中声明的参数前台是必须传的,其次是类型必须相同
+
+controller类:
+
+```
+@Controller
+public class DataBind {
+//    http://localhost:8080/dataBind/test.do?age=11
+      @RequestMapping("/test")
+    public String  test(int age){
+
+        System.out.println(age);
+
+    return "success";
+        }
+}
+```
+
+ form表单
+
+```
+<form action="test.do" method="post">  
+   <input name="age" value="11" type="text"/>  
+   ......  
+</form>  
+```
+
+注意:
+           1.参数名一致:表单中input的name值和Controller的参数变量名保持一致 ,就能完成基本数据类型的数据绑定.   
+
+            2.参数类型一致:如果在后台参数定义的是int类型,那么前台传的值也只能是int类型否则springMVC会进行拦截报一个400参数错误(数据转换的异常)
+
+            3.参数不能为空:从jsp提交过来的数据为null或者""的话，会出现500异常。也就是说，必须保证表单传递过来的数据不能为null或"".
+
+对于以上问题可以采用@RequestParam注解来解决
+
+```
+@Controller
+public class DataBind {
+    //
+    @RequestMapping("/test")
+    public String  test(@RequestParam(value ="age" ,required = false) int userAge){
+
+        System.out.println(userAge);
+
+    return "success";
+        }
+}
+```
+
+  @RequestParam(value ="name" ,required = false) value值是参数别名与表单一致,required 默认值true为必传.
+
+####     1.2包装类型的绑定
+
+        controller类:
+
+```
+ @RequestMapping("/test3")
+    public  String test3(Integer age){
+
+        System.out.println(age);
+
+    }
+```
+
+        form表单:
+
+```
+<form action="test.do" method="post">  
+   <input name="age" value="10" type="text"/>  
+   ......  
+</form> 
+```
+
+和基本数据类型基本一样，不同之处在于，JSP表单传递过来的数据可以为null或""，以上面代码为例，如果jsp中num为""或者表单中无age这个input，那么，Controller方法参数中的num值则为null。
+
+### 2.简单对象,复杂对象的绑定
+
+####     2.1简单对象&多层对象
+
+   1\. 简单POJO类对象:
+
+```
+public class User {  
+
+    private String firstName;  
+
+    private String lastName;  
+
+   //省略get&set ...  
+
+} 
+```
+
+    controller类
+
+```
+  @RequestMapping("/test4")
+    public  String test4(User user){
+
+        System.out.println(user);
+        return "success";
+    }
+```
+
+    form表单
+
+```
+<form action="test.do" method="post">  
+   <input name="firstName" value="张" type="text"/>  
+   <input name="lastName" value="三" type="text"/>  
+   ......  
+</form>  
+```
+
+> 简单对象：请求方式的参数Key即为对象属性名，不用加“对象名.”的前缀
+
+2.多层对象  
+
+POJO对象
+
+```
+public class ContactInfo {  
+
+    private String tel;  
+
+    private String address;  
+
+    //。。。省略get&set  
+
+}  
+
+public class User {  
+
+    private String firstName;  
+
+    private String lastName;  
+
+    private ContactInfo contactInfo;  
+
+   // 。。。 省略get&set 
+
+```
+
+controller类和简单对象没有什么区别,参数类型都是User(pojo类型对象)
+
+form表单
+
+```
+<form action="<%=basePath%>test5.do" method="get">
+    姓:<input name="firstName"/>
+    名:<input name="lastName"/>
+    地址:<input name="contactInfo.address"/>
+...
+</form>
+```
+
+> 多层级对象：第二级以上对象必须加“对象名.”的前缀。
+
+####     2.2.同属性的多对象
+
+<pre class="hljs css" style="box-sizing: inherit; -webkit-tap-highlight-color: transparent; user-select: text !important; display: block; overflow-x: auto; padding: 2px; background: rgb(63, 63, 63); color: rgb(220, 220, 220); border-radius: 3px; line-height: 1.4; word-wrap: normal; font-size: 13px; font-family: Menlo, Monaco, Consolas, &quot;Courier New&quot;, monospace; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">同属性的多对象 在control中声明@initBinder的WebDataBinder的前缀</pre>
+
+当两个对象含有相同属性时,为了精确的匹配绑定一种方法是通过命名的规范去规避,另一中解决办法使用@InitBinder对请求参数加前缀
+
+java代码
+
+```
+@Controller  
+public class dataBind{  
+    @InitBinder("teacher")  
+    public void initBinder1(WebDataBinder binder){  
+        binder.setFieldDefaultPrefix("teacher.");  
+    }  
+    @InitBinder("student")  
+    public void initBinder2(WebDataBinder binder){  
+        binder.setFieldDefaultPrefix("student.");  
+    }      
+
+    //URL映射  
+    @RequestMapping(value="/save", method = RequestMethod.GET)  
+    public ModelAndView save(Teacher teacher,Student student) {  
+        System.out.println(teacher.getName()+" "+student.getName());  
+        return null;  
+    }  
+```
+
+注意:当save的参数名与对象名不一致(即参数名不为类名的小写)时,需要在参数前加@ModelAttribute()注解,同时保证@InitBinder的value值与@ModelAttribute的value值一致,如果不指定value值，那么所有的都将使用。
+
+这种方式的缺点：
+
+1、不支持Path variable的绑定，如/test1/{user1.id}这种情况的绑定；
+
+2、不支持如集合/数组的绑定；
+
+```
+ @InitBinder("user1")
+    public  void initUser(WebDataBinder binder){
+        binder.setFieldDefaultPrefix("user.");
+    }
+    @InitBinder("student1")
+    public  void initStudent(WebDataBinder binder){
+        binder.setFieldDefaultPrefix("student.");
+    }
+  @RequestMapping("/test6")
+    public  String test6(@ModelAttribute("student1")Student a,@ModelAttribute("user1")User b){
+        System.out.println(a);
+        System.out.println(b);
+
+    return "success";
+    }
+```
+
+### 3.List,Set,Map类型的数据绑定
+
+####     3.1 List类型的数据绑定
+
+springMVC 不支持list类型的直接转换，需包装成object。
+
+```
+public class User {  
+
+    private String firstName;  
+
+    private String lastName;  
+
+    // 。。。 省略get&set 
+
+}  
+
+       public class UserListForm {  
+
+    private List<User> users;  
+
+    // 。。。 省略get&set
+
+}  
+
+```
+
+```
+@RequestMapping("test")  
+public void test(UserListForm userForm) {  
+    for (User user : userForm.getUsers()) {  
+        System.out.println(user.getFirstName() + " - " + user.getLastName());  
+    }  
+} 
+```
+
+form表单
+
+```
+<form action="test.do" method="post">  
+   <table>  
+      <thead>  
+         <tr>  
+            <th>First Name</th>  
+            <th>Last Name</th>  
+         </tr>  
+      </thead>  
+      <tfoot>  
+         <tr>  
+            <td colspan="2"><input type="submit" value="Save" /></td>  
+         </tr>  
+      </tfoot>  
+      <tbody>  
+         <tr>  
+            <td><input name="users[0].firstName" value="aaa" /></td>  
+            <td><input name="users[0].lastName" value="bbb" /></td>  
+         </tr>  
+         <tr>  
+            <td><input name="users[1].firstName" value="ccc" /></td>  
+            <td><input name="users[1].lastName" value="ddd" /></td>  
+         </tr>  
+         <tr>  
+            <td><input name="users[2].firstName" value="eee" /></td>  
+            <td><input name="users[2].lastName" value="fff" /></td>  
+         </tr>  
+      </tbody>  
+   </table>  
+</form>  
+```
+
+这里的UserListForm对象里面的属性被定义成List，而不是普通自定义对象。所以，在JSP中需要指定List的下标。值得一提的是，Spring会创建一个以最大下标值为size的List对象，所以，如果JSP表单中有动态添加行、删除行的情况，就需要特别注意，譬如一个表格，用户在使用过程中经过多次删除行、增加行的操作之后，下标值就会与实际大小不一致，这时候，List中的对象，只有在jsp表单中对应有下标的那些才会有值，否则会为null.
+
+<pre class="hljs cpp" style="box-sizing: inherit; -webkit-tap-highlight-color: transparent; user-select: text !important; display: block; overflow-x: auto; padding: 2px; background: rgb(63, 63, 63); color: rgb(220, 220, 220); border-radius: 3px; line-height: 1.4; word-wrap: normal; font-size: 13px; font-family: Menlo, Monaco, Consolas, &quot;Courier New&quot;, monospace; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">list集合绑定的时候 下标最好是连续的 否则可能造成后台资源浪费</pre>
+
+####     3.2 Set类型的数据绑定
+
+Set和List类似，也需要绑定在对象上，而不能直接写在Controller方法的参数中。但是，绑定Set数据时，必须先在Set对象中add相应的数量的,即Set绑定时需初始化
+
+```
+public class User {  
+
+    private String firstName;  
+
+    private String lastName;  
+//...省略set&get  
+
+}  
+
+public class UserSetForm {  
+
+    private Set<User> users = new HashSet<User>();  
+
+    public UserSetForm(){  
+        users.add(new User());  
+        users.add(new User());  
+        users.add(new User());  
+    }  
+
+   //...省略set&get  
+
+} 
+```
+
+要使用Set的排重功能必须在对象中覆写hashcode和equals方法,至于为什么要重写hashcode和equals方法可参见:[https://my.oschina.net/u/3406827/blog/897561](https://my.oschina.net/u/3406827/blog/897561)
+
+```
+<form action="test.do" method="post">  
+   <table>  
+      <thead>  
+         <tr>  
+            <th>First Name</th>  
+            <th>Last Name</th>  
+         </tr>  
+      </thead>  
+      <tfoot>  
+         <tr>  
+            <td colspan="2"><input type="submit" value="Save" /></td>  
+         </tr>  
+      </tfoot>  
+      <tbody>  
+         <tr>  
+            <td><input name="users[0].firstName" value="aaa" /></td>  
+            <td><input name="users[0].lastName" value="bbb" /></td>  
+         </tr>  
+         <tr>  
+            <td><input name="users[1].firstName" value="ccc" /></td>  
+            <td><input name="users[1].lastName" value="ddd" /></td>  
+         </tr>  
+         <tr>  
+            <td><input name="users[2].firstName" value="eee" /></td>  
+            <td><input name="users[2].lastName" value="fff" /></td>  
+         </tr>  
+      </tbody>  
+   </table>  
+</form>  
+```
+
+    基本和List绑定类似。
+要特别提醒的是，如果最大下标值大于Set的size，则会抛出org.springframework.beans.InvalidPropertyException异常
+
+spingMVC在对集合进行绑定时,优先选择List
+
+#### 3.3 Map类型的数据绑定
+
+Map类型的数据绑定也能用在对象的去重,因为Map的key值是唯一的.
+
+```
+public class User {  
+
+    private String firstName;  
+
+    private String lastName;  
+
+    。。。  
+
+}  
+
+public class UserMapForm {  
+
+    private Map<String, User> users;  
+
+    。。。  
+
+}  
+
+@RequestMapping("test")  
+public void test(UserMapForm userForm) {  
+    for (Map.Entry<String, User> entry : userForm.getUsers().entrySet()) {  
+        System.out.println(entry.getKey() + ": " + entry.getValue().getFirstName() + " - " +  
+                                 entry.getValue().getLastName());  
+    }  
+}  
+
+```
+
+```
+<form action="test.do" method="post">  
+   <table>  
+      <thead>  
+         <tr>  
+            <th>First Name</th>  
+            <th>Last Name</th>  
+         </tr>  
+      </thead>  
+      <tfoot>  
+         <tr>  
+            <td colspan="2"><input type="submit" value="Save" /></td>  
+         </tr>  
+      </tfoot>  
+      <tbody>  
+         <tr>  
+            <td><input name="users['x'].firstName" value="aaa" /></td>  
+            <td><input name="users['x'].lastName" value="bbb" /></td>  
+         </tr>  
+         <tr>  
+            <td><input name="users['y'].firstName" value="ccc" /></td>  
+            <td><input name="users['y'].lastName" value="ddd" /></td>  
+         </tr>  
+         <tr>  
+            <td><input name="users['z'].firstName" value="eee" /></td>  
+            <td><input name="users['z'].lastName" value="fff" /></td>  
+         </tr>  
+      </tbody>  
+   </table>  
+</form>  
+```
+
+x即为Map的key,firstName即为User对象的属相
+
+### 4.Json,Xml类型的数据绑定
+
+####     4.1Json类型的数据绑定
+
+@RequestBody把传过来的Json数据反序列化绑定到控制器参数上
+
+对于JOSN类型的参数绑定一般应用的场景是在使用AJax请求.而在SpringMVC环境中,@RequestBody接收的是一个Json对象的字符串，而不是一个Json对象.可以用 JSON.stringify(data)的方式就能将对象变成字符串。同时ajax请求的时候也要指定dataType: "json",contentType:"application/json" 这样就可以轻易的将一个对象或者List传到Java端，使用@RequestBody即可绑定对象或者List.
+
+JavaScript 代码：
+
+```
+<script type="text/javascript">  
+    $(document).ready(function(){  
+        var saveDataAry=[];  
+        var data1={"userName":"test","address":"gz"};  
+        var data2={"userName":"ququ","address":"gr"};  
+        saveDataAry.push(data1);  
+        saveDataAry.push(data2);         
+        $.ajax({ 
+            type:"POST", 
+            url:"user/saveUser", 
+            dataType:"json",      
+            contentType:"application/json",               
+            data:JSON.stringify(saveData), 
+            success:function(data){ 
+               //...tosomething                        
+            } 
+         }); 
+    });  
+</script> 
+```
+
+    controller方法:
+
+```
+ @RequestMapping(value = "test", method = {RequestMethod.POST }}) 
+    @ResponseBody  
+    public void saveUser(@RequestBody List<User> users) { 
+         userService.batchSave(users); 
+    }
+```
+
+#### 4.2Xml类型的数据绑定
+
+1.SpingMVC对象Xml类型的数据绑定需要spring-oxm jar包支持.同样也是@RequestBody把传过来的Xml数据反序列化绑定到控制器参数上
+
+2.xml 数据绑定：必须在实体类里面加注解@XmlRootElement(根节点),在属性上添加XmlElement (子节点)ex:@XmlElement(name="age"):此时就会将xml 里面对应的age数据添加到实体类中的age属性中去。
+
+model对象的处理:
+
+```
+@XmlRootElement(name="admin")//根节点别名
+public class Admin {
+    private  String name;
+    private  String age;
+    @XmlElement(name="name")//在get方法在夹@XmlElement 子节点别名
+    public String getName() {
+        return name;
+    }
+
+    public void setName(String name) {
+        this.name = name;
+    }
+    @XmlElement(name ="age")
+    public String getAge() {
+
+        return age;
+    }
+
+    public void setAge(String age) {
+        this.age = age;
+    }
+}
+```
+
+xml数据
+
+```
+<? version="1.0" encoding="utf-8" ?>
+<admin>
+ <name>张三</name>
+ <age>22</age>
+</admin>
+```
+
+### 5.自定义类型转化器(PropertyEditor Formatter Converter)
+
+#### 5.1PropertyEditor的应用
+
+先来看Sun提供的PropertyEditor属性编辑器
+
+![image](http://upload-images.jianshu.io/upload_images/4685968-acb27bc9958be834.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+PropertyEditor是java提供的属性编辑器接口,PropertyEditorSupport是直接实现类,通常都是继承该实现类并重写setAsText(String) 方法,实现从String类型到自定类型的装换.
+
+spring中也有继承了PropertyEditorSupport并重写了setAsText的自定义的属相编辑器,都在spring-beans包下的org.springframework.beans.propertyeditors包里:
+
+![image](http://upload-images.jianshu.io/upload_images/4685968-da25684b507f915f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+在SpringMVC中主要是WebDataBinder实现对数据的转换
+
+![image](http://upload-images.jianshu.io/upload_images/4685968-357fb9dbde628552.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+PropertyEditorRegistyr封装方法来给JavaBean注册对应的属性编辑器。
+
+![image](http://upload-images.jianshu.io/upload_images/4685968-3cc35e31f16bf866.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+实现方式代码;
+
+```
+    /**
+     * 在controller层中加入一段数据绑定代码
+     * @param webDataBinder
+     */
+    @InitBinder
+    public void initBinder(WebDataBinder webDataBinder) throws Exception{
+        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd hh:mm");
+        simpleDateFormat.setLenient(false);
+        webDataBinder.registerCustomEditor(Date.class , new CustomDateEditor(simpleDateFormat , true));
+//CustomDateEditor是spring提供的继承PropertyEditorSupport的类,也可以换成自定义的MyCustomPropertyEditor类
+    }
+   //备注：自定义类型转换器必须实现PropertyEditor接口或者继承PropertyEditorSupport类
+MyCustomPropertyEditor extends propertyEditorSupport{
+     public void setAsText(String text){
+         SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy -MM-dd hh:mm");
+        Date date = simpleDateFormat.parse(text);
+        this.setValue(date);
+     }
+     public String getAsTest(){
+      Date date = (Date)this.getValue(); 
+      return this.dateFormat.format(date);
+     }
+}
+```
+
+这种使用Property属性编辑器的方法需要在controller层加一段数据绑定的代码,不够灵活,不具有全局性
+
+#### 5.2Formatter的应用
+
+要使用全局的数据转换器,在Spring 3.0后可以使用Converter和Formatter，都是用来做数据转换的
+
+Formatter继承了Printer和Parser接口
+
+```
+public interface Formatter<T> extends Printer<T>, Parser<T> {  
+
+}
+```
+
+Printer用来打印转换后的对象 
+
+```
+public interface Printer<T> {  
+
+    /** 
+     * Print the object of type T for display. 
+     * @param object the instance to print 
+     * @param locale the current user locale 
+     * @return the printed text string 
+     */  
+    String print(T object, Locale locale);  
+
+}  
+```
+
+，Parser用来从String类型转换为指定类型值
+
+```
+public interface Parser<T> {  
+
+    /** 
+     * Parse a text String to produce a T. 
+     * @param text the text string 
+     * @param locale the current user locale 
+     * @return an instance of T 
+     * @throws ParseException when a parse exception occurs in a java.text parsing library 
+     * @throws IllegalArgumentException when a parse exception occurs 
+     */  
+    T parse(String text, Locale locale) throws ParseException;  
+
+}  
+```
+
+从方法上，可以看分出Formatter是从String类型转换为任意目标类型<T>，有点类似PropertyEditor
+
+代码实现:
+
+```
+public class MyDateFormatter implements Formatter<Date> {
+    @Override
+    public String print(Date object, Locale locale) {
+        return null;
+    }
+    //只需重写parse方法 实现类型转换为目标类型<T>
+    @Override
+    public Date parse(String text, Locale locale) throws ParseException {
+
+        return new SimpleDateFormat("yyyy-MM-dd").parse(text);
+    }
+}
+```
+
+在spring-mvc.xml的配置文件中需要注册自定义的转换器实现全局转换
+
+```
+ <mvc:annotation-driven conversion-service="MyDateFormatter"/>
+    <bean id="MyDateFormatter"
+class="org.springframework.format.support.FormattingConversionServiceFactoryBean">
+    <property name="formatters">
+        <set>
+            <bean class="com.chuyu.ssm.controller.MyDateFormatter"/>
+        </set>
+    </property>
+    </bean>
+```
+
+虽然这个方法可以实现全局的数据转换,但是支持的类型也只能是从String类型转换为任意目标类型<T>.
+
+#### 5.3Converter的应用
+
+```
+public interface Converter<S, T> {  
+
+    /** 
+     * Convert the source object of type {@code S} to target type {@code T}. 
+     * @param source the source object to convert, which must be an instance of {@code S} (never {@code null}) 
+     * @return the converted object, which must be an instance of {@code T} (potentially {@code null}) 
+     * @throws IllegalArgumentException if the source cannot be converted to the desired target type 
+     */  
+    T convert(S source);  
+
+} 
+```
+
+从源码可以看出去,Converter接口可以从任意源类型，转换为任意目标类型
+
+代码实现:
+
+```
+package com.chuyu.ssm.controller;
+
+import java.text.ParseException;
+import java.text.SimpleDateFormat;
+import java.util.Date;
+
+import org.springframework.core.convert.converter.Converter;
+/**
+ * 全局类型转换器
+ * @author acer
+ *
+ */
+public class DateConvert  implements Converter<String, Date>{
+    @Override
+    public Date convert(String text) {
+        Date date = null;
+        try {
+            if(text.contains("-")){
+                SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd");
+                date = sf.parse(text);
+            }else {
+                SimpleDateFormat sf = new SimpleDateFormat("dd/MM/yyyy");
+                date = sf.parse(text);
+            }
+
+        } catch (ParseException e) {
+            e.printStackTrace();
+        }
+        return date;
+    }
+
+}
+```
+
+类型转换器需要在配置文件中配置:
+
+```
+<!--开启注解  -->    
+<mvc:annotation-driven conversion-service="MyDataConverterService" />
+
+<!--类型转换器工厂  -->
+
+<bean id="MyDataConverterService"
+      class="org.springframework.context.support.FormattingConversionServiceFactoryBean">
+    <property name="converters">
+        <list>
+            <bean class="com.cy.springannotation.controller.DateConvert" />
+        </list>
+    </property>
+</bean>
+```
diff --git "a/Java/Spring/SpringMVC\347\232\204@ResponseBody\346\263\250\350\247\243\350\257\264\346\230\216.md" "b/Java/Spring/SpringMVC\347\232\204@ResponseBody\346\263\250\350\247\243\350\257\264\346\230\216.md"
new file mode 100644
index 0000000000..5bc3c4cb94
--- /dev/null
+++ "b/Java/Spring/SpringMVC\347\232\204@ResponseBody\346\263\250\350\247\243\350\257\264\346\230\216.md"
@@ -0,0 +1,12 @@
+***@ResponseBody*** 注解与 ***@RequestBody*** 注解类似。 ***@ResponseBody*** 注解可被应用于方法上，标志该方法的返回值将被直接写回到HTTP响应体(Response)中去（而不会被放置到Model中或者被解析为一个视图名）。举个栗子：
+```
+@RequestMapping(path = "/something", method = RequestMethod.PUT)
+@ResponseBody
+public String helloWorld() {
+   return "Hello World"
+}
+```
+上面的代码结果是文本 Hello World 将被写入HTTP的响应流中。
+
+> 注:Spring MVC的 ***@ResponseBody*** 
+> 方法是有风险的，因为它会根据客户的请求——包括URL的路径后缀，来渲染不同的内容类型。因此，禁用后缀模式匹配或者禁用仅为内容协商开启的路径文件后缀名携带，都是防范RFD攻击的有效方式。
diff --git "a/Java/Spring/Spring\345\255\246\344\271\240\344\270\216\351\235\242\350\257\225.md" "b/Java/Spring/Spring\345\255\246\344\271\240\344\270\216\351\235\242\350\257\225.md"
new file mode 100755
index 0000000000..732717aa3a
--- /dev/null
+++ "b/Java/Spring/Spring\345\255\246\344\271\240\344\270\216\351\235\242\350\257\225.md"
@@ -0,0 +1,128 @@
+
+
+# Spring相关教程/资料：
+
+> ## 官网相关
+
+ [Spring官网](https://spring.io/)
+
+[Spring系列主要项目](https://spring.io/projects)
+
+从配置到安全性，Web应用到大数据 - 无论您的应用程序的基础架构需求如何，都有一个Spring Project来帮助您构建它。 从小处着手，根据需要使用 - Spring是通过设计模块化的。
+
+ [Spring官网指南](https://spring.io/guides)
+
+无论您在构建什么，这些指南都旨在尽可能快地提高您的工作效率 - 使用Spring团队推荐的最新Spring项目发布和技术。
+
+ [Spring官方文档翻译（1~6章）](https://blog.csdn.net/tangtong1/article/details/51326887)
+
+> ##   系统学习教程：
+
+### 文档：
+
+ [极客学院Spring Wiki](http://wiki.jikexueyuan.com/project/spring/transaction-management.html)
+
+ [Spring W3Cschool教程 ](https://www.w3cschool.cn/wkspring/f6pk1ic8.html)
+
+### 视频：
+
+[网易云课堂——58集精通java教程Spring框架开发](http://study.163.com/course/courseMain.htm?courseId=1004475015#/courseDetail?tab=1&35)
+
+ [慕课网相关视频](https://www.imooc.com/)
+
+**黑马视频（非常推荐）：**
+微信公众号：“**Java面试通关手册**”后台回复“**资源分享第一波**”免费领取。
+
+> ## 一些常用的东西
+
+[Spring Framework 4.3.17.RELEASE API](https://docs.spring.io/spring/docs/4.3.17.RELEASE/javadoc-api/)
+
+默认浏览器打开，当需要查某个类的作用的时候，可以在浏览器通过ctrl+f搜索。
+
+
+# 面试必备知识点
+
+
+> ## SpringAOP,IOC实现原理
+
+AOP实现原理、动态代理和静态代理、Spring IOC的初始化过程、IOC原理、自己实现怎么实现一个IOC容器？这些东西都是经常会被问到的。
+
+[自己动手实现的 Spring IOC 和 AOP - 上篇](http://www.coolblog.xyz/2018/01/18/自己动手实现的-Spring-IOC-和-AOP-上篇/)
+
+[自己动手实现的 Spring IOC 和 AOP - 下篇](http://www.coolblog.xyz/2018/01/18/自己动手实现的-Spring-IOC-和-AOP-下篇/)
+
+### AOP：
+
+AOP思想的实现一般都是基于 **代理模式** ，在JAVA中一般采用JDK动态代理模式，但是我们都知道，**JDK动态代理模式只能代理接口而不能代理类**。因此，Spring AOP 会这样子来进行切换，因为Spring AOP 同时支持 CGLIB、ASPECTJ、JDK动态代理。
+
+- 如果目标对象的实现类实现了接口，Spring AOP 将会采用 JDK 动态代理来生成 AOP 代理类；
+- 如果目标对象的实现类没有实现接口，Spring AOP 将会采用 CGLIB 来生成 AOP 代理类——不过这个选择过程对开发者完全透明、开发者也无需关心。
+
+
+
+[※静态代理、JDK动态代理、CGLIB动态代理讲解](http://www.cnblogs.com/puyangsky/p/6218925.html)
+
+我们知道AOP思想的实现一般都是基于 **代理模式** ，所以在看下面的文章之前建议先了解一下静态代理以及JDK动态代理、CGLIB动态代理的实现方式。
+
+[Spring AOP 入门](https://juejin.im/post/5aa7818af265da23844040c6)
+
+带你入门的一篇文章。这篇文章主要介绍了AOP中的基本概念：5种类型的通知（Before，After，After-returning，After-throwing，Around）；Spring中对AOP的支持：AOP思想的实现一般都是基于代理模式，在JAVA中一般采用JDK动态代理模式，Spring AOP 同时支持 CGLIB、ASPECTJ、JDK动态代理，
+
+[※Spring AOP 基于AspectJ注解如何实现AOP](https://juejin.im/post/5a55af9e518825734d14813f)
+
+
+**AspectJ是一个AOP框架，它能够对java代码进行AOP编译（一般在编译期进行），让java代码具有AspectJ的AOP功能（当然需要特殊的编译器）**，可以这样说AspectJ是目前实现AOP框架中最成熟，功能最丰富的语言，更幸运的是，AspectJ与java程序完全兼容，几乎是无缝关联，因此对于有java编程基础的工程师，上手和使用都非常容易
+
+Spring注意到AspectJ在AOP的实现方式上依赖于特殊编译器(ajc编译器)，因此Spring很机智回避了这点，转向采用动态代理技术的实现原理来构建Spring AOP的内部机制（动态织入），这是与AspectJ（静态织入）最根本的区别。
+
+
+[※探秘Spring AOP（慕课网视频，很不错）](https://www.imooc.com/learn/869)
+
+慕课网视频，讲解的很不错，详细且深入
+
+
+[spring源码剖析（六）AOP实现原理剖析](https://blog.csdn.net/fighterandknight/article/details/51209822)
+
+通过源码分析Spring AOP的原理
+
+### IOC：
+
+Spring IOC的初始化过程：
+![Spring IOC的初始化过程](https://user-gold-cdn.xitu.io/2018/5/22/16387903ee72c831?w=709&h=56&f=png&s=4673)
+
+[[Spring框架]Spring IOC的原理及详解。](https://www.cnblogs.com/wang-meng/p/5597490.html)
+
+[Spring IOC核心源码学习](https://yikun.github.io/2015/05/29/Spring-IOC核心源码学习/)
+
+比较简短，推荐阅读。
+
+[Spring IOC 容器源码分析](https://javadoop.com/post/spring-ioc)
+
+强烈推荐，内容详尽，而且便于阅读。
+
+> ## Spring事务管理
+
+[可能是最漂亮的Spring事务管理详解](https://juejin.im/post/5b00c52ef265da0b95276091)
+
+[Spring编程式和声明式事务实例讲解](https://juejin.im/post/5b010f27518825426539ba38)
+
+> ## 其他
+
+**Spring单例与线程安全：**
+
+[Spring框架中的单例模式（源码解读）](http://www.cnblogs.com/chengxuyuanzhilu/p/6404991.html)
+
+单例模式是一种常用的软件设计模式。通过单例模式可以保证系统中一个类只有一个实例。spring依赖注入时，使用了 多重判断加锁 的单例模式。
+
+> ## Spring源码阅读
+
+阅读源码不仅可以加深我们对Spring设计思想的理解，提高自己的编码水品，还可以让自己字面试中如鱼得水。下面的是Github上的一个开源的Spring源码阅读，大家有时间可以看一下，当然你如果有时间也可以自己慢慢研究源码。
+
+###  [Spring源码阅读](https://github.com/seaswalker/Spring)
+ - [spring-core](https://github.com/seaswalker/Spring/blob/master/note/Spring.md)
+- [spring-aop](https://github.com/seaswalker/Spring/blob/master/note/spring-aop.md)
+- [spring-context](https://github.com/seaswalker/Spring/blob/master/note/spring-context.md)
+- [spring-task](https://github.com/seaswalker/Spring/blob/master/note/spring-task.md)
+- [spring-transaction](https://github.com/seaswalker/Spring/blob/master/note/spring-transaction.md)
+- [spring-mvc](https://github.com/seaswalker/Spring/blob/master/note/spring-mvc.md)
+- [guava-cache](https://github.com/seaswalker/Spring/blob/master/note/guava-cache.md)
diff --git "a/Java/Spring/Spring\346\272\220\347\240\201\350\247\243\346\236\220-IoC\345\256\271\345\231\250\347\232\204\345\210\235\345\247\213\345\214\226\350\277\207\347\250\213(\344\270\212).md" "b/Java/Spring/Spring\346\272\220\347\240\201\350\247\243\346\236\220-IoC\345\256\271\345\231\250\347\232\204\345\210\235\345\247\213\345\214\226\350\277\207\347\250\213(\344\270\212).md"
new file mode 100644
index 0000000000..c59622d02f
--- /dev/null
+++ "b/Java/Spring/Spring\346\272\220\347\240\201\350\247\243\346\236\220-IoC\345\256\271\345\231\250\347\232\204\345\210\235\345\247\213\345\214\226\350\277\207\347\250\213(\344\270\212).md"
@@ -0,0 +1,174 @@
+严格来说,容器的初始化过程主要包括
+ - BeanDefinition的Resource定位
+ - BeanDefinition的载入和解析
+ - BeanDefinition在容器中的注册
+
+在初始化的过程当中,我们会看到一个又一个的方法被调用,换句话说,其实是通过调用一些方法来完成IoC容器初始化的.
+
+`refresh()方法`,其实标志**容器初始化过程的正式启动**.
+
+Spring之所以把这三个基本过程分开,并使用不同模块
+如使用相应的**ResourceLoader**、**BeanDefinitionReader**等模块,是因为这样可以让用户更灵活地对这三个过程进行裁剪或扩展,定义出最适合自己的IoC容器的初始化过程.
+#  1 BeanDefinition的Resource定位
+**BeanDefinition**
+从字面上理解,它代表着Bean的定义.
+其实,它就是完整的描述了在Spring配置文件中定义的节点中的所有信息,包括各种子节点.
+不太恰当地说,我们可以把它理解为配置文件中一个个<bean></bean>节点所包含的信息
+
+
+在**ApplicationContext**中,Spring已经为我们提供了一系列加载不同Resource的读取器的实现**DefaultListableBeanFactory**只是一个纯粹的IoC容器,需要为它提供特定的读取器才能完成这些功能.
+但使用**DefaultListableBeanFactory**这种更底层的容器能提高定制IoC容器的灵活性.
+
+至于常用的**ApplicationContext**见名知义,如
+- **FileSystemXmlApplicationContext**
+- **ClassPathXmlApplicationContext**
+- **XmlWebApplicationContext**
+- ...
+
+下面将以**FileSystemXmlApplicationContext**为例,分析怎么完成Resource定位
+![ApplicationContext继承体系](http://upload-images.jianshu.io/upload_images/4685968-28e4fd8babdb5881.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+从实现角度,我们近距离关心以**FileSystemXmlApplicationContext**为核心的继承体系
+![](http://upload-images.jianshu.io/upload_images/4685968-7cd374f07190bbf7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+```
+package org.springframework.context.support;
+
+public class FileSystemXmlApplicationContext extends AbstractXmlApplicationContext {
+
+    public FileSystemXmlApplicationContext() {
+    }
+
+    // @param 父上下文
+    public FileSystemXmlApplicationContext(ApplicationContext parent) {
+        super(parent);
+    }
+ 
+    // 这个构造函数的configLocation包含BeanDefinition所在的文件路径
+    public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
+        this(new String[] {configLocation}, true, null);
+    }
+
+    // 这个构造函数允许configLocation包含多个BeanDefinition的文件路径
+    public FileSystemXmlApplicationContext(String... configLocations) throws BeansException {
+        this(configLocations, true, null);
+    }
+
+    
+    // 这个构造函数允许configLocation包含多个BeanDefinition的文件路径的同时
+    // 还允许指定自己的双亲IoC容器
+    public FileSystemXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException {
+        this(configLocations, true, parent);
+    }
+
+    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh) throws BeansException {
+        this(configLocations, refresh, null);
+    }
+
+    // 在对象的初始化过程中,调用refresh方法载入BeanDefinition,这个refresh启动了
+    // BeanDefinition的载入过程,我们会在下面详解
+    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
+            throws BeansException {
+
+        super(parent);
+        setConfigLocations(configLocations);
+        if (refresh) {
+            refresh();
+        }
+    }
+
+    // 这是应用于文件系统的Resourse的实现,通过构造一个FileSystemResource得到一个在文件系统中定位的BeanDefinition
+    // 这个getResourceByPath是在BeanDefinitionReader中被调用的
+    // loadBeanDefinition采用了模板模式,具体的定位实现实际上是由各个子类完成的
+    @Override
+    protected Resource getResourceByPath(String path) {
+        if (path != null && path.startsWith("/")) {
+            path = path.substring(1);
+        }
+        return new FileSystemResource(path);
+    }
+}
+```
+ 我们可以发现，在FileSystemXmlApplicationContext中不管调用哪个构造函数，最终都是会调用这个包含了refresh方法的构造函数，因此我们可以很容易得出结论：触发对`BeanDefinition`资源定位过程的`refresh`的调用是在`FileSystemXmlApplicationContext`的构造函数中启动的.
+![](http://upload-images.jianshu.io/upload_images/4685968-5635a0bc0b268228?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+ 根据上图及**FileSystemXmlApplicationContext**中含有***refresh()***方法的构造函数的分析,可清楚地看到整个**BeanDefinition**资源定位的过程.
+该过程最初是由***refresh()***触发,而***refresh()***的调用是在**FileSystemXmlApplicationContext**的构造函数中启动的,大致调用过程如下图
+![](http://upload-images.jianshu.io/upload_images/4685968-18bf13dff31cd6e6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+看了调用过程,我们可能好奇这个`FileSystemXmlAppplicationContext`在什么地方定义了`BeanDefinition`的读入器`BeanDefinitionReader`的呢?
+关于这个读入器的配置,我们到其基类  `AbstractRefreshableApplicationContext`  的 ` refreshBeanFactory()  `方法看看
+![](http://upload-images.jianshu.io/upload_images/4685968-eef2f481155ad199?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+刚才我们提到,***refresh()***的调用是在**FileSystemXmlApplicationContext**的构造函数中启动的
+而这个***refresh()***又是从**AbstractApplicationContext**继承而来
+因此,结合前面方法时序图知***refreshBeanFactory()***被**FileSystemXmlApplicationContext**构造函数中的***refresh()***调用.
+在这个方法（***refreshBeanFactory()***）中，通过***createBeanFactory()***构建了一个容器供**ApplicationContext**使用.
+这个容器就是前面我们提到的**DefaultListableBeanFactory**,同时它还启动了***loadBeanDefinition()***来载入**BeanDefinition**,这里和以编程式使用IoC容器的过程很相似
+在**AbstractRefreshableApplictionContext**中,这里是使用**BeanDefinitionReader**载入Bean定义的地方,因为允许有多种载入方式,这里通过一个抽象函数把具体的实现委托给子类完成
+
+从前面的方法调用栈可以发现***refreshBeanFactory***方法中调用的***loadBeanDefinitions***方法其实最终是调用**AbstractBeanDefinitionReader**里面的***loadBeanDefinitions***方法
+![](http://upload-images.jianshu.io/upload_images/4685968-60cb490082e9b896.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+对于取得**Resource**的具体过程，我们来看看`DefaultResourceLoader`怎样完成
+![](http://upload-images.jianshu.io/upload_images/4685968-bcb69b628fc42ae2?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+上图中 `getResourcePath()`将会被`FileSystemXmlApplicationContext`实现.
+该方法返回的是一个`FileSystemResource`对象,通过这个对象,Spring可以进行相关的I/O操作,完成`BeanDefinition`的定位.
+
+如果是其他的`ApplicationContext`,那么会对应生成其他种类的`Resource`，比如`ClassPathResource`、`ServletContextResource`等
+
+所以**BeanDefinition**的定位到这里就完成了.
+在**BeanDefinition**定位完成的基础上,就可以通过返回的**Resource**对象进行**BeanDefinition**的载入了.
+在定位过程完成后,为**BeanDefinition**的载入创造了I/O操作的条件,但具体的数据还没有开始读入.这些读入将在下面介绍的**BeanDefinition**的载入和解析中来完成.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22710\344\271\213\351\201\277\345\205\215\346\264\273\350\267\203\346\200\247\345\215\261\351\231\251.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22710\344\271\213\351\201\277\345\205\215\346\264\273\350\267\203\346\200\247\345\215\261\351\231\251.md"
new file mode 100644
index 0000000000..502caced5e
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22710\344\271\213\351\201\277\345\205\215\346\264\273\350\267\203\346\200\247\345\215\261\351\231\251.md"
@@ -0,0 +1,322 @@
+### 10.1 死锁
+
+哲学家问题
+
+有环
+
+A等B，B等A
+
+数据库往往可以检测和解决死锁//TODO
+
+JVM不行，一旦死锁只有停止重启。
+
+下面分别介绍了几种典型的死锁情况：
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1011-lock-ordering-deadlocks)10.1.1 Lock ordering Deadlocks
+
+下面是一个经典的锁顺序死锁：两个线程用不同的顺序来获得相同的锁，**如果按照锁的请求顺序来请求锁，就不会发生这种循环依赖的情况。**
+
+```
+public class LeftRightDeadlock {
+    private final Object left = new Object();
+    private final Object right = new Object();
+
+    public void leftRight() {
+        synchronized (left) {
+            synchronized (right) {
+                doSomething();
+            }
+        }
+    }
+
+    public void rightLeft() {
+        synchronized (right) {
+            synchronized (left) {
+                doSomethingElse();
+            }
+        }
+    }
+
+    void doSomething() {
+    }
+
+    void doSomethingElse() {
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1011-dynamic-lock-order-deadlocks)10.1.1 Dynamic Lock Order Deadlocks
+
+下面的转账例子，如果一个线程X向Y转，而另外一个线程Y向X也转，那么就会发生死锁。
+
+```
+public class DynamicOrderDeadlock {
+    // Warning: deadlock-prone!
+    public static void transferMoney(Account fromAccount,
+                                     Account toAccount,
+                                     DollarAmount amount)
+            throws InsufficientFundsException {
+        synchronized (fromAccount) {
+            synchronized (toAccount) {
+                if (fromAccount.getBalance().compareTo(amount) < 0)
+                    throw new InsufficientFundsException();
+                else {
+                    fromAccount.debit(amount);
+                    toAccount.credit(amount);
+                }
+            }
+        }
+    }
+
+    static class DollarAmount implements Comparable<DollarAmount> {
+        // Needs implementation
+
+        public DollarAmount(int amount) {
+        }
+
+        public DollarAmount add(DollarAmount d) {
+            return null;
+        }
+
+        public DollarAmount subtract(DollarAmount d) {
+            return null;
+        }
+
+        public int compareTo(DollarAmount dollarAmount) {
+            return 0;
+        }
+    }
+
+    static class Account {
+        private DollarAmount balance;
+        private final int acctNo;
+        private static final AtomicInteger sequence = new AtomicInteger();
+
+        public Account() {
+            acctNo = sequence.incrementAndGet();
+        }
+
+        void debit(DollarAmount d) {
+            balance = balance.subtract(d);
+        }
+
+        void credit(DollarAmount d) {
+            balance = balance.add(d);
+        }
+
+        DollarAmount getBalance() {
+            return balance;
+        }
+
+        int getAcctNo() {
+            return acctNo;
+        }
+    }
+
+    static class InsufficientFundsException extends Exception {
+    }
+}
+
+```
+
+解决办法还是顺序话锁，考虑针对两种情况取hashcode然后判断if-else里面决定锁顺序。
+
+```
+class Helper {
+            public void transfer() throws InsufficientFundsException {
+                if (fromAcct.getBalance().compareTo(amount) < 0)
+                    throw new InsufficientFundsException();
+                else {
+                    fromAcct.debit(amount);
+                    toAcct.credit(amount);
+                }
+            }
+        }
+        int fromHash = System.identityHashCode(fromAcct);
+        int toHash = System.identityHashCode(toAcct);
+
+        if (fromHash < toHash) {
+            synchronized (fromAcct) {
+                synchronized (toAcct) {
+                    new Helper().transfer();
+                }
+            }
+        } else if (fromHash > toHash) {
+            synchronized (toAcct) {
+                synchronized (fromAcct) {
+                    new Helper().transfer();
+                }
+            }
+        } else {
+            synchronized (tieLock) {
+                synchronized (fromAcct) {
+                    synchronized (toAcct) {
+                        new Helper().transfer();
+                    }
+                }
+            }
+        }
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1013-%E5%9C%A8%E5%8D%8F%E4%BD%9C%E5%AF%B9%E8%B1%A1%E4%B9%8B%E9%97%B4%E5%8F%91%E7%94%9F%E6%AD%BB%E9%94%81deadlocks-between-cooperating-objects)10.1.3 在协作对象之间发生死锁Deadlocks Between Cooperating Objects
+
+下面的例子setLocation和getImage都会获取两把锁，会存在两个线程按照不同的顺序获取锁的情况。
+
+```
+public class CooperatingDeadlock {
+    // Warning: deadlock-prone!
+    class Taxi {
+        @GuardedBy("this") private Point location, destination;
+        private final Dispatcher dispatcher;
+
+        public Taxi(Dispatcher dispatcher) {
+            this.dispatcher = dispatcher;
+        }
+
+        public synchronized Point getLocation() {
+            return location;
+        }
+
+        public synchronized void setLocation(Point location) {
+            this.location = location;
+            if (location.equals(destination))
+                dispatcher.notifyAvailable(this);
+        }
+
+        public synchronized Point getDestination() {
+            return destination;
+        }
+
+        public synchronized void setDestination(Point destination) {
+            this.destination = destination;
+        }
+    }
+
+    class Dispatcher {
+        @GuardedBy("this") private final Set<Taxi> taxis;
+        @GuardedBy("this") private final Set<Taxi> availableTaxis;
+
+        public Dispatcher() {
+            taxis = new HashSet<Taxi>();
+            availableTaxis = new HashSet<Taxi>();
+        }
+
+        public synchronized void notifyAvailable(Taxi taxi) {
+            availableTaxis.add(taxi);
+        }
+
+        public synchronized Image getImage() {
+            Image image = new Image();
+            for (Taxi t : taxis)
+                image.drawMarker(t.getLocation());
+            return image;
+        }
+    }
+
+    class Image {
+        public void drawMarker(Point p) {
+        }
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1014-%E5%BC%80%E6%94%BE%E8%B0%83%E7%94%A8)10.1.4 开放调用
+
+减小锁的力度，锁不嵌套。
+
+```
+class CooperatingNoDeadlock {
+    @ThreadSafe
+    class Taxi {
+        @GuardedBy("this") private Point location, destination;
+        private final Dispatcher dispatcher;
+
+        public Taxi(Dispatcher dispatcher) {
+            this.dispatcher = dispatcher;
+        }
+
+        public synchronized Point getLocation() {
+            return location;
+        }
+
+        public synchronized void setLocation(Point location) {
+            boolean reachedDestination;
+            synchronized (this) {
+                this.location = location;
+                reachedDestination = location.equals(destination);
+            }
+            if (reachedDestination)
+                dispatcher.notifyAvailable(this);
+        }
+
+        public synchronized Point getDestination() {
+            return destination;
+        }
+
+        public synchronized void setDestination(Point destination) {
+            this.destination = destination;
+        }
+    }
+
+    @ThreadSafe
+    class Dispatcher {
+        @GuardedBy("this") private final Set<Taxi> taxis;
+        @GuardedBy("this") private final Set<Taxi> availableTaxis;
+
+        public Dispatcher() {
+            taxis = new HashSet<Taxi>();
+            availableTaxis = new HashSet<Taxi>();
+        }
+
+        public synchronized void notifyAvailable(Taxi taxi) {
+            availableTaxis.add(taxi);
+        }
+
+        public Image getImage() {
+            Set<Taxi> copy;
+            synchronized (this) {
+                copy = new HashSet<Taxi>(taxis);
+            }
+            Image image = new Image();
+            for (Taxi t : copy)
+                image.drawMarker(t.getLocation());
+            return image;
+        }
+    }
+
+    class Image {
+        public void drawMarker(Point p) {
+        }
+    }
+
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1015-%E8%B5%84%E6%BA%90%E6%AD%BB%E9%94%81)1.0.15 资源死锁
+
+*   数据库连接池，A持有数据库D1连接，等待与D2连接，B持有D2的连接，等待与D1连接。
+*   线程饥饿死锁，如8.1.1小节的例子。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#102-%E6%AD%BB%E9%94%81%E7%9A%84%E9%81%BF%E5%85%8D%E4%B8%8E%E8%AF%8A%E6%96%AD)10.2 死锁的避免与诊断
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1021-%E6%94%AF%E6%8C%81%E5%AE%9A%E6%97%B6%E7%9A%84%E9%94%81)10.2.1 支持定时的锁
+
+tryLock
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1022-kill--3-%E5%8F%91%E4%BF%A1%E5%8F%B7%E7%BB%99jvm-dump%E7%BA%BF%E7%A8%8B)10.2.2 kill -3 发信号给JVM dump线程
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#103-%E5%85%B6%E4%BB%96%E6%B4%BB%E8%B7%83%E6%80%A7%E5%8D%B1%E9%99%A9)10.3 其他活跃性危险
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1031-%E9%A5%A5%E9%A5%BF)10.3.1 饥饿
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1033-%E6%B4%BB%E9%94%81livelock)10.3.3 活锁Livelock
+
+他不会阻塞线程，但是也不能继续执行，因为线程在不断的重复执行相同的操作，而且总会失败。
+
+例如处理事务消，回滚后再次重新把任务放在队头。
+
+又例如发送数据包，都选择1s后重试，那么总会冲突，所以可以考虑一个随机数时间间隔。
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22711\344\271\213\346\200\247\350\203\275\344\270\216\345\217\257\344\274\270\347\274\251\346\200\247Performance-and-Scalability.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22711\344\271\213\346\200\247\350\203\275\344\270\216\345\217\257\344\274\270\347\274\251\346\200\247Performance-and-Scalability.md"
new file mode 100644
index 0000000000..a42dc5e5e2
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22711\344\271\213\346\200\247\350\203\275\344\270\216\345\217\257\344\274\270\347\274\251\346\200\247Performance-and-Scalability.md"
@@ -0,0 +1,320 @@
+线程可以充分发挥系统的处理能力，提高资源利用率。同时现有的线程可以提升系统响应性。
+
+但是在安全性与极限性能上，我们首先需要保证的是安全性。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#111-%E5%AF%B9%E6%80%A7%E8%83%BD%E7%9A%84%E6%80%9D%E8%80%83)11.1 对性能的思考
+
+提升性能=用更少的资源做更多的事情（太对了，这才是问题的本质）。
+
+资源包括：CPU时钟周期，内存，网络带宽，I/O带宽，数据请求，磁盘空间等。
+
+资源密集型说的就是对上述维度敏感的应用。
+
+与单线程相比，多线程总会一起一些额外的性能开销：
+
+*   线程协调with coordinating between threads (locking, signaling, and memory synchronization)
+*   上下文切换increased context switching
+*   线程创建和销毁thread creation and teardown
+*   线程调度scheduling overhead
+
+可伸缩性是指：增加资源，程序的吞吐可以成比例的增加。
+
+性能的提高往往是一个权衡的过程，需要考虑诸多因素。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#112-amdahl%E5%AE%9A%E5%BE%8B-amdahls-law)11.2 Amdahl定律 Amdahl's Law
+
+收割可以靠并行提高性能，而作物生长则不行。这是一个很简单的自然界的问题，在计算机界也存在，需要对问题进行合理的分解，发现潜在的并行能力。
+
+Amdahl定律：[并行计算](https://zh.wikipedia.org/wiki/%E5%B9%B6%E8%A1%8C%E8%AE%A1%E7%AE%97)中的**加速比**是用并行前的执行速度和并行后的执行速度之比来表示的，它表示了在并行化之后的效率提升情况。
+
+speedup <= 1 / F + (1 - F) /N
+
+F表示被串行化的部分，N表示处理器数量。
+
+如果N无穷大，那么最大的加速比例是1/F。理论上如果50%是串行的，那么最大的加速比只能是2。如果10%串行。那么最大加速比接近10，如果N=10也就是说有10个处理器资源，那么最高的加速比是5.4，在100个处理器的情况下是9.2。
+
+但是任何程序都存在串行部分，例如从队列中take数据，访问数据库的操作等，这是绝对的。
+
+书中举了一个例子是Synchronized linkedlist和ConcurrentLinkedQueue的吞吐率对比，在处理器数量到达上限后，他们的吞吐都基本是一条持平的线，但是Synchronized linkedlist吞吐率更低，在处理器较少的情况下就到达了极限，这主要受context switch的限制。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#113-%E7%BA%BF%E7%A8%8B%E5%BC%95%E5%85%A5%E7%9A%84%E5%BC%80%E9%94%80)11.3 线程引入的开销
+
+单线程不存在线程调度，也不存在同步开销，不需要使用锁来保证安全一致性。而多线程这些都需要考虑。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1131-%E4%B8%8A%E4%B8%8B%E6%96%87%E5%88%87%E6%8D%A2)11.3.1 上下文切换
+
+操作系统的设计者巧妙地利用了时间片轮转的方式, CPU给每个任务都服务一定的时间, 然后把当前任务的状态保存下来, 在加载下一任务的状态后, 继续服务下一任务. 如果可运行的线程数大于CPU数量，那么OS会最终将某个正在运行的线程调度出来，从而让其他线程能够使用CPU，这会导致一次上下文切换，主要包括当前线程“保存现场”，并且新调度出来的线程需要“恢复现场“。这里的context switch直接消耗包括: CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉; 间接消耗指的是多核的cache之间得共享数据, 间接消耗对于程序的影响要看线程工作区操作数据的大小). 
+
+JVM和OS消耗的CPU时钟周期越少，那么APP可用的CPU时钟周期就越多。
+
+往往OS有一个最小的执行时间，防止过于频繁的上下文切换。
+
+JVM会因为阻塞比如锁、阻塞I/O而挂起线程，如果频繁的阻塞，就会无法使用完整的调度时间片。//?
+
+如果可运行的线程数大于CPU的内核数，那么OS会根据一定的调度算法，强行切换正在运行的线程，从而使其它线程能够使用CPU周期。
+
+切换线程会导致上下文切换。线程的调度会导致CPU需要在操作系统和进程间花费更多的时间片段，这样真正执行应用程序的时间就减少了。另外上下文切换也会导致缓存的频繁进出，对于一个刚被切换的线程来说，可能由于高速缓冲中没有数据而变得更慢，从而导致更多的IO开销。
+
+`vmstat` 命令可以看cs这一个字段看上下文切换的数据。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1132-%E5%86%85%E5%AD%98%E5%90%8C%E6%AD%A5)11.3.2 内存同步
+
+同步的性能开销包括多个方面。在synchronized和volatile提供的可见性保证中会使用一些特殊指令，即内存栅栏（memory barrier），内存栅栏可以刷新缓存，满足可见性，但是它也会抑制一些编译器优化，例如不能指令重排序。
+
+现代的JVM对于无竞争的synchronized的消耗非常小，基本微乎其微。
+
+同时现代的JVM编译优化做的非常成熟，一些不必要的同步开销往往可以优化掉。例如，下面的代码会去掉锁获取。
+
+```
+synchronized (new Object()) {
+ // do something
+} 
+
+```
+
+还有一些比如escape analysis会找出不会发布到堆上的本地对象，锁的获取和释放会被优化为最小的次数甚至去掉。例如下面的操作。
+
+```
+public String getStoogeNames() {
+ List<String> stooges = new Vector<String>();
+ stooges.add("Moe");
+ stooges.add("Larry");
+ stooges.add("Curly");
+ return stooges.toString();
+} 
+
+```
+
+当然即使不escape，也会有lock coarsening过程，将临近的同步代码块使用同一个锁合并起来。这都减少了同步的开销。
+
+所以不必过度担心非竞争同步带来的开销，这个基本的机制已经非常的快了，而且JVM还有能进行额外的优化以进一步降低或者消除开销的本领。
+
+不同线程间要进行数据同步，synchronized以及volatile提供的可见性都会导致缓存失效。线程栈之间的数据要和主存进行同步，这些同步有一些小小的开销。如果线程间同时要进行数据同步，那么这些同步的线程可能都会受阻。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1133-%E9%98%BB%E5%A1%9E)11.3.3 阻塞
+
+竞争的同步需要OS介入，从而增加了开销。当在锁上发生竞争时，失败者线程会被阻塞，JVM在实现发现阻塞的行为时，可以采用
+
+*   自旋等待 spin-waiting
+*   或者OS挂起被阻塞的线程
+
+这两种的效率高低取决于上下文切换的开销以及成功获取锁之前的等待时间，如果等待时间较短，则spin-waiting，如果较长则挂起。
+
+一个线程被阻塞会产生上下文切换的影响，但是它到底何时执行这是由OS决定的，靠时间分片机制，这个调度的策略是OS解决的，而JVM的scheduler解决的是阻塞释放锁之后哪个线程需要被select出来执行，也就是转到runnable状态。
+
+There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default. Many types of algorithms exist like **preemptive** and **time slicing**with **round robin** etc. 
+
+The JVM is based on **preemptive and priority based** scheduling algorithm to select thread to run.
+
+每个Java线程一对一映射到Solaris平台上的一个本地线程上，并将线程调度交由本地线程的调度程序。由于Java线程是与本地线程是一对一地绑在一起的，所以改变Java线程的优先权也不会有可靠地运行结果。
+
+对于类Unix系统而言，一般都是进程作为任务的调度单位，也即是操作系统调度器，只会针对进程来分配CPU等资源。由于进程彼此独立，相互不可进行直接访问，这增加了应用的通信成本。所以后面有了微进程，微进程与进程不同的是，允许一定程度上，彼此可以直接进行访问，详细可参考[LinuxThreads](http://en.wikipedia.org/wiki/LinuxThreads)。JVM在一些类Unix平台下，就是将线程映射到操作系统的微进程，来实现线程调度。这样多线程能够直接被系统调度器进行调度，与此对应的就是其线程的创建和销毁的成本就比较高，而且JVM的线程优先级很难进行匹配，无法提供确切的保证，仅仅是个hint。
+
+当发生锁竞争时，失败的线程会导致阻塞。通常阻塞的线程可能在JVM内部进行自旋等待，或者被操作系统挂起。自旋等待可能会导致更多的CPU切片浪费，而操作系统挂起则会导致更多的上下文切换。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#114-%E5%87%8F%E5%B0%91%E9%94%81%E7%9A%84%E7%AB%9E%E4%BA%89)11.4 减少锁的竞争
+
+减少锁的竞争能够提高性能和可伸缩性。
+
+在并发程序中，对可伸缩性的最主要的威胁就是独占方式的资源锁。
+
+有三种方式可以减低锁的竞争程度：
+
+*   减少锁的持有时间
+*   降低锁的请求频率
+*   使用带有协调机制的独占锁，这些机器允许更好的并发性。//?
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1141-%E7%BC%A9%E5%B0%8F%E9%94%81%E7%9A%84%E8%8C%83%E5%9B%B4%E5%BF%AB%E8%BF%9B%E5%BF%AB%E5%87%BA)11.4.1 缩小锁的范围（快进快出）
+
+原理就是Amdah定律，串行的代码总量减少了。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1142-%E5%87%8F%E5%B0%8F%E9%94%81%E7%9A%84%E7%B2%92%E5%BA%A6)11.4.2 减小锁的粒度
+
+这种方式就是降低线程请求锁的频率，通过锁分解来实现。
+
+下面的应用明显锁的粒度太粗了。
+
+```
+public class ServerStatusBeforeSplit {
+    @GuardedBy("this") public final Set<String> users;
+    @GuardedBy("this") public final Set<String> queries;
+
+    public ServerStatusBeforeSplit() {
+        users = new HashSet<String>();
+        queries = new HashSet<String>();
+    }
+
+    public synchronized void addUser(String u) {
+        users.add(u);
+    }
+
+    public synchronized void addQuery(String q) {
+        queries.add(q);
+    }
+
+    public synchronized void removeUser(String u) {
+        users.remove(u);
+    }
+
+    public synchronized void removeQuery(String q) {
+        queries.remove(q);
+    }
+}
+
+```
+
+锁分解就是独立的变量独立分配锁，不适用全局锁。优化后如下：
+
+```
+public class ServerStatusAfterSplit {
+    @GuardedBy("users") public final Set<String> users;
+    @GuardedBy("queries") public final Set<String> queries;
+
+    public ServerStatusAfterSplit() {
+        users = new HashSet<String>();
+        queries = new HashSet<String>();
+    }
+
+    public void addUser(String u) {
+        synchronized (users) {
+            users.add(u);
+        }
+    }
+
+    public void addQuery(String q) {
+        synchronized (queries) {
+            queries.add(q);
+        }
+    }
+
+    public void removeUser(String u) {
+        synchronized (users) {
+            users.remove(u);
+        }
+    }
+
+    public void removeQuery(String q) {
+        synchronized (users) {
+            queries.remove(q);
+        }
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1143-%E9%94%81%E5%88%86%E6%AE%B5)11.4.3 锁分段
+
+最典型的例子就是ConcurrentHashMap。
+
+```
+public class StripedMap {
+    // Synchronization policy: buckets[n] guarded by locks[n%N_LOCKS]
+    private static final int N_LOCKS = 16;
+    private final Node[] buckets;
+    private final Object[] locks;
+
+    private static class Node {
+        Node next;
+        Object key;
+        Object value;
+    }
+
+    public StripedMap(int numBuckets) {
+        buckets = new Node[numBuckets];
+        locks = new Object[N_LOCKS];
+        for (int i = 0; i < N_LOCKS; i++)
+            locks[i] = new Object();
+    }
+
+    private final int hash(Object key) {
+        return Math.abs(key.hashCode() % buckets.length);
+    }
+
+    public Object get(Object key) {
+        int hash = hash(key);
+        synchronized (locks[hash % N_LOCKS]) {
+            for (Node m = buckets[hash]; m != null; m = m.next)
+                if (m.key.equals(key))
+                    return m.value;
+        }
+        return null;
+    }
+
+    public void clear() {
+        for (int i = 0; i < buckets.length; i++) {
+            synchronized (locks[i % N_LOCKS]) {
+                buckets[i] = null;
+            }
+        }
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1144-%E9%81%BF%E5%85%8D%E7%83%AD%E7%82%B9%E5%9F%9Fhot-field)11.4.4 避免热点域hot field
+
+比如HashMap的size方法，ConcurrentHashMap采用了牺牲size的准确性的策略。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1145-%E4%B8%80%E4%BA%9B%E6%9B%BF%E4%BB%A3%E7%8B%AC%E5%8D%A0%E9%94%81%E7%9A%84%E6%96%B9%E6%B3%95)11.4.5 一些替代独占锁的方法
+
+ReadWriteLock，AtomicInteger，UNSAFE.compareAndSwap(..)
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1146-%E7%9B%91%E6%B5%8Bcpu%E7%9A%84%E5%88%A9%E7%94%A8%E7%8E%87)11.4.6 监测CPU的利用率
+
+vmstat，kill -3 pid
+
+”waiting to lock monitor…“有这句就证明竞争太激烈了。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#115-%E7%A4%BA%E4%BE%8B%E6%AF%94%E8%BE%83map%E7%9A%84%E6%80%A7%E8%83%BD)11.5 示例：比较Map的性能
+
+比较了ConcurrentHashMap和synchronized hashmap的性能对比。
+
+串行访问Map一个锁 pk 多个线程能并发的访问Map通过分段锁。
+
+竞争非常激烈的时候，synchronized hashmap伸缩性非常差，吞吐量不会随着线程数增加而增加，反而降低，因为每个操作消耗的时间大部分都用于上下文切换和调度延迟上了。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#116-%E5%87%8F%E5%B0%91%E4%B8%8A%E4%B8%8B%E6%96%87%E5%88%87%E6%8D%A2%E7%9A%84%E5%BC%80%E9%94%80)11.6 减少上下文切换的开销
+
+举个例子，就是APP记录日志，例如写日志到本地或者远程RPC，直接记录会存在I/O阻塞，靠一个轻量级的queue来解耦，使得APP不感知影响，减少阻塞。
+
+[http://www.artima.com/insidejvm/ed2/threadsynch.html](http://www.artima.com/insidejvm/ed2/threadsynch.html) //TODO
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#%E6%80%BB%E7%BB%93)总结
+
+了解了性能的提升的几个方面，也了解性能的开销后，应用程序就要根据实际的场景进行取舍和评估。没有一劳永逸的优化方案，不断的进行小范围改进和调整是提高性能的有效手段。当前一些大的架构调整也会导致较大的性能的提升。
+
+性能提升考虑的方面：
+
+*   系统平台的资源利用率
+
+一个程序对系统平台的资源利用率是指某一个设备繁忙且服务于此程序的时间占所有时间的比率。从物理学的角度讲类似于有用功的比率。简单的说就是：资源利用率=有效繁忙时间/总耗费时间。
+
+也就说尽可能的让设备做有用的功，同时榨取其最大值。无用的循环可能会导致CPU 100%的使用率，但不一定是有效的工作。有效性通常难以衡量，通常只能以主观来评估，或者通过被优化的程序的行为来判断是否提高了有效性。
+
+*   延迟
+
+延迟描述的是完成任务所耗费的时间。延迟有时候也成为响应时间。如果有多个并行的操作，那么延迟取决于耗费时间最大的任务。
+
+*   多处理
+
+多处理是指在单一系统上同时执行多个进程或者多个程序的能力。多处理能力的好处是可以提高吞吐量。多处理可以有效利用多核CPU的资源。
+
+*   多线程
+
+多线程描述的是同一个地址空间内同时执行多个线程的过程。这些线程都有不同的执行路径和不同的栈结构。我们说的并发性更多的是指针对线程。
+
+*   并发性
+
+同时执行多个程序或者任务称之为并发。单程序内的多任务处理或者多程序间的多任务处理都认为是并发。
+
+*   吞吐量
+
+吞吐量衡量系统在单位之间内可以完成的工作总量。对于硬件系统而言，吞吐量是物理介质的上限。在没有达到物理介质之前，提高系统的吞吐量也可以大幅度改进性能。同时吞吐量也是衡量性能的一个指标。
+
+*   瓶颈
+
+程序运行过程中性能最差的地方。通常而言，串行的IO、磁盘IO、内存单元分配、网络IO等都可能造成瓶颈。某些使用太频繁的算法也有可能成为瓶颈。
+
+*   可扩展性
+
+这里的可扩展性主要是指程序或系统通过增加可使用的资源而增加性能的能力。
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22713\344\271\213\346\230\276\345\274\217\351\224\201-(Explicit-Locks).md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22713\344\271\213\346\230\276\345\274\217\351\224\201-(Explicit-Locks).md"
new file mode 100644
index 0000000000..99605a115d
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22713\344\271\213\346\230\276\345\274\217\351\224\201-(Explicit-Locks).md"
@@ -0,0 +1,362 @@
+Java5之前只能用synchronized和volatile，5后Doug Lea加入了ReentrantLock，并不是替代内置锁，而是当内置锁机制不适用时，作为一种可选择的高级功能
+不适用包括
+- 无法中断一个正在等待获取锁的线程
+- 无限的锁等待
+- 内置锁必须放在代码块里面（编程有些局限性）
+
+所以提供了J.U.C的Lock
+# 1.  Lock和ReentrantLock
+![Lock接口定义](http://upload-images.jianshu.io/upload_images/4685968-dc1ca37c9ee37a2c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![使用范例](http://upload-images.jianshu.io/upload_images/4685968-f31c64919b44f26e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+之所以叫ReentrantLock，可理解为两部分
+- Re-entrant
+可重入，lock多少次都没关系，只需要unlock即可，或者lock里面嵌套了别的lock都可以
+- Lock
+提供了和synchronized一样的互斥性和内存可见性，与synchronized的monitor内存语义一样
+
+#2. synchronized（S）    VS     lock（L） 
+-  L 是接口，S 是关键字 
+- S异常时，会自动释放线程占有的锁，不会发生死锁
+L异常时，若没有主动通过 unlock（）释放锁，则很有可能造成死锁.所以用 lock 时要在 finally 中释放锁. 
+- L 可以当等待锁的线程响应中断
+使用 S 时，等待的线程将会一直等下去，不能响应中断
+- 通过 L 可以知道是否成功获得锁，S 不可以 
+- L 可以提高多个线程进行读写操作的效率 
+
+#3 Lock的特性
+*   可定时锁等待
+*   可轮询锁等待
+*   可中断锁等待
+*   公平性
+*   实现非块结构的加锁
+*   绑定多个Condition。通过多次newCondition可以获得多个Condition对象,可以简单的实现比较复杂的线程同步的功能.通过await(),signal();
+
+下面依次讲解：
+
+##3.1 轮询锁和定时锁
+内置锁的死锁问题只能通过重启解决，可定时和可轮询锁提供了另一种选择
+通过`tryLock`解决
+```
+public class DeadlockAvoidance {
+    private static Random rnd = new Random();
+
+    public boolean transferMoney(Account fromAcct,
+                                 Account toAcct,
+                                 DollarAmount amount,
+                                 long timeout,
+                                 TimeUnit unit)
+            throws InsufficientFundsException, InterruptedException {
+        long fixedDelay = getFixedDelayComponentNanos(timeout, unit);
+        long randMod = getRandomDelayModulusNanos(timeout, unit);
+        long stopTime = System.nanoTime() + unit.toNanos(timeout); //定时，轮询
+
+        while (true) {
+            if (fromAcct.lock.tryLock()) {
+                try {
+                    if (toAcct.lock.tryLock()) {
+                        try {
+                            if (fromAcct.getBalance().compareTo(amount) < 0)
+                                throw new InsufficientFundsException();
+                            else {
+                                fromAcct.debit(amount);
+                                toAcct.credit(amount);
+                                return true;
+                            }
+                        } finally {
+                            toAcct.lock.unlock();
+                        }
+                    }
+                } finally {
+                    fromAcct.lock.unlock();
+                }
+            }
+            if (System.nanoTime() < stopTime)
+                return false;
+            NANOSECONDS.sleep(fixedDelay + rnd.nextLong() % randMod);
+        }
+    }
+
+    private static final int DELAY_FIXED = 1;
+    private static final int DELAY_RANDOM = 2;
+
+    static long getFixedDelayComponentNanos(long timeout, TimeUnit unit) {
+        return DELAY_FIXED;
+    }
+
+    static long getRandomDelayModulusNanos(long timeout, TimeUnit unit) {
+        return DELAY_RANDOM;
+    }
+
+    static class DollarAmount implements Comparable<DollarAmount> {
+        public int compareTo(DollarAmount other) {
+            return 0;
+        }
+
+        DollarAmount(int dollars) {
+        }
+    }
+
+    class Account {
+        public Lock lock;
+
+        void debit(DollarAmount d) {
+        }
+
+        void credit(DollarAmount d) {
+        }
+
+        DollarAmount getBalance() {
+            return null;
+        }
+    }
+
+    class InsufficientFundsException extends Exception {
+    }
+}
+
+```
+##3.2 带有时间限制的锁
+![](http://upload-images.jianshu.io/upload_images/4685968-2042b71c6e0a7eec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##3.3 可中断的锁
+![](http://upload-images.jianshu.io/upload_images/4685968-d1bcc5b13fa2deae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##3.4关于Condition
+最典型的就是阻塞的有界队列的实现。
+```
+public class BoundedBuffer {
+
+    private static final Logger logger = LoggerFactory.getLogger(BoundedBuffer.class);
+
+    final Lock lock = new ReentrantLock();
+
+    final Condition notFull = lock.newCondition();
+
+    final Condition notEmpty = lock.newCondition();
+
+    final Object[] items = new Object[2]; // 阻塞队列
+
+    int putptr, takeptr, count;
+
+    private void log(String info) {
+        logger.info(Thread.currentThread().getName() + " - " + info);
+    }
+
+    public void put(Object x) throws InterruptedException {
+        log(x + ",执行put");
+        lock.lock();
+        log(x + ",put lock.lock()");
+        try {
+            while (count == items.length) { // 如果队列满了，notFull就一直等待
+                log(x + ",put notFull.await() 队列满了");
+                notFull.await(); // 调用await的意思取反，及not notFull -> Full
+            }
+            items[putptr] = x; // 终于可以插入队列
+            if (++putptr == items.length) {
+                putptr = 0; // 如果下标到达数组边界，循环下标置为0
+            }
+            ++count;
+            log(x + ",put成功 notEmpty.signal() 周知队列不为空了");
+            notEmpty.signal(); // 唤醒notEmpty
+        } finally {
+            log(x + ",put lock.unlock()");
+            lock.unlock();
+        }
+    }
+
+    public Object take() throws InterruptedException {
+        log("执行take");
+        lock.lock();
+        Object x = null;
+        log("take lock.lock()");
+        try {
+            while (count == 0) {
+                log("take notEmpty.await() 队列为空等等");
+                notEmpty.await();
+            }
+            x = items[takeptr];
+            if (++takeptr == items.length) {
+                takeptr = 0;
+            }
+            --count;
+            log(x + ",take成功 notFull.signal() 周知队列有剩余空间了");
+            notFull.signal();
+            return x;
+        } finally {
+            lock.unlock();
+            log(x + ",take lock.unlock()");
+        }
+    }
+
+    public static void main(String[] args) throws InterruptedException {
+        final BoundedBuffer bb = new BoundedBuffer();
+        ExecutorService executor = Executors.newFixedThreadPool(10);
+
+        for (char i = 'A'; i < 'F'; i++) {
+            final char t = i;
+            executor.execute(() -> {
+                try {
+                    bb.put(t);
+                } catch (InterruptedException e) {
+                    e.printStackTrace();
+                }
+            });
+        }
+
+        List<Character> res = new LinkedList<>();
+        for (char i = 'A'; i < 'F'; i++) {
+            executor.execute(() -> {
+                try {
+                    char c = (char) bb.take();
+                    res.add(c);
+                } catch (InterruptedException e) {
+                    e.printStackTrace();
+                }
+            });
+        }
+
+        try {
+            executor.awaitTermination(2, TimeUnit.SECONDS);
+        } catch (InterruptedException ie) {
+            ie.printStackTrace();
+        }
+
+        logger.info(res.toString());
+        executor.shutdownNow();
+    }
+}
+
+```
+#4 性能考虑因素
+Java5的时候J.U.C的ReentrantLock锁竞争性能非常好，到了Java6使用了改进后的算法来管理内置锁，所以现在差不太多了，只好一点点
+
+竞争性能的影响可伸缩性的关键要素：如果有越多的资源被耗费在锁的管理和线程调度上，那么应用程序得到的资源就越少，锁的实现方式越好，将需要越少的系统调用和上下文切换。
+
+#5 公平性
+ReentrantLock默认创建非公平的锁，非公平是指
+被阻塞挂起的线程(LockSupport.park)都在AQS的CLH队列中排队等待自己被唤醒
+他们是按照发出的请求顺序来排队的
+但一旦有一个唤醒的就会和新来的线程竞争锁，新来的可能会“插队”，如果新来的成功获取锁，那么它将跳过所有等待线程而开始执行，这意味着本该被唤醒的线程失败了，对不起您回到队列的尾部继续等
+这就是非公平性。
+
+一般，非公平锁的性能要好于公平锁。
+原因在于一个线程被唤醒是需要时间的，挂起线程和唤醒恢复线程存在开销，这个空隙如果有其他线程处于ready状态，不需要上下文切换，那么直接运行就行，
+A持有锁，B请求，但是B在恢复的过程中,C可以插队"非公平"的获取锁，然后执行再释放，这时候B刚刚好做完上下文切换可以
+ 执行，这个对于B和C来说是一个“双赢”的局面，是提高吞吐量的原因。
+
+那么JVM也没有在其内置锁上采用公平性的机制。
+
+#6 synchronized和ReentrantLock的选择
+除非使用到3提到的高级特性，或者内置锁无法满足需求时，否则还是老实用内置锁，毕竟是JVM自身提供的，而不是靠类库，因此可能会执行一些优化。
+
+另外内置锁在利用kill -3 dump thread的时候可以发现栈帧上的一些monitor lock的信息，识别死锁，而J.U.C的锁这方面就不太行，当然JAVA6之后提供了管理和调试接口解决了。
+
+#7 读-写锁
+ReentrantLock每次只有一个线程能持有锁，但是这种严格的互斥也会抑制并发。会抑制
+*   写/写
+*   写/读
+*   读/读
+
+冲突，但是很多情况下读操作是非常多的，如果放宽加锁的需求，允许多个读操作可以同时访问数据，那么就可以提升性能
+**但是要保证读取的数据是最新的,不会有其他线程修改数据**
+
+使用ReadWriteLock的场景是
+- 一个资源可以被多个读操作访问
+- 被一个写操作访问
+
+但是二者不能同时进行
+![](http://upload-images.jianshu.io/upload_images/4685968-f67b0246c467a4af.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+如果读线程正在持有锁,这时候另外一个写线程,那么会优先获取写锁
+
+应用
+```
+public class ReadWriteMap<K, V> {
+    private final Map<K, V> map;
+    private final ReadWriteLock lock=new ReentrantReadWriteLock();
+    private final Lock r=lock.readLock();
+    private final Lock w=lock.writeLock();
+
+    public ReadWriteMap(Map<K, V> map) {
+        this.map=map;
+    }
+
+    public V put(K key, V value) {
+        w.lock();
+        try {
+            return map.put( key, value );
+        } finally {
+            w.unlock();
+        }
+    }
+
+    public V remove(Object key) {
+        w.lock();
+        try {
+            return map.remove( key );
+        } finally {
+            w.unlock();
+        }
+    }
+
+    public void putAll(Map<? extends K, ? extends V> m) {
+        w.lock();
+        try {
+            map.putAll( m );
+        } finally {
+            w.unlock();
+        }
+    }
+
+    public void clear() {
+        w.lock();
+        try {
+            map.clear();
+        } finally {
+            w.unlock();
+        }
+    }
+
+    public V get(Object key) {
+        r.lock();
+        try {
+            return map.get( key );
+        } finally {
+            r.unlock();
+        }
+    }
+
+    public int size() {
+        r.lock();
+        try {
+            return map.size();
+        } finally {
+            r.unlock();
+        }
+    }
+
+    public boolean isEmpty() {
+        r.lock();
+        try {
+            return map.isEmpty();
+        } finally {
+            r.unlock();
+        }
+    }
+
+    public boolean containsKey(Object key) {
+        r.lock();
+        try {
+            return map.containsKey( key );
+        } finally {
+            r.unlock();
+        }
+    }
+
+    public boolean containsValue(Object value) {
+        r.lock();
+        try {
+            return map.containsValue( value );
+        } finally {
+            r.unlock();
+        }
+    }
+}
+```
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22714\344\271\213\346\236\204\345\273\272\350\207\252\345\256\232\344\271\211\347\232\204\345\220\214\346\255\245\345\267\245\345\205\267-(Building-Custom-Synchronizers).md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22714\344\271\213\346\236\204\345\273\272\350\207\252\345\256\232\344\271\211\347\232\204\345\220\214\346\255\245\345\267\245\345\205\267-(Building-Custom-Synchronizers).md"
new file mode 100644
index 0000000000..1fe8e3a439
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22714\344\271\213\346\236\204\345\273\272\350\207\252\345\256\232\344\271\211\347\232\204\345\220\214\346\255\245\345\267\245\345\205\267-(Building-Custom-Synchronizers).md"
@@ -0,0 +1,783 @@
+类库中包含了许多存在状态依赖的类，例如FutureTask、Semaphore和BlockingQueue，他们的一些操作都有前提条件，例如非空，或者任务已完成等。
+
+创建状态依赖类的最简单的房就是在JDK提供了的状态依赖类基础上构造。例如第八章的ValueLactch，如果这些不满足，可以使用Java语言或者类库提供的底层机制来构造，包括
+
+*   内置的条件队列
+*   condition
+*   AQS
+
+这一章就介绍这些。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#141-%E7%8A%B6%E6%80%81%E4%BE%9D%E8%B5%96%E6%80%A7%E7%9A%84%E7%AE%A1%E7%90%86-state-dependence)14.1 状态依赖性的管理 State Dependence
+
+在14.2节会介绍使用条件队列来解决阻塞线程运行的问题。下面先介绍通过轮询和休眠的方式（勉强）的解决。
+
+下面是一个标准的模板，
+
+```
+void blockingAction() throws InterruptedException {
+   acquire lock on object state
+   while (precondition does not hold) {
+      release lock
+      wait until precondition might hold
+      optionally fail if interrupted or timeout expires
+      reacquire lock
+   }
+   perform action
+}
+
+```
+
+下面介绍阻塞有界队列的集中实现方式。依赖的前提条件是：
+
+*   不能从空缓存中获取元素
+*   不能将元素放入已满的缓存中
+
+不满足条件时候，依赖状态的操作可以
+
+*   抛出异常
+*   返回一个错误状态（码）
+*   阻塞直到进入正确的状态
+
+下面是基类，线程安全，但是非阻塞。
+
+```
+@ThreadSafe
+public abstract class BaseBoundedBuffer <V> {
+    @GuardedBy("this") private final V[] buf;
+    @GuardedBy("this") private int tail;
+    @GuardedBy("this") private int head;
+    @GuardedBy("this") private int count;
+
+    protected BaseBoundedBuffer(int capacity) {
+        this.buf = (V[]) new Object[capacity];
+    }
+
+    protected synchronized final void doPut(V v) {
+        buf[tail] = v;
+        if (++tail == buf.length)
+            tail = 0;
+        ++count;
+    }
+
+    protected synchronized final V doTake() {
+        V v = buf[head];
+        buf[head] = null;
+        if (++head == buf.length)
+            head = 0;
+        --count;
+        return v;
+    }
+
+    public synchronized final boolean isFull() {
+        return count == buf.length;
+    }
+
+    public synchronized final boolean isEmpty() {
+        return count == 0;
+    }
+}
+
+```
+
+“先检查再运行”的逻辑解决方案如下，调用者必须自己处理前提条件失败的情况。当然也可以返回错误消息。
+
+当然调用者可以不Sleep，而是直接重试，这种方法叫做**忙等待或者自旋等待（busy waiting or spin waiting. ）**，如果换成很长时间都不变，那么这将会消耗大量的CPU时间！！！所以调用者自己休眠，sleep让出CPU。但是这个时间就很尴尬了，sleep长了万一一会前提条件就满足了岂不是白等了从而响应性低，sleep短了浪费CPU时钟周期。另外可以试试yield，但是这也不靠谱。
+
+```
+@ThreadSafe
+        public class GrumpyBoundedBuffer <V> extends BaseBoundedBuffer<V> {
+    public GrumpyBoundedBuffer() {
+        this(100);
+    }
+
+    public GrumpyBoundedBuffer(int size) {
+        super(size);
+    }
+
+    public synchronized void put(V v) throws BufferFullException {
+        if (isFull())
+            throw new BufferFullException();
+        doPut(v);
+    }
+
+    public synchronized V take() throws BufferEmptyException {
+        if (isEmpty())
+            throw new BufferEmptyException();
+        return doTake();
+    }
+}
+
+class ExampleUsage {
+    private GrumpyBoundedBuffer<String> buffer;
+    int SLEEP_GRANULARITY = 50;
+
+    void useBuffer() throws InterruptedException {
+        while (true) {
+            try {
+                String item = buffer.take();
+                // use item
+                break;
+            } catch (BufferEmptyException e) {
+                Thread.sleep(SLEEP_GRANULARITY);
+            }
+        }
+    }
+}
+
+```
+
+下一步改进下，首先让客户端舒服些。
+
+```
+@ThreadSafe
+public class SleepyBoundedBuffer <V> extends BaseBoundedBuffer<V> {
+    int SLEEP_GRANULARITY = 60;
+
+    public SleepyBoundedBuffer() {
+        this(100);
+    }
+
+    public SleepyBoundedBuffer(int size) {
+        super(size);
+    }
+
+    public void put(V v) throws InterruptedException {
+        while (true) {
+            synchronized (this) {
+                if (!isFull()) {
+                    doPut(v);
+                    return;
+                }
+            }
+            Thread.sleep(SLEEP_GRANULARITY);
+        }
+    }
+
+    public V take() throws InterruptedException {
+        while (true) {
+            synchronized (this) {
+                if (!isEmpty())
+                    return doTake();
+            }
+            Thread.sleep(SLEEP_GRANULARITY);
+        }
+    }
+}
+
+```
+
+这种方式测试失败，那么释放锁，让别人做，自己休眠下，然后再检测，不断的重复这个过程，当然可以解决，但是还是需要做权衡，CPU使用率与响应性之间的抉择。
+
+那么我们想如果这种轮询和休眠的dummy方式不用，而是存在某种挂起线程的方案，并且这种方法能够确保党某个条件成真时候立刻唤醒线程，那么将极大的简化实现工作，这就是条件队列的实现。
+
+Condition Queues的名字来源：it gives a group of threads called the **wait set** a way to wait for a specific condition to become true. Unlike typical queues in which the elements are data items, the elements of a condition queue are the threads waiting for the condition.
+
+每个Java对象都可以是一个锁，每个对象同样可以作为一个条件队列，并且Object的wait、notify和notifyAll就是内部条件队列的API。对象的内置锁（intrinsic lock ）和内置条件队列是关联的，**要调用X中的条件队列的任何一个方法，都必须持有对象X上的锁。**
+
+Object.wait自动释放锁，并且请求操作系统挂起当前线程，从而其他线程可以获得这个锁并修改对象状态。当被挂起的线程唤醒时。它将在返回之前重新获取锁。
+
+```
+@ThreadSafe
+public class BoundedBuffer <V> extends BaseBoundedBuffer<V> {
+    // CONDITION PREDICATE: not-full (!isFull())
+    // CONDITION PREDICATE: not-empty (!isEmpty())
+    public BoundedBuffer() {
+        this(100);
+    }
+
+    public BoundedBuffer(int size) {
+        super(size);
+    }
+
+    // BLOCKS-UNTIL: not-full
+    public synchronized void put(V v) throws InterruptedException {
+        while (isFull())
+            wait();
+        doPut(v);
+        notifyAll();
+    }
+
+    // BLOCKS-UNTIL: not-empty
+    public synchronized V take() throws InterruptedException {
+        while (isEmpty())
+            wait();
+        V v = doTake();
+        notifyAll();
+        return v;
+    }
+
+    // BLOCKS-UNTIL: not-full
+    // Alternate form of put() using conditional notification
+    public synchronized void alternatePut(V v) throws InterruptedException {
+        while (isFull())
+            wait();
+        boolean wasEmpty = isEmpty();
+        doPut(v);
+        if (wasEmpty)
+            notifyAll();
+    }
+}
+
+```
+
+注意，如果某个功能无法通过“轮询和休眠"来实现，那么条件队列也无法实现。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#142-using-condition-queues)14.2 Using Condition Queues
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1421-%E6%9D%A1%E4%BB%B6%E8%B0%93%E8%AF%8Dthe-condition-predicate)14.2.1 条件谓词The Condition Predicate
+
+The Condition Predicate 是使某个操作成为状态依赖操作的前提条件。take方法的条件谓词是”缓存不为空“，take方法在执行之前必须首先测试条件谓词。同样，put方法的条件谓词是”缓存不满“。
+
+在条件等待中存在一种重要的三元关系，包括
+
+*   加锁
+*   wait方法
+*   条件谓词
+
+条件谓词中包含多个状态变量，而状态变量由一个锁来保护，因此在测试条件谓词之前必须先持有这个锁。锁对象和条件队列对象必须是同一个对象。wait释放锁，线程挂起阻塞，等待知道超时，然后被另外一个线程中断或者被一个通知唤醒。唤醒后，wait在返回前还需要重新获取锁，当线程从wait方法中唤醒，它在重新请求锁时不具有任何特殊的优先级，和其他人一起竞争。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1422-%E8%BF%87%E6%97%A9%E5%94%A4%E9%86%92)14.2.2 过早唤醒
+
+其他线程中间插足了，获取了锁，并且修改了遍历，这时候线程获取锁需要重新检查条件谓词。
+
+```
+wait block ----------race to get lock ------------------------------------------get lock ----- 
+                    ^
+wait block --------> race to get lock ------get lock------> perform action  ---> release lock
+                    ^
+                    notifyAll
+
+```
+
+当然有的时候，比如一个你根本不知道为什么别人调用了notify或者notifyAll，也许条件谓词压根就没满足，但是线程还是获取了锁，然后test条件谓词，释放所，其他线程都来了这么一趟，发生这就是“谎报军情”啊。
+
+基于以上这两种情况，都必须重新测试条件谓词。
+
+When using condition waits (Object.wait or Condition.await):
+
+*   Always have a condition predicate——some test of object state that must hold before proceeding;
+*   Always test the condition predicate before calling wait, and again after returning from wait;
+*   Always call wait in a loop;
+*   Ensure that the state variables making up the condition predicate are guarded by the lock associated with the condition queue;
+*   Hold the lock associated with the the condition queue when calling wait, notify, or notifyAll
+*   Do not release the lock after checking the condition predicate but before acting on it.
+
+模板就是：
+
+```
+void stateDependentMethod() throws InterruptedException {
+ // condition predicate must be guarded by lock
+ synchronized(lock) {  
+     while (!conditionPredicate())  //一定在循环里面做条件谓词
+         lock.wait();  //确保和synchronized的是一个对象
+     // object is now in desired state  //不要释放锁
+ }
+} 
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1423-%E4%B8%A2%E5%A4%B1%E7%9A%84%E4%BF%A1%E5%8F%B7)14.2.3 丢失的信号
+
+保证notify一定在wait之后
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1424-%E9%80%9A%E7%9F%A5)14.2.4 通知
+
+下面介绍通知。
+
+调用notify和notifyAll也得持有与条件队列对象相关联的锁。调用notify，JVM Thread Scheduler在这个条件队列上等待的多个线程中选择一个唤醒，而notifyAll则会唤醒所有线程。因此一旦notify了那么就需要尽快的释放锁，否则别人都竞争等着拿锁，都会进行blocked的状态，而不是线程挂起waiting状态，竞争都了不是好事，但是这是你考了性能因素和安全性因素的一个矛盾，具体问题要具体分析。
+
+下面的方法可以进来减少竞争，但是确然程序正确的实现有些难写，所以这个折中还得自己考虑：
+
+```
+public synchronized void alternatePut(V v) throws InterruptedException {
+        while (isFull())
+            wait();
+        boolean wasEmpty = isEmpty();
+        doPut(v);
+        if (wasEmpty)
+            notifyAll();
+    }
+
+```
+
+使用notify容易丢失信号，所以大多数情况下用notifyAll，比如take notify，却通知了另外一个take，没有通知put，那么这就是信号丢失，是一种“被劫持的”信号。
+
+因此只有满足下面两个条件，才能用notify，而不是notifyAll：
+
+*   所有等待线程的类型都相同
+*   单进单出
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1425-%E7%A4%BA%E4%BE%8B%E9%98%80%E9%97%A8%E7%B1%BBa-gate-class)14.2.5 示例：阀门类A Gate Class
+
+和第5章的那个TestHarness中使用CountDownLatch类似，完全可以使用wait/notifyAll做阀门。
+
+```
+@ThreadSafe
+public class ThreadGate {
+    // CONDITION-PREDICATE: opened-since(n) (isOpen || generation>n)
+    @GuardedBy("this") private boolean isOpen;
+    @GuardedBy("this") private int generation;
+
+    public synchronized void close() {
+        isOpen = false;
+    }
+
+    public synchronized void open() {
+        ++generation;
+        isOpen = true;
+        notifyAll();
+    }
+
+    // BLOCKS-UNTIL: opened-since(generation on entry)
+    public synchronized void await() throws InterruptedException {
+        int arrivalGeneration = generation;
+        while (!isOpen && arrivalGeneration == generation)
+            wait();
+    }
+}
+
+```
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#143-explicit-condition-objects)14.3 Explicit Condition Objects
+
+Lock是一个内置锁的替代，而Condition也是一种广义的**内置条件队列**。
+
+Condition的API如下：
+
+```
+public interface Condition {
+ void await() throws InterruptedException;
+ boolean await(long time, TimeUnit unit)throws InterruptedException;
+ long awaitNanos(long nanosTimeout) throws InterruptedException;
+ void awaitUninterruptibly();
+ boolean awaitUntil(Date deadline) throws InterruptedException;
+ void signal();
+ void signalAll();
+}
+
+```
+
+内置条件队列存在一些缺陷，每个内置锁都只能有一个相关联的条件队列，记住是**一个**。所以在BoundedBuffer这种累中，**多个线程可能在同一个条件队列上等待不同的条件谓词**，所以notifyAll经常通知不是同一个类型的需求。如果想编写一个带有多个条件谓词的并发对象，或者想获得除了条件队列可见性之外的更多的控制权，可以使用Lock和Condition，而不是内置锁和条件队列，这更加灵活。
+
+一个Condition和一个lock关联，想象一个条件队列和内置锁关联一样。在Lock上调用newCondition就可以新建无数个条件谓词，这些condition是可中断的、可有时间限制的，公平的或者非公平的队列操作。
+
+The equivalents of wait, notify, and notifyAll for Condition objects are await, signal, and signalAll。
+
+下面的例子就是改造后的BoundedBuffer，
+
+```
+@ThreadSafe
+public class ConditionBoundedBuffer <T> {
+    protected final Lock lock = new ReentrantLock();
+    // CONDITION PREDICATE: notFull (count < items.length)
+    private final Condition notFull = lock.newCondition();
+    // CONDITION PREDICATE: notEmpty (count > 0)
+    private final Condition notEmpty = lock.newCondition();
+    private static final int BUFFER_SIZE = 100;
+    @GuardedBy("lock") private final T[] items = (T[]) new Object[BUFFER_SIZE];
+    @GuardedBy("lock") private int tail, head, count;
+
+    // BLOCKS-UNTIL: notFull
+    public void put(T x) throws InterruptedException {
+        lock.lock();
+        try {
+            while (count == items.length)
+                notFull.await();
+            items[tail] = x;
+            if (++tail == items.length)
+                tail = 0;
+            ++count;
+            notEmpty.signal();
+        } finally {
+            lock.unlock();
+        }
+    }
+
+    // BLOCKS-UNTIL: notEmpty
+    public T take() throws InterruptedException {
+        lock.lock();
+        try {
+            while (count == 0)
+                notEmpty.await();
+            T x = items[head];
+            items[head] = null;
+            if (++head == items.length)
+                head = 0;
+            --count;
+            notFull.signal();
+            return x;
+        } finally {
+            lock.unlock();
+        }
+    }
+}
+
+```
+
+注意这里使用了signal而不是signalll，能极大的减少每次缓存操作中发生的上下文切换和锁请求次数。
+
+使用condition和内置锁和条件队列一样，必须保卫在lock里面。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#144-synchronizer%E5%89%96%E6%9E%90)14.4 Synchronizer剖析
+
+看似ReentrantLock和Semaphore功能很类似，每次只允许一定的数量线程通过，到达阀门时
+
+*   可以通过 lock或者acquire
+*   等待，阻塞住了
+*   取消tryLock，tryAcquire
+*   可中断的，限时的
+*   公平等待和非公平等待
+
+下面的程序是使用Lock做一个Mutex也就是持有一个许可的Semaphore。
+
+```
+@ThreadSafe
+public class SemaphoreOnLock {
+    private final Lock lock = new ReentrantLock();
+    // CONDITION PREDICATE: permitsAvailable (permits > 0)
+    private final Condition permitsAvailable = lock.newCondition();
+    @GuardedBy("lock") private int permits;
+
+    SemaphoreOnLock(int initialPermits) {
+        lock.lock();
+        try {
+            permits = initialPermits;
+        } finally {
+            lock.unlock();
+        }
+    }
+
+    // BLOCKS-UNTIL: permitsAvailable
+    public void acquire() throws InterruptedException {
+        lock.lock();
+        try {
+            while (permits <= 0)
+                permitsAvailable.await();
+            --permits;
+        } finally {
+            lock.unlock();
+        }
+    }
+
+    public void release() {
+        lock.lock();
+        try {
+            ++permits;
+            permitsAvailable.signal();
+        } finally {
+            lock.unlock();
+        }
+    }
+}
+
+```
+
+实际上很多J.U.C下面的类都是基于AbstractQueuedSynchronizer (AQS)构建的，例如CountDownLatch, ReentrantReadWriteLock, SynchronousQueue,and FutureTask（java7之后不是了）。AQS解决了实现同步器时设计的大量细节问题，例如等待线程采用FIFO队列操作顺序。AQS不仅能极大极少实现同步器的工作量，并且也不必处理竞争问题，基于AQS构建只可能在一个时刻发生阻塞，从而降低上下文切换的开销，提高吞吐量。在设计AQS时，充分考虑了可伸缩性，可谓大师Doug Lea的经典作品啊！
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#145-abstractqueuedsynchronizer-aqs)14.5 AbstractQueuedSynchronizer (AQS)
+
+基于AQS构建的同步器勒种，最进步的操作包括各种形式的获取操作和释放操作。获取操作是一种依赖状态的操作，并且通常会阻塞。
+
+如果一个类想成为状态依赖的类，它必须拥有一些状态，AQS负责管理这些状态，通过getState,setState, compareAndSetState等protected类型方法进行操作。这是设计模式中的模板模式。
+
+使用AQS的模板如下：
+
+获取锁：首先判断当前状态是否允许获取锁，如果是就获取锁，否则就阻塞操作或者获取失败，也就是说如果是独占锁就可能阻塞，如果是共享锁就可能失败。另外如果是阻塞线程，那么线程就需要进入阻塞队列。当状态位允许获取锁时就修改状态，并且如果进了队列就从队列中移除。
+
+释放锁:这个过程就是修改状态位，如果有线程因为状态位阻塞的话就唤醒队列中的一个或者更多线程。
+
+```
+boolean acquire() throws InterruptedException {
+ while (state does not permit acquire) {
+ if (blocking acquisition requested) {
+ enqueue current thread if not already queued
+ block current thread
+ }
+ else
+ return failure
+ }
+ possibly update synchronization state
+ dequeue thread if it was queued
+ return success
+}
+void release() {
+ update synchronization state
+ if (new state may permit a blocked thread to acquire)
+ unblock one or more queued threads
+}
+
+```
+
+要支持上面两个操作就必须有下面的条件：
+
+*   原子性操作同步器的状态位
+*   阻塞和唤醒线程
+*   一个有序的队列
+
+**1 状态位的原子操作**
+
+这里使用一个32位的整数来描述状态位，前面章节的原子操作的理论知识整好派上用场，在这里依然使用CAS操作来解决这个问题。事实上这里还有一个64位版本的同步器（AbstractQueuedLongSynchronizer），这里暂且不谈。
+
+**2 阻塞和唤醒线程**
+
+标准的JAVA API里面是无法挂起（阻塞）一个线程，然后在将来某个时刻再唤醒它的。JDK 1.0的API里面有Thread.suspend和Thread.resume，并且一直延续了下来。但是这些都是过时的API，而且也是不推荐的做法。
+
+HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。
+
+在JDK 5.0以后利用JNI在LockSupport类中实现了此特性。
+
+> LockSupport.park() LockSupport.park(Object) LockSupport.parkNanos(Object, long) LockSupport.parkNanos(long) LockSupport.parkUntil(Object, long) LockSupport.parkUntil(long) LockSupport.unpark(Thread)
+
+上面的API中park()是在当前线程中调用，导致线程阻塞，带参数的Object是挂起的对象，这样监视的时候就能够知道此线程是因为什么资源而阻塞的。由于park()立即返回，所以通常情况下需要在循环中去检测竞争资源来决定是否进行下一次阻塞。park()返回的原因有三：
+
+*   其他某个线程调用将当前线程作为目标调用 [`unpark`](http://www.blogjava.net/xylz/java/util/concurrent/locks/LockSupport.html#unpark(java.lang.Thread))；
+*   其他某个线程[中断](http://www.blogjava.net/xylz/java/lang/Thread.html#interrupt())当前线程；
+*   该调用不合逻辑地（即毫无理由地）返回。
+
+其实第三条就决定了需要循环检测了，类似于通常写的while(checkCondition()){Thread.sleep(time);}类似的功能。
+
+**3 有序队列**
+
+在AQS中采用CHL列表来解决有序的队列的问题。
+
+AQS采用的CHL模型采用下面的算法完成FIFO的入队列和出队列过程。该队列的操作均通过Lock-Free（CAS）操作.
+
+自己实现的CLH SpinLock如下：
+
+```
+class ClhSpinLock {
+    private final ThreadLocal<Node> prev;
+    private final ThreadLocal<Node> node;
+    private final AtomicReference<Node> tail = new AtomicReference<Node>(new Node());
+
+    public ClhSpinLock() {
+        this.node = new ThreadLocal<Node>() {
+            protected Node initialValue() {
+                return new Node();
+            }
+        };
+
+        this.prev = new ThreadLocal<Node>() {
+            protected Node initialValue() {
+                return null;
+            }
+        };
+    }
+
+    public void lock() {
+        final Node node = this.node.get();
+        node.locked = true;
+        // 一个CAS操作即可将当前线程对应的节点加入到队列中，
+        // 并且同时获得了前继节点的引用，然后就是等待前继释放锁
+        Node pred = this.tail.getAndSet(node);
+        this.prev.set(pred);
+        while (pred.locked) {// 进入自旋
+        }
+    }
+
+    public void unlock() {
+        final Node node = this.node.get();
+        node.locked = false;
+        this.node.set(this.prev.get());
+    }
+
+    private static class Node {
+        private volatile boolean locked;
+    }
+}
+
+```
+
+对于入队列(*enqueue)：*采用CAS操作，每次比较尾结点是否一致，然后插入的到尾结点中。
+
+```
+do {
+        pred = tail;
+}while ( !compareAndSet(pred,tail,node) );
+
+```
+
+对于出队列(*dequeue*):由于每一个节点也缓存了一个状态，决定是否出队列，因此当不满足条件时就需要自旋等待，一旦满足条件就将头结点设置为下一个节点。
+
+AQS里面有三个核心字段：
+
+> private volatile int state;
+> 
+> private transient volatile Node head;
+> 
+> private transient volatile Node tail;
+
+其中state描述的有多少个线程取得了锁，对于互斥锁来说state<=1。head/tail加上CAS操作就构成了一个CHL的FIFO队列。下面是Node节点的属性。
+
+独占操作的API都是不带有shared，而共享的包括semaphore和countdownlatch都是使用带有shared字面的API。
+
+一些有用的参考资料：
+
+**java.util.concurrent.locks.AbstractQueuedSynchronizer - **AQS
+
+[http://gee.cs.oswego.edu/dl/papers/aqs.pdf](http://gee.cs.oswego.edu/dl/papers/aqs.pdf)论文
+
+[http://www.blogjava.net/xylz/archive/2010/07/08/325587.html](http://www.blogjava.net/xylz/archive/2010/07/08/325587.html) 一个比较全面的另外一个人的解读
+
+[http://suo.iteye.com/blog/1329460](http://suo.iteye.com/blog/1329460)
+
+[http://www.infoq.com/cn/articles/jdk1.8-abstractqueuedsynchronizer](http://www.infoq.com/cn/articles/jdk1.8-abstractqueuedsynchronizer)
+
+[http://www.cnblogs.com/zhanjindong/p/java-concurrent-package-aqs-overview.html](http://www.cnblogs.com/zhanjindong/p/java-concurrent-package-aqs-overview.html)
+
+[http://www.cnblogs.com/zhanjindong/p/java-concurrent-package-aqs-clh-and-spin-lock.html](http://www.cnblogs.com/zhanjindong/p/java-concurrent-package-aqs-clh-and-spin-lock.html)
+
+[http://www.cnblogs.com/zhanjindong/p/java-concurrent-package-aqs-locksupport-and-thread-interrupt.html](http://www.cnblogs.com/zhanjindong/p/java-concurrent-package-aqs-locksupport-and-thread-interrupt.html)
+
+独占的就用TRyAcquire, TRyRelease, and isHeldExclusively,共享的就用 tryAcquireShared and TRyReleaseShared. 带有try前缀的方法都是模板方法，AQS用于判断是否可以继续，例如如果tryAcquireShared返回一个负值，那么表示获取锁失败，失败的就需要进入CLH队列，并且挂起线程。
+
+举一个例子，一个简单的闭锁。
+
+```
+@ThreadSafe
+public class OneShotLatch {
+    private final Sync sync = new Sync();
+
+    public void signal() {
+        sync.releaseShared(0);
+    }
+
+    public void await() throws InterruptedException {
+        sync.acquireSharedInterruptibly(0);
+    }
+
+    private class Sync extends AbstractQueuedSynchronizer {
+        protected int tryAcquireShared(int ignored) {
+            // Succeed if latch is open (state == 1), else fail
+            return (getState() == 1) ? 1 : -1;
+        }
+
+        protected boolean tryReleaseShared(int ignored) {
+            setState(1); // Latch is now open
+            return true; // Other threads may now be able to acquire
+
+        }
+    }
+}
+
+```
+
+下面是自己实现的一个Mutex。
+
+```
+/**
+ * Lock free的互斥锁，简单实现，不可重入锁
+ */
+public class Mutex implements Lock {
+
+    private static final int FREE = 0;
+    private static final int BUSY = 1;
+
+    private static class LockSync extends AbstractQueuedSynchronizer {
+
+        private static final long serialVersionUID = 4689388770786922019L;
+
+        protected boolean isHeldExclusively() {
+            return getState() == BUSY;
+        }
+
+        public boolean tryAcquire(int acquires) {
+            return compareAndSetState(FREE, BUSY);
+        }
+
+        protected boolean tryRelease(int releases) {
+            if (getState() == FREE) {
+                throw new IllegalMonitorStateException();
+            }
+
+            setState(FREE);
+            return true;
+        }
+
+        Condition newCondition() {
+            return new ConditionObject();
+        }
+
+    }
+
+    private final LockSync sync = new LockSync();
+
+    public void lock() {
+        sync.acquire(0);
+    }
+
+    public boolean tryLock() {
+        return sync.tryAcquire(0);
+    }
+
+    public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
+        return sync.tryAcquireNanos(1, unit.toNanos(timeout));
+    }
+
+    public void unlock() {
+        sync.release(0);
+    }
+
+    public Condition newCondition() {
+        return sync.newCondition();
+    }
+
+    public boolean isLocked() {
+        return sync.isHeldExclusively();
+    }
+
+    public boolean hasQueuedThreads() {
+        return sync.hasQueuedThreads();
+    }
+
+    public void lockInterruptibly() throws InterruptedException {
+        sync.acquireInterruptibly(0);
+    }
+
+}
+
+```
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#146-juc%E5%90%8C%E6%AD%A5%E5%99%A8%E5%8B%92%E7%A7%8D%E7%9A%84aqs)14.6 J.U.C同步器勒种的AQS
+
+*   ReentrantLock
+
+```
+protected boolean tryAcquire(int ignored) {
+ final Thread current = Thread.currentThread();
+ int c = getState();
+ if (c == 0) {
+ if (compareAndSetState(0, 1)) {
+ owner = current;
+ return true;
+ }
+ } else if (current == owner) {
+ setState(c+1);
+ return true;
+ }
+ return false;
+} 
+
+```
+
+*   Semaphore和CountDownLatch
+
+```
+protected int tryAcquireShared(int acquires) {
+ while (true) {
+ int available = getState();
+ int remaining = available - acquires;
+ if (remaining < 0
+ || compareAndSetState(available, remaining))
+ return remaining;
+ }
+}
+protected boolean tryReleaseShared(int releases) {
+ while (true) {
+ int p = getState();
+ if (compareAndSetState(p, p + releases))
+ return true;
+ }
+} 
+```
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22715\344\271\213\345\216\237\345\255\220\351\201\215\345\216\206\344\270\216\351\235\236\351\230\273\345\241\236\345\220\214\346\255\245\346\234\272\345\210\266(Atomic-Variables-and-Non-blocking-Synchron.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22715\344\271\213\345\216\237\345\255\220\351\201\215\345\216\206\344\270\216\351\235\236\351\230\273\345\241\236\345\220\214\346\255\245\346\234\272\345\210\266(Atomic-Variables-and-Non-blocking-Synchron.md"
new file mode 100644
index 0000000000..4c9f9c8bb7
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22715\344\271\213\345\216\237\345\255\220\351\201\215\345\216\206\344\270\216\351\235\236\351\230\273\345\241\236\345\220\214\346\255\245\346\234\272\345\210\266(Atomic-Variables-and-Non-blocking-Synchron.md"
@@ -0,0 +1,300 @@
+近年来，在并发算法领域的大多数研究都侧重于非阻塞算法，这种算法用底层的原子机器指令来代替锁来确保数据在并发访问中的一致性，非阻塞算法被广泛应用于OS和JVM中实现线程/进程调度机制和GC以及锁，并发数据结构中。
+
+与锁的方案相比，非阻塞算法都要复杂的多，他们在可伸缩性和活跃性上（避免死锁）都有巨大的优势。
+
+非阻塞算法，顾名思义，多个线程竞争相同的数据时不会发生阻塞，因此他能在粒度更细的层次上进行协调，而且极大的减少调度开销。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#151-%E9%94%81%E7%9A%84%E5%8A%A3%E5%8A%BF)15.1 锁的劣势
+
+独占，可见性是锁要保证的。
+
+许多JVM都对非竞争的锁获取和释放做了很多优化，性能很不错了。但是如果一些线程被挂起然后稍后恢复运行，当线程恢复后还得等待其他线程执行完他们的时间片，才能被调度，所以挂起和恢复线程存在很大的开销，其实很多锁的力度很小的，很简单，如果锁上存在着激烈的竞争，那么多调度开销/工作开销比值就会非常高。
+
+与锁相比volatile是一种更轻量的同步机制，因为使用volatile不会发生上下文切换或者线程调度操作，但是volatile的指明问题就是虽然保证了可见性，但是原子性无法保证，比如i++的字节码就是N行。
+
+锁的其他缺点还包括，如果一个线程正在等待锁，它不能做任何事情，如果一个线程在持有锁的情况下呗延迟执行了，例如发生了缺页错误，调度延迟，那么就没法执行。如果被阻塞的线程优先级较高，那么就会出现priority invesion的问题，被永久的阻塞下去。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#152-%E7%A1%AC%E4%BB%B6%E5%AF%B9%E5%B9%B6%E5%8F%91%E7%9A%84%E6%94%AF%E6%8C%81)15.2 硬件对并发的支持
+
+独占锁是悲观所，对于细粒度的操作，更高效的应用是乐观锁，这种方法需要借助**冲突监测机制来判断更新过程中是否存在来自其他线程的干扰，如果存在则失败重试**。
+
+几乎所有的现代CPU都有某种形式的原子读-改-写指令，例如compare-and-swap等，JVM就是使用这些指令来实现无锁并发。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1521-%E6%AF%94%E8%BE%83%E5%B9%B6%E4%BA%A4%E6%8D%A2)15.2.1 比较并交换
+
+CAS（Compare and set）乐观的技术。Java实现的一个compare and set如下，这是一个模拟底层的示例：
+
+```
+@ThreadSafe
+public class SimulatedCAS {
+    @GuardedBy("this") private int value;
+
+    public synchronized int get() {
+        return value;
+    }
+
+    public synchronized int compareAndSwap(int expectedValue,
+                                           int newValue) {
+        int oldValue = value;
+        if (oldValue == expectedValue)
+            value = newValue;
+        return oldValue;
+    }
+
+    public synchronized boolean compareAndSet(int expectedValue,
+                                              int newValue) {
+        return (expectedValue
+                == compareAndSwap(expectedValue, newValue));
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1522-%E9%9D%9E%E9%98%BB%E5%A1%9E%E7%9A%84%E8%AE%A1%E6%95%B0%E5%99%A8)15.2.2 非阻塞的计数器
+
+```
+public class CasCounter {
+    private SimulatedCAS value;
+
+    public int getValue() {
+        return value.get();
+    }
+
+    public int increment() {
+        int v;
+        do {
+            v = value.get();
+        } while (v != value.compareAndSwap(v, v + 1));
+        return v + 1;
+    }
+}
+
+```
+
+Java中使用AtomicInteger。
+
+首先在竞争激烈一般时候，CAS性能远超过第三章基于锁的计数器。看起来他的指令更多，但是无需上下文切换和线程挂起，JVM内部的代码路径实际很长，所以反而好些。但是激烈程度比较高的时候，它的开销还是比较大，但是你会发生这种激烈程度非常高的情况只是理论，实际生产环境很难遇到。况且JIT很聪明，这种操作往往能非常大的优化。
+
+为了确保正常更新，可能得将CAS操作放到for循环里，从语法结构上来看，使用**CAS**比使用锁更加复杂，得考虑失败的情况（锁会挂起线程，直到恢复）；但是基于**CAS**的原子操作，在性能上基本超过了基于锁的计数器，即使只有很小的竞争或者不存在竞争！
+
+在轻度到中度的争用情况下，非阻塞算法的性能会超越阻塞算法，因为 CAS 的多数时间都在第一次尝试时就成功，而发生争用时的开销也不涉及**线程挂起**和**上下文切换**，只多了几个循环迭代。没有争用的 CAS 要比没有争用的锁便宜得多（这句话肯定是真的，因为没有争用的锁涉及 CAS 加上额外的处理，加锁至少需要一个CAS，在有竞争的情况下，需要操作队列，线程挂起，上下文切换），而争用的 CAS 比争用的锁获取涉及更短的延迟。
+
+CAS的缺点是它使用调用者来处理竞争问题，通过重试、回退、放弃，而锁能自动处理竞争问题，例如阻塞。
+
+原子变量可以看做更好的volatile类型变量。
+
+AtomicInteger在JDK8里面做了改动。
+
+```
+public final int getAndIncrement() {
+    return unsafe.getAndAddInt(this, valueOffset, 1);
+}
+
+```
+
+JDK7里面的实现如下：
+
+```
+public final int getAndAdd(int delta) {
+       for(;;) {
+           intcurrent= get();
+           intnext=current+delta;
+           if(compareAndSet(current,next))
+               returncurrent;
+        }
+    }
+
+```
+
+Unsafe是经过特殊处理的，不能理解成常规的java代码，区别在于：
+
+*   1.8在调用getAndAddInt的时候，如果系统底层支持fetch-and-add，那么它执行的就是native方法，使用的是fetch-and-add；
+
+*   如果不支持，就按照上面的所看到的getAndAddInt方法体那样，以java代码的方式去执行，使用的是compare-and-swap；
+
+这也正好跟openjdk8中Unsafe::getAndAddInt上方的注释相吻合：
+
+```
+// The following contain CAS-based Java implementations used on
+// platforms not supporting native instructions
+
+```
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#153-%E5%8E%9F%E5%AD%90%E5%8F%98%E9%87%8F%E7%B1%BB)15.3 原子变量类
+
+J.U.C的AtomicXXX
+
+例如一个AtomictReference的使用如下：
+
+```
+public class CasNumberRange {
+    @Immutable
+            private static class IntPair {
+        // INVARIANT: lower <= upper
+        final int lower;
+        final int upper;
+
+        public IntPair(int lower, int upper) {
+            this.lower = lower;
+            this.upper = upper;
+        }
+    }
+
+    private final AtomicReference<IntPair> values =
+            new AtomicReference<IntPair>(new IntPair(0, 0));
+
+    public int getLower() {
+        return values.get().lower;
+    }
+
+    public int getUpper() {
+        return values.get().upper;
+    }
+
+    public void setLower(int i) {
+        while (true) {
+            IntPair oldv = values.get();
+            if (i > oldv.upper)
+                throw new IllegalArgumentException("Can't set lower to " + i + " > upper");
+            IntPair newv = new IntPair(i, oldv.upper);
+            if (values.compareAndSet(oldv, newv))
+                return;
+        }
+    }
+
+    public void setUpper(int i) {
+        while (true) {
+            IntPair oldv = values.get();
+            if (i < oldv.lower)
+                throw new IllegalArgumentException("Can't set upper to " + i + " < lower");
+            IntPair newv = new IntPair(oldv.lower, i);
+            if (values.compareAndSet(oldv, newv))
+                return;
+        }
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1532-%E6%80%A7%E8%83%BD%E6%AF%94%E8%BE%83%E9%94%81%E4%B8%8E%E5%8E%9F%E5%AD%90%E5%8F%98%E9%87%8F)15.3.2 性能比较：锁与原子变量
+
+略
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#154-%E9%9D%9E%E9%98%BB%E5%A1%9E%E7%AE%97%E6%B3%95)15.4 非阻塞算法
+
+Lock-free算法，可以实现栈、队列、优先队列或者散列表。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#154-%E9%9D%9E%E9%98%BB%E5%A1%9E%E7%9A%84%E6%A0%88)15.4 非阻塞的栈
+
+Trebier算法，1986年提出的。
+
+```
+ public class ConcurrentStack <E> {
+    AtomicReference<Node<E>> top = new AtomicReference<Node<E>>();
+
+    public void push(E item) {
+        Node<E> newHead = new Node<E>(item);
+        Node<E> oldHead;
+        do {
+            oldHead = top.get();
+            newHead.next = oldHead;
+        } while (!top.compareAndSet(oldHead, newHead));
+    }
+
+    public E pop() {
+        Node<E> oldHead;
+        Node<E> newHead;
+        do {
+            oldHead = top.get();
+            if (oldHead == null)
+                return null;
+            newHead = oldHead.next;
+        } while (!top.compareAndSet(oldHead, newHead));
+        return oldHead.item;
+    }
+
+    private static class Node <E> {
+        public final E item;
+        public Node<E> next;
+
+        public Node(E item) {
+            this.item = item;
+        }
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1542-%E9%9D%9E%E9%98%BB%E5%A1%9E%E7%9A%84%E9%93%BE%E8%A1%A8)15.4.2 非阻塞的链表
+
+有点复杂哦，实际J.U.C的ConcurrentLinkedQueue也是参考了这个由Michael and Scott，1996年实现的算法。
+
+```
+public class LinkedQueue <E> {
+
+    private static class Node <E> {
+        final E item;
+        final AtomicReference<LinkedQueue.Node<E>> next;
+
+        public Node(E item, LinkedQueue.Node<E> next) {
+            this.item = item;
+            this.next = new AtomicReference<LinkedQueue.Node<E>>(next);
+        }
+    }
+
+    private final LinkedQueue.Node<E> dummy = new LinkedQueue.Node<E>(null, null);
+    private final AtomicReference<LinkedQueue.Node<E>> head
+            = new AtomicReference<LinkedQueue.Node<E>>(dummy);
+    private final AtomicReference<LinkedQueue.Node<E>> tail
+            = new AtomicReference<LinkedQueue.Node<E>>(dummy);
+
+    public boolean put(E item) {
+        LinkedQueue.Node<E> newNode = new LinkedQueue.Node<E>(item, null);
+        while (true) {
+            LinkedQueue.Node<E> curTail = tail.get();
+            LinkedQueue.Node<E> tailNext = curTail.next.get();
+            if (curTail == tail.get()) {
+                if (tailNext != null) {
+                    // Queue in intermediate state, advance tail
+                    tail.compareAndSet(curTail, tailNext);
+                } else {
+                    // In quiescent state, try inserting new node
+                    if (curTail.next.compareAndSet(null, newNode)) {
+                        // Insertion succeeded, try advancing tail
+                        tail.compareAndSet(curTail, newNode);
+                        return true;
+                    }
+                }
+            }
+        }
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1543-%E5%8E%9F%E5%AD%90%E5%9F%9F%E6%9B%B4%E6%96%B0)15.4.3 原子域更新
+
+AtomicReferenceFieldUpdater,一个基于反射的工具类，它能对指定类的指定的volatile引用字段进行原子更新。(注意这个字段不能是private的) 
+
+通过调用AtomicReferenceFieldUpdater的静态方法newUpdater就能创建它的实例，该方法要接收三个参数： 
+
+*   包含该字段的对象的类 
+*   将被更新的对象的类 
+*   将被更新的字段的名称 
+
+```
+AtomicReferenceFieldUpdater updater=AtomicReferenceFieldUpdater.newUpdater(Dog.class,String.class,"name");  
+        Dog dog1=new Dog();  
+        updater.compareAndSet(dog1,dog1.name,"test") ;  
+        System.out.println(dog1.name);  
+
+class Dog  {  
+     volatile  String name="dog1";  
+
+}  
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1544-aba%E9%97%AE%E9%A2%98)15.4.4 ABA问题
+
+AtomicStampedReference //TODO
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22716\344\271\213Java\345\206\205\345\255\230\346\250\241\345\236\213(JMM).md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22716\344\271\213Java\345\206\205\345\255\230\346\250\241\345\236\213(JMM).md"
new file mode 100644
index 0000000000..39bcbed06c
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\22716\344\271\213Java\345\206\205\345\255\230\346\250\241\345\236\213(JMM).md"
@@ -0,0 +1,326 @@
+前面几章介绍的安全发布、同步策略的规范还有一致性，这些安全性都来自于JMM。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#161-%E4%BB%80%E4%B9%88%E6%98%AF%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81%E5%AE%83)16.1 什么是内存模型，为什么需要它？
+
+假设
+
+```
+a=3
+
+```
+
+内存模型要解决的问题是：“在什么条件下，读取a的线程可以看到这个值为3？”
+
+如果缺少同步会有很多因素导致无法立即、甚至永远看不到一个线程的操作结果，包括
+
+*   编译器中指令顺序
+*   变量保存在寄存器而不是内存中
+*   处理器可以乱序或者并行执行指令
+*   缓存可能会改变将写入变量提交到主内存的次序
+*   处理器中也有本地缓存，对其他处理器不可见
+
+单线程中，会为了提高速度使用这些技术，但是Java语言规范要求JVM在线程中维护一种类似串行的语义：只要程序的最终结果与在严格环境中的执行结果相同，那么上述操作都是允许的。
+
+随着处理器越来越强大，编译器也在不断的改进，通过指令重排序实现优化执行，使用成熟的全局寄存器分配算法，但是单处理器存在瓶颈，转而变为多核，提高并行性。
+
+在多线程环境中，维护程序的串行性将导致很大的性能开销，并发程序中的线程，大多数时间各自为政，线程之间协调操作只会降低应用程序的运行速度，不会带来任何好处，只有当多个线程要共享数据时，才必须协调他们之间的操作，并且JVM依赖程序通过同步操作找出这些协调操作将何时发生。
+
+JMM规定了JVM必须遵循一组最小的保证，**保证规定了对变量的写入操作在何时将对其他线程可见。**JMM需要在各个处理器体系架构中实现一份。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1611-%E5%B9%B3%E5%8F%B0%E7%9A%84%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B)16.1.1 平台的内存模型
+
+在共享内存的多处理器体系架构中，每个处理器拥有自己的缓存，并且定期的与主内存进行协调。在不同的处理器架构中提供了不同级别的缓存一致性（cache coherence）。其中一部分只提供最小的保证，即允许不同的处理器在任意时刻从同一个存储位置上看到不同的值。操作系统、编译器以及runtime需要弥补这种硬件能力与线程安全需求之间的差异。
+
+要确保每个处理器在任意时刻都知道其他处理器在进行的工作，这将开销巨大。多数情况下，这完全没必要，可随意放宽存储一致性，换取性能的提升。存在一些特殊的指令（成为内存栅栏），当需要共享数据时，这些指令就能实现额外的存储协调保证。为了使Java开发人员无须关心不同架构上内存模型之间的差异，产生了JMM，JVM通过在适当的位置上插入内存栅栏来屏蔽JMM与底层平台内存模型之间的差异。
+
+按照程序的顺序执行，这种乐观的串行一致性在任何一款现代多处理器架构中都不会提供这种串行一致性。当跨线程共享数据时，会出现一些奇怪的情况，除非通过使用内存栅栏来防止这种情况的发生。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1612-%E9%87%8D%E6%8E%92%E5%BA%8F)16.1.2 重排序
+
+下面的代码，4中输出都是有可能的。
+
+```
+public class ReorderingDemo {
+
+    static int x = 0, y = 0, a = 0, b = 0;
+
+    public static void main(String[] args) throws Exception {
+        Bag bag = new HashBag();
+        for (int i = 0; i < 10000; i++) {
+            x = y = a = b = 0;
+            Thread one = new Thread() {
+                public void run() {
+                    a = 1;
+                    x = b;
+                }
+            };
+            Thread two = new Thread() {
+                public void run() {
+                    b = 1;
+                    y = a;
+                }
+            };
+            one.start();
+            two.start();
+            one.join();
+            two.join();
+            bag.add(x + "_" + y);
+        }
+        System.out.println(bag.getCount("0_1"));
+        System.out.println(bag.getCount("1_0"));
+        System.out.println(bag.getCount("1_1"));
+        System.out.println(bag.getCount("0_0"));
+        // 结果是如下的或者其他情况，证明可能发生指令重排序
+        //        9999
+        //        1
+        //        0
+        //        0
+
+        //        9998
+        //        2
+        //        0
+        //        0
+    }
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1613-java%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B%E7%AE%80%E4%BB%8B)16.1.3 Java内存模型简介
+
+JMM通过各种操作来定义，包括对变量的读写操作，监视器monitor的加锁和释放操作，以及线程的启动和合并操作，JMM为程序中所有的操作定义了一个偏序关系，成为Happens-before，要想保证执行操作B的线程看到A的结果，那么A和B之间必须满足Happens-before关系。如果没有这个关系，JVM可以任意的重排序。
+
+**JVM来定义了JMM（Java内存模型）来屏蔽底层平台不同带来的各种同步问题，使得程序员面向JAVA平台预期的结果都是一致的，对于“共享的内存对象的访问保证因果性正是JMM存在的理由”（这句话说的太好了！！！）。**
+
+因为没法枚举各种情况，所以提供工具辅助程序员自定义，另外一些就是JMM提供的通用原则，叫做happens-before原则，就是如果动作B要看到动作A的执行结果（无论A/B是否在同一个线程里面执行），那么A/B就需要满足happens-before关系。下面是所有的规则，满足这些规则是一种特殊的处理措施，否则就按照上面背景提到的对于可见性、顺序性是没有保障的，会出现“意外”的情况。
+
+如果多线程写入遍历，没有happens-before来排序，那么会产生race condition。在正确使用同步的的程序中，不存在数据竞争，会表现出串行一致性。
+
+*   （1）同一个线程中的每个Action都happens-before于出现在其后的任何一个Action。//控制流，而非语句
+*   （2）对一个监视器的解锁happens-before于每一个后续对同一个监视器的加锁。//lock、unlock
+*   （3）对volatile字段的写入操作happens-before于每一个后续的同一个字段的读操作。
+*   （4）Thread.start()的调用会happens-before于启动线程里面的动作。
+*   （5）Thread中的所有动作都happens-before于其他线程检查到此线程结束或者Thread.join（）中返回或者Thread.isAlive()==false。
+*   （6）一个线程A调用另一个另一个线程B的interrupt（）都happens-before于线程A发现B被A中断（B抛出异常或者A检测到B的isInterrupted（）或者interrupted()）。
+*   （7）一个对象构造函数的结束happens-before与该对象的finalizer的开始
+*   （8）如果A动作happens-before于B动作，而B动作happens-before与C动作，那么A动作happens-before于C动作。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1614-%E5%80%9F%E5%8A%A9%E5%90%8C%E6%AD%A5)16.1.4 借助同步
+
+piggyback（借助）现有的同步机制可见性。例如在AQS中借助一个volatile的state变量保证happens-before进行排序。
+
+举例：Inner class of FutureTask illustrating synchronization piggybacking. (See JDK source)
+
+还可以记住CountDownLatch，Semaphore，Future，CyclicBarrier等完成自己的希望。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#162-%E5%8F%91%E5%B8%83)16.2 发布
+
+第三章介绍了如何安全的或者不正确的发布一个对象，其中介绍的各种技术都依赖JMM的保证，而造成发布不正确的原因就是
+
+*   发布一个共享对象
+*   另外一个线程访问该对象
+
+之间缺少一种happens-before关系。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1621-%E4%B8%8D%E5%AE%89%E5%85%A8%E7%9A%84%E5%8F%91%E5%B8%83)16.2.1 不安全的发布
+
+缺少happens-before就会发生重排序，会造成发布一个引用的时候，和内部各个field初始化重排序，比如
+
+```
+init field a
+init field b
+发布ref
+init field c
+
+```
+
+这时候从使用这角度就会看到一个被部分构造的对象。
+
+错误的延迟初始化将导致不正确的发布，如下代码。这段代码不光有race condition、创建低效等问题还存储在另外一个线程会看到部分构造的Resource实例引用。
+
+```
+@NotThreadSafe
+public class UnsafeLazyInitialization {
+    private static Resource resource;
+
+    public static Resource getInstance() {
+        if (resource == null)
+            resource = new Resource(); // unsafe publication
+        return resource;
+    }
+
+    static class Resource {
+    }
+}
+
+```
+
+那么，除非使用final，或者发布操作线程在使用线程开始之前执行，这些都满足了happens-before原则。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1622-%E5%AE%89%E5%85%A8%E7%9A%84%E5%8F%91%E5%B8%83)16.2.2 安全的发布
+
+使用第三章的各种技术可以安全发布对象，去报发布对象的操作在使用对象的线程开始使用对象的引用之前执行。如果A将X放入BlockingQueue，B从队列中获取X，那么B看到的X与A放入的X相同，实际上由于使用了锁保护，实际B能看到A移交X之前所有的操作。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1623-%E5%AE%89%E5%85%A8%E7%9A%84%E5%88%9D%E5%A7%8B%E5%8C%96%E6%A8%A1%E5%BC%8F)16.2.3 安全的初始化模式
+
+有时候需要延迟初始化，最简单的方法：
+
+```
+@ThreadSafe
+public class SafeLazyInitialization {
+    private static Resource resource;
+
+    public synchronized static Resource getInstance() {
+        if (resource == null)
+            resource = new Resource();
+        return resource;
+    }
+
+    static class Resource {
+    }
+}
+
+```
+
+如果getInstance调用不频繁，这绝对是最佳的。
+
+在初始化中使用static会提供额外的线程安全保证。静态初始化是由JVM在类的初始化阶段执行，并且在类被加载后，在线程使用前的。静态初始化期间，内存写入操作将自动对所有线程可见。因此静态初始化对象不需要显示的同步。下面的代码叫做eager initialization。
+
+```
+@ThreadSafe
+public class EagerInitialization {
+    private static Resource resource = new Resource();
+
+    public static Resource getResource() {
+        return resource;
+    }
+
+    static class Resource {
+    }
+}
+
+```
+
+下面是lazy initialization。JVM推迟ResourceHolder的初始化操作，直到开始使用这个类时才初始化，并且通过一个static来做，不需要额外的同步。
+
+```
+@ThreadSafe
+public class ResourceFactory {
+    private static class ResourceHolder {
+        public static Resource resource = new Resource();
+    }
+
+    public static Resource getResource() {
+        return ResourceFactory.ResourceHolder.resource;
+    }
+
+    static class Resource {
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#1624-%E5%8F%8C%E9%87%8D%E6%A3%80%E6%9F%A5%E5%8A%A0%E9%94%81cdl)16.2.4 双重检查加锁CDL
+
+DCL实际是一种糟糕的方式，是一种anti-pattern，它只在JAVA1.4时代好用，因为早期同步的性能开销较大，但是现在这都不是事了，已经不建议使用。
+
+```
+@NotThreadSafe
+public class DoubleCheckedLocking {
+    private static Resource resource;
+
+    public static Resource getInstance() {
+        if (resource == null) {
+            synchronized (DoubleCheckedLocking.class) {
+                if (resource == null)
+                    resource = new Resource();
+            }
+        }
+        return resource;
+    }
+
+    static class Resource {
+
+    }
+}
+
+```
+
+初始化instance变量的伪代码如下所示：
+
+```
+memory = allocate();   //1：分配对象的内存空间
+ctorInstance(memory);  //2：初始化对象
+instance = memory;     //3：设置instance指向刚分配的内存地址
+
+```
+
+之所以会发生上面我说的这种状况，是因为在一些编译器上存在指令排序，初始化过程可能被重排成这样：
+
+```
+memory = allocate();   //1：分配对象的内存空间
+instance = memory;     //3：设置instance指向刚分配的内存地址
+                       //注意，此时对象还没有被初始化！
+ctorInstance(memory);  //2：初始化对象
+
+```
+
+而volatile存在的意义就在于禁止这种重排！解决办法是声明为volatile类型。这样就可以用DCL了。
+
+```
+@NotThreadSafe
+public class DoubleCheckedLocking {
+    private static volatile Resource resource;
+
+    public static Resource getInstance() {
+        if (resource == null) {
+            synchronized (DoubleCheckedLocking.class) {
+                if (resource == null)
+                    resource = new Resource();
+            }
+        }
+        return resource;
+    }
+
+    static class Resource {
+
+    }
+}
+
+```
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#163-%E5%88%9D%E5%A7%8B%E5%8C%96%E8%BF%87%E7%A8%8B%E4%B8%AD%E7%9A%84%E5%AE%89%E5%85%A8%E6%80%A7)16.3 初始化过程中的安全性
+
+final不会被重排序。
+
+下面的states因为是final的所以可以被安全的发布。即使没有volatile，没有锁。但是，如果除了构造函数外其他方法也能修改states。如果类中还有其他非final域，那么其他线程仍然可能看到这些域上不正确的值。也导致了构造过程中的escape。
+
+写final的重排规则：
+
+*   JMM禁止编译器把final域的写重排序到构造函数之外。
+*   编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。也就是说：写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了。
+
+读final的重排规则：
+
+*   在一个线程中，初次读对象引用与初次读该对象包含的final域，JMM禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读final域操作的前面插入一个LoadLoad屏障。也就是说：读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读包含这个final域的对象的引用。
+
+如果final域是引用类型，那么增加如下约束：
+
+*   在构造函数内对一个final引用的对象的成员域的写入，与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。（个人觉得基本意思也就是确保在构造函数外把这个被构造对象的引用赋值给一个引用变量之前，final域已经完全初始化并且赋值给了当前构造对象的成员域，至于初始化和赋值这两个操作则不确保先后顺序。）
+
+```
+@ThreadSafe
+public class SafeStates {
+    private final Map<String, String> states;
+
+    public SafeStates() {
+        states = new HashMap<String, String>();
+        states.put("alaska", "AK");
+        states.put("alabama", "AL");
+        /*...*/
+        states.put("wyoming", "WY");
+    }
+
+    public String getAbbreviation(String s) {
+        return states.get(s);
+    }
+}
+```
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2275\344\271\213\345\237\272\347\241\200\346\236\204\345\273\272\346\250\241\345\235\227.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2275\344\271\213\345\237\272\347\241\200\346\236\204\345\273\272\346\250\241\345\235\227.md"
new file mode 100644
index 0000000000..70954a7aad
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2275\344\271\213\345\237\272\347\241\200\346\236\204\345\273\272\346\250\241\345\235\227.md"
@@ -0,0 +1,128 @@
+#1 同步容器类
+同步容器类包括Vector和HashTable，二者是早期JDK一部分，此外还包括在JDK 1.2中添加的一些功能相似的类，这些的同步封装器类是由Collections.synchronizedXxx等工厂方法创建的。这些类实现线程安全的方式是：将他们的状态封装起来，并对每个共有方法进行同步，使得每次只有一个线程能访问容器的状态。
+## 1.1 同步容器类的问题
+同步容器类都是线程安全的，但在某些情况可能需额外客户端加锁来保护复合操作。
+容器上常见的复合操作包括：
+
+- 迭代(反复访问元素，直到遍历完容器中所有元素)
+- 跳转(根据指定顺序找到当前元素的下一个元素)以及条件运算
+
+在同步容器类中，这些复合操作在没有客户端加锁的情况下，仍是线程安全的，
+但当其他线程并发的修改容器时，他们可能会表现出意料之外的行为。
+# 2 并发容器
+Java5提供了多种并发容器来改进同步容器的性能。
+
+同步容器将所有对容器状态的访问都串行化，以实现他们的线程安全性。
+这种方法的代价是严重降低并发性，当多个线程竞争容器的锁时，吞吐量将严重降低。
+
+并发容器是针对多个线程并发访问设计的。在Java 5中增加了
+
+- ConcurrentHashMap，用来替代同步且基于散列的Map，增加了对一些常见符合操作的支持，例如“若没有则添加”、替换以及有条件删除等。
+- CopyOnWriteArrayList，用于在遍历操作为主要操作的情况下代替同步的List。
+
+
+![](https://upload-images.jianshu.io/upload_images/4685968-8f68228c343b71ef.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+copyOnWriteArrayList 和 copyOnWriteSet 一开始都共享同一个内容，当想要修改内容时,才会真正的把内容 copy 出去,形成一个新的内容后再改
+比如：当我们往一个容器添加元素时，不直接往当前容器添加，而是先将容器进行 copy，复制出一个新容器，再往新容器里加元素。添加完之后，再将原容器引用指向新容器。
+好处:对 copyOnWrite 容器进行并发读时,不需要加锁,因为当前容器不会增加新元素,读写分离 
+`copyOnWriteArrayList#add`要加锁,否则多线程时会 copy N 个副本
+ copyOnWrite 适合于`读多写少`场景，但只能保证数据最终一致性,不保证实时一致性
+若你希望写入马上被读到，不要用 copyOnWrite 容器 
+
+**通过并发容器来代替同步容器，可以极大地提供伸缩性并降低风险。**
+## 2.1 CocurrentHashMap
+同步容器在执行每个操作期间都持有一个锁。在一些操作中，例如`HashMashMap.get`或`List.contains`，可能包含大量的工作：当遍历散列桶或链表来查找某个特定的对象时，必须在许多元素上调用equals。在基于散列的容器中，如果hashCode不能很均匀的分布散列值，那么容器中的元素就不会均匀的分布在整个容器中。某些情况下，某个糟糕的散列函数还会把一个散列表变成线性链表。当遍历很长的链表并且在某些或者全部元素上调用equals方法时，会花费很长时间，而其他线程在这段时间内都不能访问容器。
+
+ConcurrentHashMap使用一种粒度更细的称为分段锁的机制来实现更大程度的共享.
+在这种机制中，任意数量的读取线程可以并发的访问Map，执行读操作的线程和执行写操作的线程可以并发的访问Map，并且一定数量的写线程可以并发的修改Map.
+
+ConcurrentHashMap与其他并发容器一起增强了同步容器:迭代器不会抛出ConcurrentModificationException,因此迭代过程无需加锁.
+其迭代器具有"弱一致性",而并非"及时失败".可以容忍并发的修改,当创建迭代器时会遍历已有的元素,并可以(但不保证)在迭代器被构造后将修改操作反映给容器.
+
+只有当需要加锁Map以进行独占访问时,才应该放弃使用ConcurrentHashMap.
+## 2.2 额外的原子Map操作
+由于ConcurrentHashMap不能被加锁来执行独占访问,因此 无法使用客户端加锁来创建新的原子操作.
+一些常见的复合操作,eg."若没有则添加","若相等则移除"等,都已经实现为原子操作并且在ConcurrentMap接口中声明,如下面代码所示.
+
+```
+public interface ConcurrentMap<K, V> extends Map<K, V> {
+     //仅当K没有相应的映射值时才插入
+	 V putIfAbsent(K key, V value);
+	 
+     //仅当K被映射到V时才移除
+     boolean remove(Object key, Object value);
+     
+	 //仅当K被映射到oldValue时才替换为newValue
+	 boolean replace(K key, V oldValue, V newValue);
+	 
+	 //仅当K被映射到某个值时才被替换为newValue
+	  V replace(K key, V value);
+}
+```
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2276\344\271\213\344\273\273\345\212\241\346\211\247\350\241\214(Task-Execution).md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2276\344\271\213\344\273\273\345\212\241\346\211\247\350\241\214(Task-Execution).md"
new file mode 100644
index 0000000000..5cddb0c8f8
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2276\344\271\213\344\273\273\345\212\241\346\211\247\350\241\214(Task-Execution).md"
@@ -0,0 +1,152 @@
+# 1. 在线程中执行任务
+##1.1 串行的执行任务
+这是最经典的一个最简单的Socket server的例子，服务器的资源利用率非常低，因为单线程在等待I/O操作完成时，CPU处于空闲状态。从而阻塞了当前请求的延迟，还彻底阻止了其他等待中的请求被处理。
+```
+public class SingleThreadWebServer {
+    public static void main(String[] args) throws IOException {
+        ServerSocket socket = new ServerSocket(80);
+        while (true) {
+            Socket connection = socket.accept();
+            handleRequest(connection);
+        }
+    }
+
+    private static void handleRequest(Socket connection) {
+        // request-handling logic here
+    }
+}
+```
+##1.2 显式地为任务创建线程
+任务处理从主线程中分离出来，主循环可以快速等待下一个连接，提高响应性。同时任务可以并行处理了，吞吐量也提高了。
+```java
+public class ThreadPerTaskWebServer {
+    public static void main(String[] args) throws IOException {
+        ServerSocket socket = new ServerSocket(80);
+        while (true) {
+            final Socket connection = socket.accept();
+            Runnable task = new Runnable() {
+                public void run() {
+                    handleRequest(connection);
+                }
+            };
+            new Thread(task).start();
+        }
+    }
+    private static void handleRequest(Socket connection) {
+        // request-handling logic here
+    }
+}
+```
+##1.3 无限制创建线程的不足
+- 线程的生命周期开销非常高
+- 资源消耗。大量的空闲线程占用内存，给GC带来压力，同时线程数量过多，竞争CPU资源开销太大。
+稳定性。容易引起GC问题，甚至OOM
+#2  Executor框架
+任务就是一组逻辑工作单元（unit of work），而线程则是使任务异步执行的机制。
+
+Executor接口，是代替Thread来做异步执行的入口，接口虽然简单，却为非常灵活强大的异步任务执行框架提供了基础。
+提供了一种标准的方法将任务的提交与执行过程解耦，并用Runnable（无返回时）或者Callable（有返回值）表示任务。
+
+Executor基于生产者-消费者模式
+提交任务/执行任务分别相当于生产者/消费者,通常是最简单的实现生产者-消费者设计的方式了
+
+##2.1 基于Executor改造后的样例如下
+![](http://upload-images.jianshu.io/upload_images/4685968-1f600dab8e78cc3b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+将请求处理任务的提交与任务的实际执行解耦,并且只需采用另一种不同的Executor实现,就可以改变服务器的行为,其影响远远小于修改任务提交方式带来的影响
+##2.2 执行策略
+这一节主要介绍做一个Executor框架需要靠那些点？
+
+在什么线程中执行任务？
+任务按照什么顺序执行？FIFO/LIFO/优先级
+有多少个任务可以并发执行？
+队列中允许多少个任务等待？
+如果系统过载了要拒绝一个任务，那么选择拒绝哪一个？如何通知客户端任务被拒绝了？
+在执行任务过程中能不能有些别的动作before/after或者回调？
+各种执行策略都是一种资源管理工具，最佳的策略取决于可用的计算资源以及对服务质量的要求。
+
+因此每当看到
+new Thread(runnable).start();
+并且希望有一种灵活的执行策略的时候，请考虑使用Executor来代替
+##2.3 线程池
+在线程池中执行任务比为每个任务分配一个线程优势明显：
+
+重用线程，减少开销。
+延迟低，线程是等待任务到达。
+最大化挖掘系统资源以及保证稳定性。CPU忙碌但是又不会出现线程竞争资源而耗尽内存或者失败的情况。
+Executors可以看做一个工厂，提供如下几种Executor的创建：
+```java
+newCachedThreadPool
+newFixedThreadPool
+newSingleThreadExecutor
+newScheduledThreadPool
+```
+##2.4 Executor的生命周期
+为解决执行服务的生命周期问题,Executor扩展了ExecutorService接口,添加了一些用于生命周期管理的方法
+![](http://upload-images.jianshu.io/upload_images/4685968-d8f5761de7cb23f9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+一个优雅停止的例子：
+![](http://upload-images.jianshu.io/upload_images/4685968-218fcddabcf94772.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+增加生命周期扩展Web服务器的功能
+- 调用stop
+- 客户端请求形式
+
+关闭
+##2.5 延迟任务与周期任务
+使用Timer的弊端在于
+- 如果某个任务执行时间过长，那么将破坏其他TimerTask的定时精确性(执行所有定时任务时只会创建一个线程),只支持基于绝对时间的调度机制,所以对系统时钟变化敏感
+- TimerTask抛出未检查异常后就会终止定时线程(不会捕获异常)
+
+更加合理的做法是使用ScheduledThreadPoolExecutor,只支持基于相对时间的调度
+它是DelayQueue的应用场景
+# 3 找出可利用的并行性
+##3.1 携带结果的任务Callable和Future
+Executor框架支持Runnable，同时也支持Callable(它将返回一个值或者抛出一个异常)
+在Executor框架中，已提交但是尚未开始的任务可以取消，但是对于那些已经开始执行的任务，只有他们能响应中断时，才能取消。
+Future非常实用，他的API如下
+![](http://upload-images.jianshu.io/upload_images/4685968-5ae3dabd24462546.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+内部get的阻塞是靠LockSupport.park来做的，在任务完成后Executor回调finishCompletion方法会依次唤醒被阻塞的线程。
+
+ExecutorService的submit方法接受Runnable和Callable，返回一个Future。ThreadPoolExecutor框架留了一个口子，子类可以重写newTaskFor来决定创建什么Future的实现，默认是FutureTask类。
+##3.2  示例：使用Future实现页面的渲染器
+![](http://upload-images.jianshu.io/upload_images/4685968-1e87b014583e01ff.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##3.3 CompletionService: Executor与BlockingQueue
+计算完成后FutureTask会调用done方法，而CompletionService集成了FutureTask，对于计算完毕的结果直接放在自己维护的BlockingQueue里面，这样上层调用者就可以一个个take或者poll出来。
+![](http://upload-images.jianshu.io/upload_images/4685968-c19070c09477a763.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 3.3 示例：使用CompletionService提高渲染性能
+
+```
+void renderPage(CharSequence source) {
+        final List<ImageInfo> info = scanForImageInfo(source);
+        CompletionService<ImageData> completionService =
+                new ExecutorCompletionService<ImageData>(executor);
+        for (final ImageInfo imageInfo : info)
+            completionService.submit(new Callable<ImageData>() {
+                public ImageData call() {
+                    return imageInfo.downloadImage();
+                }
+            });
+
+        renderText(source);
+
+        try {
+            for (int t = 0, n = info.size(); t < n; t++) {
+                Future<ImageData> f = completionService.take();
+                ImageData imageData = f.get();
+                renderImage(imageData);
+            }
+        } catch (InterruptedException e) {
+            Thread.currentThread().interrupt();
+        } catch (ExecutionException e) {
+            throw launderThrowable(e.getCause());
+        }
+    }
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#637-%E4%B8%BA%E4%BB%BB%E5%8A%A1%E8%AE%BE%E7%BD%AE%E6%97%B6%E9%99%90)6.3.7 为任务设置时限
+
+Future的get支持timeout。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#638-%E6%89%B9%E9%87%8F%E6%8F%90%E4%BA%A4%E4%BB%BB%E5%8A%A1)6.3.8 批量提交任务
+
+使用invokeAll方法提交`List<Callable>`，返回一个`List<Future>`
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2277\344\271\213\345\217\226\346\266\210\344\270\216\345\205\263\351\227\255.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2277\344\271\213\345\217\226\346\266\210\344\270\216\345\205\263\351\227\255.md"
new file mode 100644
index 0000000000..020c4d672e
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2277\344\271\213\345\217\226\346\266\210\344\270\216\345\205\263\351\227\255.md"
@@ -0,0 +1,185 @@
+JAVA媒体提供任务机制来安全的终止线程。但是它提供了中断（interruption），这是一种写作机制，能够使一个线程终止另外一个线程。
+
+一般来说没人希望立即终止，因为必要时总要先清理再终止。
+
+开发一个应用能够妥善处理失败、关闭、取消等过程非常重要也有挑战。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#71-%E4%BB%BB%E5%8A%A1%E5%8F%96%E6%B6%88)7.1 任务取消
+
+一定不要使用Thread.stop和suspend这些机制。
+
+一种协作机制就是“标记位”。例如使用volatile类型的field来保存取消状态。
+
+```
+@ThreadSafe
+public class PrimeGenerator implements Runnable {
+    private static ExecutorService exec = Executors.newCachedThreadPool();
+
+    @GuardedBy("this") private final List<BigInteger> primes
+            = new ArrayList<BigInteger>();
+    private volatile boolean cancelled;
+
+    public void run() {
+        BigInteger p = BigInteger.ONE;
+        while (!cancelled) {
+            p = p.nextProbablePrime();
+            synchronized (this) {
+                primes.add(p);
+            }
+        }
+    }
+
+    public void cancel() {
+        cancelled = true;
+    }
+
+    public synchronized List<BigInteger> get() {
+        return new ArrayList<BigInteger>(primes);
+    }
+
+    static List<BigInteger> aSecondOfPrimes() throws InterruptedException {
+        PrimeGenerator generator = new PrimeGenerator();
+        exec.execute(generator);
+        try {
+            SECONDS.sleep(1);
+        } finally {
+            generator.cancel();
+        }
+        return generator.get();
+    }
+}
+
+```
+
+##1.1 中断
+下面的例子会出现死锁，线程根本不会停止
+```
+class BrokenPrimeProducer extends Thread {
+    private final BlockingQueue<BigInteger> queue;
+    private volatile boolean cancelled = false;
+
+    BrokenPrimeProducer(BlockingQueue<BigInteger> queue) {
+        this.queue = queue;
+    }
+
+    public void run() {
+        try {
+            BigInteger p = BigInteger.ONE;
+            while (!cancelled)
+                queue.put(p = p.nextProbablePrime());
+        } catch (InterruptedException consumed) {
+        }
+    }
+
+    public void cancel() {
+        cancelled = true;
+    }
+}
+
+```
+interrupt 方法：中断目标线程。isInterrupted：返回目标线程的中断状态。静态的 interrupted方法：清除当前线程的中断状态，并返回它之前的值。大多数可中断的阻塞方法会在入口处检查中断状态
+
+
+对中断操作（调用interrupt）的正确理解
+他并不会真正的中断一个正在运行的线程，而只是发出中断请求，然后由线程在下一个合适的时候中断自己。比如，wait、sleep、
+join等方法，当他们收到中断请求或开始执行时，发现某个已经被设置好的中断状态，则抛出异常interruptedException。 
+
+
+每个线程都有一个boolean类型的中断状态。当调用Thread.interrupt方法时，该值被设置为true，Thread.interruptted可以恢复中断。
+
+阻塞库方法，例如sleep和wait、join都会检查中断，并且发现中断则提前返回，他们会清楚中断状态，并抛出InterruptedException。
+
+但是对于其他方法interrupt仅仅是传递了中断的请求消息，并不会使线程中断，需要由线程在下一个合适的时刻中断自己。
+
+通常，用中断是取消的最合理的实现方式。
+
+上面的例子的改进方法就是
+
+```
+public class PrimeProducer extends Thread {
+    private final BlockingQueue<BigInteger> queue;
+
+    PrimeProducer(BlockingQueue<BigInteger> queue) {
+        this.queue = queue;
+    }
+
+    public void run() {
+        try {
+            BigInteger p = BigInteger.ONE;
+            while (!Thread.currentThread().isInterrupted())
+                queue.put(p = p.nextProbablePrime());
+        } catch (InterruptedException consumed) {
+            /* Allow thread to exit */
+        }
+    }
+
+    public void cancel() {
+        interrupt();
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#712-%E4%B8%AD%E6%96%AD%E7%AD%96%E7%95%A5)7.1.2 中断策略
+
+发生了中断，需要尽快退出执行流程，并把中断信息传递给调用者，从而使调用栈中的上层代码可以采取进一步的操作。当然任务也可以不需要放弃所有操作，可以推迟处理中断清楚，知道某个时机。
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#713-%E5%93%8D%E5%BA%94%E4%B8%AD%E6%96%AD)7.1.3 响应中断
+
+*   传递异常
+*   回复中断状态
+
+```
+public class NoncancelableTask {
+    public Task getNextTask(BlockingQueue<Task> queue) {
+        boolean interrupted = false;
+        try {
+            while (true) {
+                try {
+                    return queue.take();
+                } catch (InterruptedException e) {
+                    interrupted = true;
+                    // fall through and retry
+                }
+            }
+        } finally {
+            if (interrupted)
+                Thread.currentThread().interrupt();
+        }
+    }
+
+    interface Task {
+    }
+}
+
+```
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#716-%E5%A4%84%E7%90%86%E4%B8%8D%E5%8F%AF%E4%B8%AD%E6%96%AD%E7%9A%84%E9%98%BB%E5%A1%9E)7.1.6 处理不可中断的阻塞
+
+例如Socket I/O或者内置锁都不能响应中断，这时候该如何做才能终止他们呢？可以通过重写Thread.interrupt方法，例如加入close的逻辑。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#72-%E5%81%9C%E6%AD%A2%E5%9F%BA%E4%BA%8E%E7%BA%BF%E7%A8%8B%E7%9A%84%E6%9C%8D%E5%8A%A1)7.2 停止基于线程的服务
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#721-%E7%A4%BA%E4%BE%8B%E6%97%A5%E5%BF%97%E6%9C%8D%E5%8A%A1)7.2.1 示例：日志服务
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#722-%E5%85%B3%E9%97%ADexecutorservice)7.2.2 关闭ExecutorService
+
+#### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#723-poison-pill)7.2.3 Poison Pill
+
+例如CloseEvent机制或者POISON对象，来做特殊的识别，从而让程序自己处理停止操作，退出线程。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#73-%E5%A4%84%E7%90%86%E9%9D%9E%E6%AD%A3%E5%B8%B8%E7%9A%84%E7%BA%BF%E7%A8%8B%E7%BB%88%E6%AD%A2)7.3 处理非正常的线程终止
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#74-jvm%E5%85%B3%E9%97%AD)7.4 JVM关闭
+
+## [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#%E7%AC%AC8%E7%AB%A0-%E7%BA%BF%E7%A8%8B%E6%B1%A0%E7%9A%84%E4%BD%BF%E7%94%A8)第8章 线程池的使用
+
+一个很好的[ThreadPoolExecutor源码分析文档](https://my.oschina.net/xionghui/blog/494698)
+
+ThreadPoolExecutor UML图：
+
+[![image](http://upload-images.jianshu.io/upload_images/4685968-77840b3322b97eca?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](https://camo.githubusercontent.com/c0809a89c8ec3367d66a4181e6ab39f380c8b2e8/687474703a2f2f6e656f72656d696e642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031362f30392f6a6176612d372d636f6e63757272656e742d6578656375746f72732d756d6c2d636c6173732d6469616772616d2d6578616d706c652e706e67) 
+
+[![image](http://upload-images.jianshu.io/upload_images/4685968-4172f899bcf770d7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](https://camo.githubusercontent.com/6a87675bedf83eb673abb2c90025ebc35e52a584/687474703a2f2f6e656f72656d696e642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031362f30392f6a6176612d372d636f6e63757272656e742d636f6c6c656374696f6e732d756d6c2d636c6173732d6469616772616d2d6578616d706c652e706e67) 
+
+[![image](http://upload-images.jianshu.io/upload_images/4685968-b0cc68de7aaba827?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](https://camo.githubusercontent.com/2c7da5881649bfadbae9dec00dd5b4c45ffdeb74/687474703a2f2f6e656f72656d696e642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031362f30392f6a6176612d372d636f6e63757272656e742d6675747572652d756d6c2d636c6173732d6469616772616d2d6578616d706c652e706e67)
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2278\344\271\213\347\272\277\347\250\213\346\261\240\347\232\204\344\275\277\347\224\250.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2278\344\271\213\347\272\277\347\250\213\346\261\240\347\232\204\344\275\277\347\224\250.md"
new file mode 100644
index 0000000000..f342dd259d
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\345\256\236\346\210\230\347\263\273\345\210\2278\344\271\213\347\272\277\347\250\213\346\261\240\347\232\204\344\275\277\347\224\250.md"
@@ -0,0 +1,146 @@
+ThreadPoolExecutor UML图：
+
+[![image](http://upload-images.jianshu.io/upload_images/4685968-3df69177176c81dd?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](https://camo.githubusercontent.com/c0809a89c8ec3367d66a4181e6ab39f380c8b2e8/687474703a2f2f6e656f72656d696e642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031362f30392f6a6176612d372d636f6e63757272656e742d6578656375746f72732d756d6c2d636c6173732d6469616772616d2d6578616d706c652e706e67) 
+
+[![image](http://upload-images.jianshu.io/upload_images/4685968-579b162e5b60eb0a?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](https://camo.githubusercontent.com/6a87675bedf83eb673abb2c90025ebc35e52a584/687474703a2f2f6e656f72656d696e642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031362f30392f6a6176612d372d636f6e63757272656e742d636f6c6c656374696f6e732d756d6c2d636c6173732d6469616772616d2d6578616d706c652e706e67) 
+
+![](http://upload-images.jianshu.io/upload_images/4685968-4a8db303a1e728e1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#81-%E5%9C%A8%E4%BB%BB%E5%8A%A1%E5%92%8C%E6%89%A7%E8%A1%8C%E7%AD%96%E7%95%A5%E4%B9%8B%E9%97%B4%E9%9A%90%E5%BD%A2%E8%80%A6%E5%90%88)8.1 在任务和执行策略之间隐形耦合
+
+避免Thread starvation deadlock
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#82-%E8%AE%BE%E7%BD%AE%E7%BA%BF%E7%A8%8B%E6%B1%A0%E5%A4%A7%E5%B0%8F)8.2 设置线程池大小
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#83-%E9%85%8D%E7%BD%AEthreadpoolexecutor)8.3 配置ThreadPoolExecutor
+
+[![image](http://upload-images.jianshu.io/upload_images/4685968-1d1eac17930b3246?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](https://camo.githubusercontent.com/3ba3bc8d6aedfd58b6dfa17bcb7259fede320e29/687474703a2f2f6e656f72656d696e642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031362f30392f32303131313230393131313934345f3933332e6a7067) 
+
+构造函数如下：
+
+```
+public ThreadPoolExecutor(int corePoolSize,
+ int maximumPoolSize,
+ long keepAliveTime,
+ TimeUnit unit,
+ BlockingQueue<Runnable> workQueue,
+ ThreadFactory threadFactory,
+ RejectedExecutionHandler handler) { ... } 
+
+```
+
+*   核心和最大池大小：如果运行的线程少于 corePoolSize，则创建新线程来处理请求（即一个Runnable实例），即使其它线程是空闲的。如果运行的线程多于 corePoolSize 而少于 maximumPoolSize，则仅当队列满时才创建新线程。
+*   保持活动时间：如果池中当前有多于 corePoolSize 的线程，则这些多出的线程在空闲时间超过 keepAliveTime 时将会终止。
+*   排队：如果运行的线程等于或多于 corePoolSize，则 Executor 始终首选将请求加入队列BlockingQueue，而不添加新的线程。
+*   被拒绝的任务：当 Executor 已经关闭，或者队列已满且线程数量达到maximumPoolSize时（即线程池饱和了），请求将被拒绝。这些拒绝的策略叫做Saturation Policy，即饱和策略。包括AbortPolicy, CallerRunsPolicy, DiscardPolicy, and DiscardOldestPolicy.
+
+另外注意：
+
+*   如果运行的线程少于 corePoolSize，ThreadPoolExecutor 会始终首选创建新的线程来处理请求；注意，这时即使有空闲线程也不会重复使用（这和数据库连接池有很大差别）。
+*   如果运行的线程等于或多于 corePoolSize，则 ThreadPoolExecutor 会将请求加入队列BlockingQueue，而不添加新的线程（这和数据库连接池也不一样）。
+*   如果无法将请求加入队列（比如队列已满），则创建新的线程来处理请求；但是如果创建的线程数超出 maximumPoolSize，在这种情况下，请求将被拒绝。
+
+newCachedThreadPool使用了SynchronousQueue，并且是无界的。
+
+线程工厂ThreadFactory
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#84-%E6%89%A9%E5%B1%95threadpoolexecutor)8.4 扩展ThreadPoolExecutor
+
+重写beforeExecute和afterExecute方法。
+
+### [](https://github.com/neoremind/coddding/blob/master/codding/src/main/java/net/neoremind/mycode/concurrent/JAVA_CONCURRENCY_IN_PRACTICE_NOTES.md#85-%E9%80%92%E5%BD%92%E7%AE%97%E6%B3%95%E7%9A%84%E5%B9%B6%E8%A1%8C%E5%8C%96)8.5 递归算法的并行化
+
+实际就是类似Number of Islands或者N-Queens等DFS问题的一种并行处理。
+
+串行版本如下：
+
+```
+public class SequentialPuzzleSolver <P, M> {
+    private final Puzzle<P, M> puzzle;
+    private final Set<P> seen = new HashSet<P>();
+
+    public SequentialPuzzleSolver(Puzzle<P, M> puzzle) {
+        this.puzzle = puzzle;
+    }
+
+    public List<M> solve() {
+        P pos = puzzle.initialPosition();
+        return search(new PuzzleNode<P, M>(pos, null, null));
+    }
+
+    private List<M> search(PuzzleNode<P, M> node) {
+        if (!seen.contains(node.pos)) {
+            seen.add(node.pos);
+            if (puzzle.isGoal(node.pos))
+                return node.asMoveList();
+            for (M move : puzzle.legalMoves(node.pos)) {
+                P pos = puzzle.move(node.pos, move);
+                PuzzleNode<P, M> child = new PuzzleNode<P, M>(pos, move, node);
+                List<M> result = search(child);
+                if (result != null)
+                    return result;
+            }
+        }
+        return null;
+    }
+}
+
+```
+
+并行版本如下：
+
+```
+public class ConcurrentPuzzleSolver <P, M> {
+    private final Puzzle<P, M> puzzle;
+    private final ExecutorService exec;
+    private final ConcurrentMap<P, Boolean> seen;
+    protected final ValueLatch<PuzzleNode<P, M>> solution = new ValueLatch<PuzzleNode<P, M>>();
+
+    public ConcurrentPuzzleSolver(Puzzle<P, M> puzzle) {
+        this.puzzle = puzzle;
+        this.exec = initThreadPool();
+        this.seen = new ConcurrentHashMap<P, Boolean>();
+        if (exec instanceof ThreadPoolExecutor) {
+            ThreadPoolExecutor tpe = (ThreadPoolExecutor) exec;
+            tpe.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy());
+        }
+    }
+
+    private ExecutorService initThreadPool() {
+        return Executors.newCachedThreadPool();
+    }
+
+    public List<M> solve() throws InterruptedException {
+        try {
+            P p = puzzle.initialPosition();
+            exec.execute(newTask(p, null, null));
+            // block until solution found
+            PuzzleNode<P, M> solnPuzzleNode = solution.getValue();
+            return (solnPuzzleNode == null) ? null : solnPuzzleNode.asMoveList();
+        } finally {
+            exec.shutdown();
+        }
+    }
+
+    protected Runnable newTask(P p, M m, PuzzleNode<P, M> n) {
+        return new SolverTask(p, m, n);
+    }
+
+    protected class SolverTask extends PuzzleNode<P, M> implements Runnable {
+        SolverTask(P pos, M move, PuzzleNode<P, M> prev) {
+            super(pos, move, prev);
+        }
+
+        public void run() {
+            if (solution.isSet()
+                    || seen.putIfAbsent(pos, true) != null)
+                return; // already solved or seen this position
+            if (puzzle.isGoal(pos))
+                solution.setValue(this);
+            else
+                for (M m : puzzle.legalMoves(pos))
+                    exec.execute(newTask(puzzle.move(pos, m), m, this));
+        }
+    }
+}
+```
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\347\237\245\350\257\206\347\202\271\345\205\250\346\200\273\347\273\223.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\347\237\245\350\257\206\347\202\271\345\205\250\346\200\273\347\273\223.md"
new file mode 100644
index 0000000000..8011a4eb5e
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/Java\345\271\266\345\217\221\347\274\226\347\250\213\347\237\245\350\257\206\347\202\271\345\205\250\346\200\273\347\273\223.md"
@@ -0,0 +1,874 @@
+# 0 [相关源码](https://github.com/Wasabi1234/Concurrency-Progamming-Tutorial)
+
+![](https://upload-images.jianshu.io/upload_images/4685968-f12a51fabb09287a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![高并发处理的思路及手段](https://upload-images.jianshu.io/upload_images/4685968-881327a0ac18f5a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-f6439f7c997bfcf8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 1 基本概念
+
+## 1.1 并发
+同时拥有两个或者多个线程，如果程序在单核处理器上运行多个线程将交替地换入或者换出内存,这些线程是同时“存在"的，每个线程都处于执行过程中的某个状态，如果运行在多核处理器上,此时，程序中的每个线程都将分配到一个处理器核上，因此可以同时运行.
+
+## 1.2 高并发( High Concurrency) 
+互联网分布式系统架构设计中必须考虑的因素之一，通常是指，通过设计保证系统能够同时并行处理很多请求.
+
+## 1.3 区别与联系
+- 并发: 多个线程操作相同的资源，保证线程安全，合理使用资源
+- 高并发:服务能同时处理很多请求，提高程序性能
+
+# 2 CPU
+
+## 2.1 CPU 多级缓存
+![](https://upload-images.jianshu.io/upload_images/4685968-6fc8b5b6509ca6d7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 为什么需要CPU cache
+CPU的频率太快了，快到主存跟不上
+如此,在处理器时钟周期内，CPU常常需要等待主存，浪费资源。所以cache的出现，是为了缓解CPU和内存之间速度的不匹配问题(结构:cpu-> cache-> memory ).
+- CPU cache的意义
+  1) 时间局部性
+ 如果某个数据被访问，那么在不久的将来它很可能被再次访问
+  2) 空间局部性
+如果某个数据被访问，那么与它相邻的数据很快也可能被访问
+
+## 2.2 缓存一致性(MESI)
+用于保证多个 CPU cache 之间缓存共享数据的一致
+- M-modified被修改
+该缓存行只被缓存在该 CPU 的缓存中,并且是被修改过的,与主存中数据是不一致的,需在未来某个时间点写回主存,该时间是允许在其他CPU 读取主存中相应的内存之前,当这里的值被写入主存之后,该缓存行状态变为 E
+- E-exclusive独享
+缓存行只被缓存在该 CPU 的缓存中,未被修改过,与主存中数据一致
+可在任何时刻当被其他 CPU读取该内存时变成 S 态,被修改时变为 M态
+- S-shared共享
+该缓存行可被多个 CPU 缓存,与主存中数据一致
+- I-invalid无效
+![](https://upload-images.jianshu.io/upload_images/4685968-d2325f1e0e5b7786.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 乱序执行优化
+处理器为提高运算速度而做出违背代码原有顺序的优化
+
+##并发的优势与风险
+![](https://upload-images.jianshu.io/upload_images/4685968-e083e9bf164b7d73.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 3 项目准备
+
+## 3.1 项目初始化
+![自定义4个基本注解](https://upload-images.jianshu.io/upload_images/4685968-9ea512f5c1b3b4ea.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![随手写个测试类](https://upload-images.jianshu.io/upload_images/4685968-7bc23c076be35936.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![运行正常](https://upload-images.jianshu.io/upload_images/4685968-c7fba914bceb792e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 3.2 并发模拟-Jmeter压测
+![](https://upload-images.jianshu.io/upload_images/4685968-8c994437f5663dd6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0a6f7c5e0217aa17.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![添加"查看结果数"和"图形结果"监听器](https://upload-images.jianshu.io/upload_images/4685968-646e66ad4e2c7ffc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![log view 下当前日志信息](https://upload-images.jianshu.io/upload_images/4685968-cc70555c9f3b78b2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![图形结果](https://upload-images.jianshu.io/upload_images/4685968-01c21bb9069bcd28.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 3.3 并发模拟-代码
+
+### CountDownLatch
+![可阻塞线程,并保证当满足特定条件时可继续执行](https://upload-images.jianshu.io/upload_images/4685968-0d0481ec5302cadb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### Semaphore(信号量)
+![可阻塞线程,控制同一时间段内的并发量](https://upload-images.jianshu.io/upload_images/4685968-3133af3b8e419a39.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+以上二者通常和线程池搭配
+
+下面开始做并发模拟
+```
+package com.mmall.concurrency;
+
+import com.mmall.concurrency.annoations.NotThreadSafe;
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Semaphore;
+
+/**
+ * @author shishusheng
+ * @date 18/4/1
+ */
+@Slf4j
+@NotThreadSafe
+public class ConcurrencyTest {
+
+    /**
+     * 请求总数
+     */
+    public static int clientTotal = 5000;
+
+    /**
+     * 同时并发执行的线程数
+     */
+    public static int threadTotal = 200;
+
+    public static int count = 0;
+
+    public static void main(String[] args) throws Exception {
+        //定义线程池
+        ExecutorService executorService = Executors.newCachedThreadPool();
+        //定义信号量,给出允许并发的线程数目
+        final Semaphore semaphore = new Semaphore(threadTotal);
+        //统计计数结果
+        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
+        //将请求放入线程池
+        for (int i = 0; i < clientTotal ; i++) {
+            executorService.execute(() -> {
+                try {
+                    //信号量的获取
+                    semaphore.acquire();
+                    add();
+                    //释放
+                    semaphore.release();
+                } catch (Exception e) {
+                    log.error("exception", e);
+                }
+                countDownLatch.countDown();
+            });
+        }
+        countDownLatch.await();
+        //关闭线程池
+        executorService.shutdown();
+        log.info("count:{}", count);
+    }
+
+    /**
+     * 统计方法
+     */
+    private static void add() {
+        count++;
+    }
+}
+
+```
+运行发现结果随机,所以非线程安全
+# 4线程安全性
+
+## 4.1  线程安全性
+当多个线程访问某个类时，不管运行时环境采用`何种调度方式`或者这些进程将如何交替执行，并且在主调代码中`不需要任何额外的同步或协同`，这个类都能表现出`正确的行为`，那么就称这个类是线程安全的
+
+## 4.2 原子性
+
+### 4.2.1 Atomic 包
+- AtomicXXX:CAS,Unsafe.compareAndSwapInt
+提供了互斥访问，同一时刻只能有一个线程来对它进行操作
+```
+package com.mmall.concurrency.example.atomic;
+
+import com.mmall.concurrency.annoations.ThreadSafe;
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Semaphore;
+import java.util.concurrent.atomic.AtomicLong;
+
+/**
+ * @author shishusheng
+ */
+@Slf4j
+@ThreadSafe
+public class AtomicExample2 {
+
+    /**
+     * 请求总数
+     */
+    public static int clientTotal = 5000;
+
+    /**
+     * 同时并发执行的线程数
+     */
+    public static int threadTotal = 200;
+
+    /**
+     * 工作内存
+     */
+    public static AtomicLong count = new AtomicLong(0);
+
+    public static void main(String[] args) throws Exception {
+        ExecutorService executorService = Executors.newCachedThreadPool();
+        final Semaphore semaphore = new Semaphore(threadTotal);
+        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
+        for (int i = 0; i < clientTotal ; i++) {
+            executorService.execute(() -> {
+                try {
+                    System.out.println();
+                    semaphore.acquire();
+                    add();
+                    semaphore.release();
+                } catch (Exception e) {
+                    log.error("exception", e);
+                }
+                countDownLatch.countDown();
+            });
+        }
+        countDownLatch.await();
+        executorService.shutdown();
+        //主内存
+        log.info("count:{}", count.get());
+    }
+    
+    private static void add() {
+        count.incrementAndGet();
+        // count.getAndIncrement();
+    }
+}
+```
+
+```
+package com.mmall.concurrency.example.atomic;
+
+import com.mmall.concurrency.annoations.ThreadSafe;
+import lombok.extern.slf4j.Slf4j;
+import java.util.concurrent.atomic.AtomicReference;
+
+/**
+ * @author shishusheng
+ * @date 18/4/3
+ */
+@Slf4j
+@ThreadSafe
+public class AtomicExample4 {
+
+    private static AtomicReference<Integer> count = new AtomicReference<>(0);
+
+    public static void main(String[] args) {
+        // 2
+        count.compareAndSet(0, 2);
+        // no
+        count.compareAndSet(0, 1);
+        // no
+        count.compareAndSet(1, 3);
+        // 4
+        count.compareAndSet(2, 4);
+        // no
+        count.compareAndSet(3, 5); 
+        log.info("count:{}", count.get());
+    }
+}
+```
+![输出结果](https://upload-images.jianshu.io/upload_images/4685968-b60dac7453bd0904.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- AtomicReference,AtomicReferenceFieldUpdater
+![](https://upload-images.jianshu.io/upload_images/4685968-d726108a34669255.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- AtomicBoolean
+![](https://upload-images.jianshu.io/upload_images/4685968-b5fb1eaf9938c163.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- AtomicStampReference : CAS的 ABA 问题
+###4.2.2 锁
+synchronized:依赖 JVM
+- 修饰代码块:大括号括起来的代码，作用于调用的对象
+- 修饰方法: 整个方法，作用于调用的对象
+![](https://upload-images.jianshu.io/upload_images/4685968-88b9935f21beef0e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 修饰静态方法:整个静态方法，作用于所有对象
+![](https://upload-images.jianshu.io/upload_images/4685968-f0b3530e761400d1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+package com.mmall.concurrency.example.count;
+
+import com.mmall.concurrency.annoations.ThreadSafe;
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Semaphore;
+
+/**
+ * @author shishusheng
+ */
+@Slf4j
+@ThreadSafe
+public class CountExample3 {
+
+    /**
+     * 请求总数
+     */
+    public static int clientTotal = 5000;
+
+    /**
+     * 同时并发执行的线程数
+     */
+    public static int threadTotal = 200;
+
+    public static int count = 0;
+
+    public static void main(String[] args) throws Exception {
+        ExecutorService executorService = Executors.newCachedThreadPool();
+        final Semaphore semaphore = new Semaphore(threadTotal);
+        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
+        for (int i = 0; i < clientTotal ; i++) {
+            executorService.execute(() -> {
+                try {
+                    semaphore.acquire();
+                    add();
+                    semaphore.release();
+                } catch (Exception e) {
+                    log.error("exception", e);
+                }
+                countDownLatch.countDown();
+            });
+        }
+        countDownLatch.await();
+        executorService.shutdown();
+        log.info("count:{}", count);
+    }
+
+    private synchronized static void add() {
+        count++;
+    }
+}
+```
+synchronized 修正计数类方法
+- 修饰类:括号括起来的部分，作用于所有对象
+子类继承父类的被 synchronized 修饰方法时,是没有 synchronized 修饰的!!!
+
+Lock: 依赖特殊的 CPU 指令,代码实现 
+
+
+### 4.2.3  对比
+- synchronized: 不可中断锁，适合竞争不激烈，可读性好
+- Lock: 可中断锁，多样化同步，竞争激烈时能维持常态
+- Atomic: 竞争激烈时能维持常态，比Lock性能好; 只能同步一
+个值
+
+## 4.3 可见性
+一个线程对主内存的修改可以及时的被其他线程观察到
+
+### 4.3.1 导致共享变量在线程间不可见的原因
+- 线程交叉执行
+- 重排序结合线程交叉执行
+- 共享变量更新后的值没有在工作内存与主存间及时更新
+
+### 4.3.2 可见性之synchronized
+JMM关于synchronized的规定
+- 线程解锁前，必须把共享变量的最新值刷新到主内存
+- 线程加锁时，将清空工作内存中共享变量的值，从而使
+用共享变量时需要从主内存中重新读取最新的值(`加锁与解锁是同一把锁`)
+
+### 4.3.3 可见性之volatile
+通过加入内存屏障和禁止重排序优化来实现
+- 对volatile变量写操作时，会在写操作后加入一条store
+屏障指令，将本地内存中的共享变量值刷新到主内存
+- 对volatile变量读操作时，会在读操作前加入一条load
+屏障指令，从主内存中读取共享变量
+![volatile 写](https://upload-images.jianshu.io/upload_images/4685968-1b52dfe716f14632.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![volatile 读](https://upload-images.jianshu.io/upload_images/4685968-fe9dd1b03c64c7f4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![计数类之 volatile 版,非线程安全的](https://upload-images.jianshu.io/upload_images/4685968-977262be174e2dbc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- volatile使用
+```
+volatile boolean inited = false;
+
+//线程1:
+context = loadContext();
+inited= true;
+
+// 线程2:
+while( !inited ){
+    sleep();
+}
+doSomethingWithConfig(context)
+```
+
+## 4.4 有序性
+一个线程观察其他线程中的指令执行顺序，由于指令重排序的存在，该观察结果一般杂乱无序
+
+JMM允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性
+### 4.4.1 happens-before 规则
+#5发布对象
+![](https://upload-images.jianshu.io/upload_images/4685968-ed313a1caed24223.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![发布对象](https://upload-images.jianshu.io/upload_images/4685968-b368f6fe5b350cbe.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![对象逸出](https://upload-images.jianshu.io/upload_images/4685968-88d207fcc6bf1866.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+##5.1 安全发布对象
+![](https://upload-images.jianshu.io/upload_images/4685968-7400ab2abe1dbbfb.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![非线程安全的懒汉模式](https://upload-images.jianshu.io/upload_images/4685968-ba18bdbe3a3c4ed1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![饿汉模式](https://upload-images.jianshu.io/upload_images/4685968-be2854c290143094.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![线程安全的懒汉模式](https://upload-images.jianshu.io/upload_images/4685968-e632243a5a97281a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+package com.mmall.concurrency.example.singleton;
+
+import com.mmall.concurrency.annoations.NotThreadSafe;
+
+/**
+ * 懒汉模式 -》 双重同步锁单例模式
+ * 单例实例在第一次使用时进行创建
+ * @author shishusheng
+ */
+@NotThreadSafe
+public class SingletonExample4 {
+
+    /**
+     * 私有构造函数
+     */
+    private SingletonExample4() {
+
+    }
+
+    // 1、memory = allocate() 分配对象的内存空间
+    // 2、ctorInstance() 初始化对象
+    // 3、instance = memory 设置instance指向刚分配的内存
+
+    // JVM和cpu优化，发生了指令重排
+
+    // 1、memory = allocate() 分配对象的内存空间
+    // 3、instance = memory 设置instance指向刚分配的内存
+    // 2、ctorInstance() 初始化对象
+
+    /**
+     * 单例对象
+     */
+    private static SingletonExample4 instance = null;
+
+    /**
+     * 静态的工厂方法
+     *
+     * @return
+     */
+    public static SingletonExample4 getInstance() {
+        // 双重检测机制 // B
+        if (instance == null) {        
+            // 同步锁
+            synchronized (SingletonExample4.class) { 
+                if (instance == null) {
+                    // A - 3
+                    instance = new SingletonExample4(); 
+                }
+            }
+        }
+        return instance;
+    }
+}
+```
+![](https://upload-images.jianshu.io/upload_images/4685968-823166cdf7936293.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-9002671b71096f6c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 7 AQS
+
+## 7.1 介绍
+![数据结构](https://upload-images.jianshu.io/upload_images/4685968-918dcaea77d556e9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 使用Node实现FIFO队列，可以用于构建锁或者其他同步装置的基础框架
+- 利用了一个int类型表示状态
+- 使用方法是继承
+- 子类通过继承并通过实现它的方法管理其状态{acquire 和release} 的方法操纵状态
+- 可以同时实现排它锁和共享锁模式(独占、共享)
+同步组件
+
+###CountDownLatch
+```
+package com.mmall.concurrency.example.aqs;
+
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+
+/**
+ * @author shishusheng
+ */
+@Slf4j
+public class CountDownLatchExample1 {
+
+    private final static int threadCount = 200;
+
+    public static void main(String[] args) throws Exception {
+
+        ExecutorService exec = Executors.newCachedThreadPool();
+
+        final CountDownLatch countDownLatch = new CountDownLatch(threadCount);
+
+        for (int i = 0; i < threadCount; i++) {
+            final int threadNum = i;
+            exec.execute(() -> {
+                try {
+                    test(threadNum);
+                } catch (Exception e) {
+                    log.error("exception", e);
+                } finally {
+                    countDownLatch.countDown();
+                }
+            });
+        }
+        countDownLatch.await();
+        log.info("finish");
+        exec.shutdown();
+    }
+
+    private static void test(int threadNum) throws Exception {
+        Thread.sleep(100);
+        log.info("{}", threadNum);
+        Thread.sleep(100);
+    }
+}
+```
+ ```
+package com.mmall.concurrency.example.aqs;
+
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * 指定时间内处理任务
+ * 
+ * @author shishusheng 
+ * 
+ */
+@Slf4j
+public class CountDownLatchExample2 {
+
+    private final static int threadCount = 200;
+
+    public static void main(String[] args) throws Exception {
+
+        ExecutorService exec = Executors.newCachedThreadPool();
+
+        final CountDownLatch countDownLatch = new CountDownLatch(threadCount);
+
+        for (int i = 0; i < threadCount; i++) {
+            final int threadNum = i;
+            exec.execute(() -> {
+                try {
+                    test(threadNum);
+                } catch (Exception e) {
+                    log.error("exception", e);
+                } finally {
+                    countDownLatch.countDown();
+                }
+            });
+        }
+        countDownLatch.await(10, TimeUnit.MILLISECONDS);
+        log.info("finish");
+        exec.shutdown();
+    }
+
+    private static void test(int threadNum) throws Exception {
+        Thread.sleep(100);
+        log.info("{}", threadNum);
+    }
+}
+```
+
+## Semaphore用法
+![](https://upload-images.jianshu.io/upload_images/4685968-e6cbcd4254c642c5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-dbefbf2c76ad5a2a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-41f5f5a5fd135804.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## CycliBarrier
+```
+package com.mmall.concurrency.example.aqs;
+
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CyclicBarrier;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+
+/**
+ * @author shishusheng
+ */
+@Slf4j
+public class CyclicBarrierExample1 {
+
+    private static CyclicBarrier barrier = new CyclicBarrier(5);
+
+    public static void main(String[] args) throws Exception {
+
+        ExecutorService executor = Executors.newCachedThreadPool();
+
+        for (int i = 0; i < 10; i++) {
+            final int threadNum = i;
+            Thread.sleep(1000);
+            executor.execute(() -> {
+                try {
+                    race(threadNum);
+                } catch (Exception e) {
+                    log.error("exception", e);
+                }
+            });
+        }
+        executor.shutdown();
+    }
+
+    private static void race(int threadNum) throws Exception {
+        Thread.sleep(1000);
+        log.info("{} is ready", threadNum);
+        barrier.await();
+        log.info("{} continue", threadNum);
+    }
+}
+```
+![](https://upload-images.jianshu.io/upload_images/4685968-4fb51fa4926fd70e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+package com.mmall.concurrency.example.aqs;
+
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.CyclicBarrier;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * @author shishusheng
+ */
+@Slf4j
+public class CyclicBarrierExample2 {
+
+    private static CyclicBarrier barrier = new CyclicBarrier(5);
+
+    public static void main(String[] args) throws Exception {
+
+        ExecutorService executor = Executors.newCachedThreadPool();
+
+        for (int i = 0; i < 10; i++) {
+            final int threadNum = i;
+            Thread.sleep(1000);
+            executor.execute(() -> {
+                try {
+                    race(threadNum);
+                } catch (Exception e) {
+                    log.error("exception", e);
+                }
+            });
+        }
+        executor.shutdown();
+    }
+
+    private static void race(int threadNum) throws Exception {
+        Thread.sleep(1000);
+        log.info("{} is ready", threadNum);
+        try {
+            barrier.await(2000, TimeUnit.MILLISECONDS);
+        } catch (Exception e) {
+            log.warn("BarrierException", e);
+        }
+        log.info("{} continue", threadNum);
+    }
+}
+```
+![await 超时导致程序抛异常](https://upload-images.jianshu.io/upload_images/4685968-0f899c23531f8ee8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+```
+package com.mmall.concurrency.example.aqs;
+
+import lombok.extern.slf4j.Slf4j;
+
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Semaphore;
+/**
+ * @author shishusheng
+ */
+@Slf4j
+public class SemaphoreExample3 {
+
+    private final static int threadCount = 20;
+
+    public static void main(String[] args) throws Exception {
+
+        ExecutorService exec = Executors.newCachedThreadPool();
+
+        final Semaphore semaphore = new Semaphore(3);
+
+        for (int i = 0; i < threadCount; i++) {
+            final int threadNum = i;
+            exec.execute(() -> {
+                try {
+                    // 尝试获取一个许可
+                    if (semaphore.tryAcquire()) {
+                        test(threadNum);
+                        // 释放一个许可
+                        semaphore.release();
+                    }
+                } catch (Exception e) {
+                    log.error("exception", e);
+                }
+            });
+        }
+        exec.shutdown();
+    }
+
+    private static void test(int threadNum) throws Exception {
+        log.info("{}", threadNum);
+        Thread.sleep(1000);
+    }
+
+
+}
+```
+# 9 线程池
+## 9.1 newCachedThreadPool
+![](https://upload-images.jianshu.io/upload_images/4685968-1122da7a48223ba1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 9.2 newFixedThreadPool
+![](https://upload-images.jianshu.io/upload_images/4685968-0ea942bf12e5210f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 9.3 newSingleThreadExecutor
+看出是顺序执行的
+![](https://upload-images.jianshu.io/upload_images/4685968-989d59429f589403.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## 9.4 newScheduledThreadPool
+![](https://upload-images.jianshu.io/upload_images/4685968-f7536ec7a1cf6ecc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c90e09d5bfe707e6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 10 死锁
+![](https://upload-images.jianshu.io/upload_images/4685968-461f6a4251ae8ca4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-46d58773e597195f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 11 高并发之扩容思路
+
+## 11.1 扩容
+![](https://upload-images.jianshu.io/upload_images/4685968-8fabe01a7a9073ba.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 11.1 扩容 - 数据库
+![](https://upload-images.jianshu.io/upload_images/4685968-f1b501aa5f49953d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 12 高并发之缓存思路
+
+## 12.1 缓存
+![](https://upload-images.jianshu.io/upload_images/4685968-c5b8fa643df25009.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 1 缓存特征
+![](https://upload-images.jianshu.io/upload_images/4685968-272a9236ceace316.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 2 缓存命中率影响因素
+![](https://upload-images.jianshu.io/upload_images/4685968-302f50ee02ba8cf5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 3  缓存分类和应用场景
+![](https://upload-images.jianshu.io/upload_images/4685968-52b2f576007d9b70.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+##  12.2 高并发之缓存-特征、场景及组件介绍
+
+### 1 Guava Cache
+![](https://upload-images.jianshu.io/upload_images/4685968-23d4a01198f33926.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 2 缓存 - Memchche
+![](https://upload-images.jianshu.io/upload_images/4685968-ddde5e19b73fd570.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-7659178fc344a005.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-59c0c75277c9f31f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 3 缓存 - Redis
+![](https://upload-images.jianshu.io/upload_images/4685968-c8267b97a065b4b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 12.3 高并发之缓存-redis的使用
+- 配置类
+![](https://upload-images.jianshu.io/upload_images/4685968-4134748d1b3181f2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-8634e07d480b8546.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+- 服务类
+![](https://upload-images.jianshu.io/upload_images/4685968-fdb9daccd4778227.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-0c8d8a14d833b9e5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-461ff2bf851c25ab.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-a6efafc286fd0119.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 12.4 高并发场景问题及实战
+![](https://upload-images.jianshu.io/upload_images/4685968-66a1136fda32d82c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 缓存一致性
+![](https://upload-images.jianshu.io/upload_images/4685968-8897cf0ea46fd70e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 缓存并发问题
+![](https://upload-images.jianshu.io/upload_images/4685968-829cc45cffa45305.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 缓存穿透问题
+![](https://upload-images.jianshu.io/upload_images/4685968-9cd72ad60d574e44.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 缓存的雪崩问题
+![](https://upload-images.jianshu.io/upload_images/4685968-3222e4ef6875eeb0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+### 缓存高并发实战 - 股票分时线
+![](https://upload-images.jianshu.io/upload_images/4685968-5be19a8189b4202d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+# 13 高并发之消息队列思路
+## 13.1 业务案例
+![](https://upload-images.jianshu.io/upload_images/4685968-269e8e4d643ab023.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+将发短信封装成一条消息放进消息队列中,若发生短信过多,队列已满,需要控制发送的频率.
+通过将事件封装成消息放入队列,实现了业务解耦,异步设计,确保了短信服务只要正常后,一定会将短信成功发到用户.
+
+## 13.2 消息队列的特性
+![](https://upload-images.jianshu.io/upload_images/4685968-4153efed9fa882d2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 为何需要消息队列呢
+![](https://upload-images.jianshu.io/upload_images/4685968-4d0a52ea405e86af.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+- 优点
+![](https://upload-images.jianshu.io/upload_images/4685968-6ff5a7fbc96173b9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-5b2f547310cfd06f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+## 队列
+### kafka
+![](https://upload-images.jianshu.io/upload_images/4685968-f387cab7dbc62cb3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://img-blog.csdnimg.cn/20190220165509612.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+![](https://img-blog.csdnimg.cn/20190220165535530.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+![](https://img-blog.csdnimg.cn/20190220165600370.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+### rabbitmq
+![](https://upload-images.jianshu.io/upload_images/4685968-5ff08db891f912c8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://img-blog.csdnimg.cn/20190220165327892.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+![在这里插入图片描述](https://img-blog.csdnimg.cn/20190220165407887.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+![](https://img-blog.csdnimg.cn/20190220165431132.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 14 高并发之应用拆分
+## 14.1 应用拆分案例
+![](https://img-blog.csdnimg.cn/20190220170807133.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 14.2 应用拆分 - 原则
+![](https://img-blog.csdnimg.cn/20190220171337713.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+## 14.3 应用拆分 - 思考
+![](https://img-blog.csdnimg.cn/20190220171603900.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+### Dubbo
+![](https://img-blog.csdnimg.cn/20190220171806934.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+### 微服务
+![](https://img-blog.csdnimg.cn/20190220172313692.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 15 应用限流
+![](https://img-blog.csdnimg.cn/20190221093539939.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 16 高并发之服务降级与服务熔断思路
+![](https://img-blog.csdnimg.cn/20190221093917603.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 16.1 服务降级的分类
+![](https://img-blog.csdnimg.cn/20190221094008959.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 16.2 对比
+![](https://img-blog.csdnimg.cn/20190221094142183.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 16.3 服务降级要考虑的问题
+![](https://img-blog.csdnimg.cn/20190221094252928.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 16.4 Hystrix
+![](https://img-blog.csdnimg.cn/20190221094332379.png)
+![](https://img-blog.csdnimg.cn/20190221094406366.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 17 高并发之数据库切库分库分表思路
+## 17.1 数据库瓶颈
+![](https://img-blog.csdnimg.cn/2019022109460243.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+##  17.2 数据库切库
+![](https://img-blog.csdnimg.cn/20190221095113720.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 17.3 数据库支持多个数据源与分库
+![](https://img-blog.csdnimg.cn/20190221095301733.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+![](https://img-blog.csdnimg.cn/20190221095242146.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 17.4 数据库分表
+![](https://img-blog.csdnimg.cn/2019022109564342.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 18  高并发之高可用手段介绍
+![](https://img-blog.csdnimg.cn/20190221100710464.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 19 总结
+![](https://img-blog.csdnimg.cn/20190221100858987.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+![](https://img-blog.csdnimg.cn/20190221100918783.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+![](https://img-blog.csdnimg.cn/20190221101124952.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+![](https://upload-images.jianshu.io/upload_images/16782311-567ff3477bb9dc7b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+
+![](https://upload-images.jianshu.io/upload_images/16782311-3350c1ed75337cde.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+# 参考
+[Java并发编程入门与高并发面试](https://coding.imooc.com/class/195.html)
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/Java/\345\271\266\345\217\221\347\274\226\347\250\213/\345\217\262\344\270\212\346\234\200\345\277\253Docker\345\205\245\351\227\250!(\344\270\200)-\345\256\271\345\231\250\346\212\200\346\234\257\345\222\214Docker\347\256\200\344\273\213.md" "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/\345\217\262\344\270\212\346\234\200\345\277\253Docker\345\205\245\351\227\250!(\344\270\200)-\345\256\271\345\231\250\346\212\200\346\234\257\345\222\214Docker\347\256\200\344\273\213.md"
new file mode 100644
index 0000000000..0505d1519c
--- /dev/null
+++ "b/Java/\345\271\266\345\217\221\347\274\226\347\250\213/\345\217\262\344\270\212\346\234\200\345\277\253Docker\345\205\245\351\227\250!(\344\270\200)-\345\256\271\345\231\250\346\212\200\346\234\257\345\222\214Docker\347\256\200\344\273\213.md"
@@ -0,0 +1,14 @@
+# 1  容器技术概述
+聊聊容器技术
+![](https://upload-images.jianshu.io/upload_images/4685968-bd8b71e958d72512.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-38b190b30a6725fc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-d5964b56c470f7da.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-efbae9d25a5587bc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-37b6ff19a297195e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-ed3e0e9ca31eecb9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-6e58dfc936b99b9f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-4e4e60f90a74b6cc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-70f576b03b6e3d07.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-c28e798b24cde9b6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-2727f55a7e591e11.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+![](https://upload-images.jianshu.io/upload_images/4685968-decd32927628981b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
diff --git "a/\350\201\214\344\270\232\345\217\221\345\261\225/\346\274\253\346\274\253\345\244\247\345\255\246\346\261\237\346\271\226\345\275\225 - \347\210\261\344\270\216\346\201\250\345\224\257\344\270\216\345\267\245\344\275\234\346\233\264\344\272\244\347\273\207.md" "b/\350\201\214\344\270\232\345\217\221\345\261\225/\346\274\253\346\274\253\345\244\247\345\255\246\346\261\237\346\271\226\345\275\225 - \347\210\261\344\270\216\346\201\250\345\224\257\344\270\216\345\267\245\344\275\234\346\233\264\344\272\244\347\273\207.md"
new file mode 100755
index 0000000000..070c4fd196
--- /dev/null
+++ "b/\350\201\214\344\270\232\345\217\221\345\261\225/\346\274\253\346\274\253\345\244\247\345\255\246\346\261\237\346\271\226\345\275\225 - \347\210\261\344\270\216\346\201\250\345\224\257\344\270\216\345\267\245\344\275\234\346\233\264\344\272\244\347\273\207.md"	
@@ -0,0 +1,139 @@
+# 0 前言
+
+其实在18年11月秋招就拿了华为南研所的offer了,基本宣告结束了大学校招历程，是时候写下总结了，再不写估计很多东西都忘了。
+
+从学习Java开始就在各种程序员社区混了，大二第一个知道了牛客网,从别人的学习、求职、工作经历中越发感受到很多的正能量，也本着日行一善的原则，向学弟学妹们，尤其和我一样的双非本科生学弟学妹们传递点正能量，因为笔者也是双非，虽然现在好像双一流了.而且在整个求职的过程中能够很明显地感受到名校学生那种得天独厚的优势，同样的实力，名校学生进入一线互联网企业确实要容易很多，即便技术很水，一样有华为等企业保底，而非名校的可能连简历筛选这关都过不了。
+
+说到这些，并不是为了打击非名校的学生，只是，这些确实是事实，既然无法改变环境，那就改变自己吧，**提高自己的技术实力，并放宽自己的心态，对结果看淡点，不要抱怨自己的出身**，这样一路走来，你反而会发现：越努力，越幸运！
+
+# 1 offer情况
+
+由于南京机会太少，校招前就一直想去上海驻扎，但后来因为地点和一些感情的事，一直没法留在魔都，而且又有学院坑爹的不准外地实习规定，就只能呆在南京了。
+
+由于实习限制，而且又非常向往魔都，因此主要参加了携程、美团、饿了么这几家企业的实习生面试，没办法因为算法不好，没刷过题，基本挂。后来，还意外地收到了网易杭研的面试通知，据说光简历这关就刷了很多人，有点喜出望外，但也因为算法题答不好一面就挂了，不过问面试官，都说我对技术和框架玩的不错，也算安慰了，至少算法不好，技术还行~10月下旬拿到华为的offer后，就没再参加后面公司的笔试了，主要是考虑到工作地点的问题，而且感觉也没必要刷那么多面经和算法题，毕竟自己追求是真正技术的进步，在哪工作其实都一样，华为也还差强人意,
+
+# 2 漫漫大学江湖路
+
+在南京某双非双一流大学就读，专业物联网工程。
+
+**15.9 ~ 16.2** 在大一的时候，大把时间都花在和谈恋爱搞暧昧、打游戏和各种无意义活动上了，大一上结束，C语言只考了67，感觉很丢人现眼，隐约意识到要提高自己的编程能力，但又不知道往什么方向学，正好下学期听说还有C++课，正好上学期快结束时发了课本，寒假时就一直在研读学习C++课本，后面又看了《c++ primer》。
+
+**16.3 ~ 16.7** 到了大一下学期，听课时就觉得都不难了，好像编程还行，作业题虽然依旧是抄同届大佬的，但是至少看得懂写的啥了，期末也还不错，考了97分。转眼大一都快结束了，想想要确定一个未来工作的方向了，老这么漫无目的地瞎折腾，总不是办法。那时正好因为上了学院教授的MIT编程选修课，加了群，认识了一些当时拿到华为、携程等20W年薪工作的学长，在网上查了好几天，最终决定搞Java，原因很简单：需求量大，就业机会多，未来几年应该依然是主流。接下来，便是各种自学，先是到图书馆借了基本 Java 的书，到闲鱼买了本《Java 核心技术》两卷，入门Java，但是书一开始还是看不懂，暑假时搜了点视频，从马士兵的JavaSE 视频开始真正入门了。没办法，谁让自己当初觉悟低，错过了大半年的大好光阴，好在现在意识到，还为时不晚，每天多努力点就好啦。
+
+**16.9 ~ 17.2** 大二上，学院开了Java课，不过我基本不听课，老师自己说的太没激情了，而且大部分我都自学过了。自学过程很艰难，网上找的传智播客的Java就业班视频开始有点体系的学习基础，遇到不会的还没人问，很多时候代码和视频一模一样，但就是跑不了，一直报错，想砸电脑，感觉也没学到啥东西，时常都想放弃自己，不过咬咬牙还是坚持了，毕竟自己不努力，以后还能干嘛呢，我不想被人看不起，别人高中就学计算机，大学了更厉害，我虽然学的晚，但我不觉得我会一直比他们差，终有一天会超过绝大多数的人，因为我够努力，智商不够，时间来凑，同时进一步巩固了Java基础，学习数据结构与算法，并抽空看了一遍《大话数据结构》。因为学院老师教的数据结构课实在是太恶心了，C语言说的根本听不懂，虽然看了几本Java 实现的数据结构书，还是一头雾水，很多内容不得其要领。
+
+**17.3 ~ 17.7**  大二上就这么浑浑噩噩地过了，真正在技术上有质的飞跃是大二下到大三上这一年，由于参加了学校的大创，开始组队待在实验室里每天，开始翘课，这一年有了很多自由的时间，一边做个商城项目及牛客的高级项目，一边看书，从Java语言，到JVM，再到多线程编程，算法，看了很多经典的书籍，获益匪浅。但学习的过程还是很曲折的，主要是实验室有着各种坑爹的规定，导师总是进屋就吐槽软件怎么还没做出来，每天看这么多书有什么用？而且学习氛围不是一般的差，当然这些都已成过去，也不想吐槽太多，期间还在追实验室和我一组的一个妹纸，不过快追到时就放假了，假期过后，一切凉凉没了感觉，所以下学期开学后一段时间极度痛苦每天。就这样，为了能安静高效地学习，我打了一年的游击战，持续性在课堂上掉线，没怎么上线过。比较庆幸的是，很早就知道了牛客网这个东西，平时也都会上去看看面经啥的，很多内推帖子，感觉该出去看看了就投了个爱奇艺实习，5月多时视频面试，答得很垃圾，原来自己还差这么多，于是决定开始坚持写技术博客，事实证明，这确实是一件有百利而无一害的事情，通过写博客，在社区上结识了很多志同道合的小伙伴和技术上精益求精的前辈，从这些素未谋面的人身上学到了很多，感受到了满满的正能量，也提升了技术认知。
+
+**17.9 18.2** 另外一件对我找工作帮助很大的事情，是11月下旬拿到了百度运营产品研发部的实习offer，考虑到即使无法留下来也有个大厂实习经历了，便决定去实习，寒假一开始，就独自坐车北上，从南京到北京，买了最便宜的火车票都要五百多，北京很干，在那里嘴唇一直都是干裂的，向父亲要了一万多用于租房，即使过年也一直在北京，期间打王者认识了个重庆的女孩子，每天下班回去都和她聊天打游戏，也算在远方的一个陪伴了，不算太孤独吧，没离开过小租房，短短的一个半月，就要说再见了，因为开学，辅导员发现我不在学校了，打电话质问我在哪里并要求我立即回校，否则做退学处理，没办法，离开心爱的百度，又南下五个多小时火车，蹲的腿都麻了，想死的心都有。
+
+**18.3 ~ 18.9** 接下来，大三下,便是校招了，校招高峰期虽然只有不到两个月，但真正关键的是校招前的那一两年，甚至三五年，你所付出的努力。博主在社区里看到很多默默付出，最后在校招期间爆发的人，当然也会有人悠哉了三年，一样拿到了不错的offer，只是人可幸运一时，总不至幸运一世，所以脚踏实地，才能有所作为。回到学校后,和室友顺路进了一个校级的技术组织易班,这里环境超棒,于是就天天来此继续学习微服务分布式的知识点,顺便又做了个微服务的项目,顺带帮着组织招了一批新人,后来发展都不错~下面是这时间参加的一些面试
+
+#### 阿里（一面挂）
+
+阿里之于我，只有一句话可以形容：阿里虐我千万遍，我待阿里如初恋。
+
+第一次面阿里是3月份的实习生内推，当时加了一个菜鸟技术部的内推群，无奈水平太渣，很多基础记不得了，又超级紧张，聊了不到半小时，就顺利地挂掉了简历面，不过也没有太在意，因为当时一直觉得BAT对我来说，是很遥远的事情。
+
+被阿里打击后，我一度开始怀疑自己的能力，越想越觉得找份好工作不容易，郁闷了两天后，索性接下来的面试不再做任何准备（实际上，也没有时间准备，因为项目赶的太紧），放空身心，一切随缘，大不了最后去小公司，反而是这种心态，让我顺利通过了后面公司的面试。
+
+#### 华为（二面挂）
+
+在拿到携程实习 offer 后参加的华为春招，心态很轻松，态度很轻蔑，二面很顺利的挂了。不过表现还是不错，参加华为秋招还是优招名额。
+
+#### 携程（两面offer）
+
+很早就来南京开了宣讲会，和一个群里的粉丝同学一起去的，宣讲会最后有个小笔试题，做了个算法交了上去，第二天就收到了面试通知，克日去面试，听他说就十个研发面试名额，而且就只有我一个是本科生，其实那个笔试算法题我也没做对，只是看了我的简历有百度经验还有丰富的项目经验，就给了我个机会面试了，问的也都不难，答得也中规中矩吧，回去等消息了，这一等就是近三个月，三月的宣讲会，五月多来个二面，幸好电话面试，问了都是算法，正好还都是我会的，就轻轻松松的过了，这时候正好玩吃鸡时遇到了个老乡，就谈上了恋爱，瞬间幸福感爆棚，之后几乎就一直打游戏了，没怎么学习了，因为听说携程实习生留用率很高，不想再努力了，可后来事实证明我错了，一切都重新翻牌了。
+
+暑假在携程实习了一个月后，老板通知我不会留用，一时间很生气无奈又痛苦，心情很差，那段时间也没心没肺，和女友经常吵架，最后把她气跑了，之后在上海疯狂找工作，无奈也都是要求实习的，没法继续留在魔都的，最后还是忍痛割爱，离开了魔都，2018.8.31失去了工作与女友，一无所有的又回到了南京
+
+**18.9 ~ 18.11**
+
+回到了南京，心情很复杂，一个暑假，一直在实习，根本没想过会要参加秋招，很多东西都没准备，算法一点没刷过。
+
+没办法，想去好点的公司，还是要付出才行，从失恋中调整了好久，继续征战各种笔试，虽然也是意料之中的做五关挂六笔。想想应该和互联网公司没啥关系了再。
+
+#### 顺丰（offer）
+
+偶然发现笔试过了一个，通知了面试，就去一个大酒店现场面试，一面技术，二面HR，直接过了，没啥难的东西。
+
+#### 美团（一面挂）
+
+框架技术玩的不错，算法太差，面试官评价，好的，告辞了。
+
+#### 百词斩（笔试过，没参加面试）
+
+由于当时参加上海携程面试，没打开电脑面试，遂挂。
+
+#### 携程（挂）
+
+秋招又来了携程面试，真是又爱又恨，可是遇到的面试官太恶心了，几乎没听我说话，莫名其妙挂了，从此携程一生黑
+
+#### 中兴（两面offer）
+
+中兴经历过那个事件后开始在我们学校大规模招人，相对来说，中兴的offer拿的是最容易的，官网投了简历，就宣布去面试了，在ZTE总部，问了很多，只是都无关技术，很顺利地通过了一面，同样是第二天收到的二面短信，同样二对一面试，完全没问技术，各种HR综合问题，大概二十多分钟，面试结束，没几天收到offer短信，薪资太低，直接拒了。
+
+#### 华为（两面offer）
+
+一面很忐忑的过了，面试官一直和我谈框架与业务的问题，没咋答好觉得，不过还是有了二面
+
+二面高冷大叔，不过我也很平和了，舒畅说完大学自学历程，提到翘课很多，最后问他评价，自学能力强，不过不听话不去好好上课可不太好哦哈哈哈，十天后收到 offer 短信，谢天谢地，对于南京，给的白菜价也不错了，很满意了，就这样吧，累了。最后三方也给了我的为为。
+
+#### 京东金融(两面挂)
+
+不经意间又收到南京京东金融的面试,一面部门总监,二面技术经理,面完无后文
+
+#### 百度补招(两面挂)
+
+上海补招,一面女士,聊得还行,几天后二面,spring有的细节忘了没回答好,无后文.
+
+**18.11~19.6** 大四后半段了,专注毕设，由于牵涉到推荐系统，又把大数据和机器学习简单补了一下
+
+# 3  一些感悟
+
+从3月份的实习生招聘开始，到现在，一路跌跌撞撞，总算有了着落，总结下其中切身体会到的一些感悟。
+
+## 3.1  基础很重要
+
+这个相信大家都深有体会，特别是算法，我最有体会了哈哈哈，没刷过题，一切靠 Java 技术。也许你的 Java够好就可以不需要考你的算法了。
+
+## 3.2 项目要深入
+
+做项目不能浅尝辄止，这个参加过面试的人应该都会有所体会，很多面试官会挖坑，不理解透彻你就是去搞笑的。
+
+## 3.3 心态很重更要
+
+跟高考一样，面试中心态不好，会很影响临场的发挥。
+
+## 3.4 细节决定成败
+
+从基础到项目，这个都会有所体现。
+
+## 3.5  坚持写博客
+
+面试到现在，很多面试官看了我的博客，写博客真的是一件有百利而无一害的事情。笔者也在很多社区成为专项作者
+
+### [慕课网认证作者](https://www.imooc.com/u/2396649/articles)
+
+![](https://ask.qcloudimg.com/http-save/1752328/rresmbbbda.png)
+
+![](https://ask.qcloudimg.com/http-save/1752328/qxaspre898.png)
+
+![](https://ask.qcloudimg.com/http-save/1752328/e1xbo5wp1k.png)
+
+### [阿里云栖社区博客专家](https://yq.aliyun.com/users/article?spm=a2c4e.8091938.headeruserinfo.3.65993d6eqaQ0O6)
+
+![](https://ask.qcloudimg.com/http-save/1752328/owjz7ep7gp.png)
+
+### [腾讯云自媒体邀约计划作者](https://cloud.tencent.com/developer/user/1752328)
+
+![](https://ask.qcloudimg.com/http-save/1752328/iulhzjg9pt.png)
+
+[简书程序员专题推荐作者](https://www.jianshu.com/u/32c7d1f520c2)
+
+![](https://ask.qcloudimg.com/http-save/1752328/zgunah6xqx.png)
+
+## 3.6 佛系一点
+
+有些时候，有些事，确实要看缘分，所以把心放宽些，不要刻意放大一些痛苦。无论是工作还是爱情。
+
+# 付出就有所收获,关键在于,你是否坚持的足够久
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(00) - \350\257\264\346\230\216.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(00) - \350\257\264\346\230\216.md"
new file mode 100644
index 0000000000..0929740d7a
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(00) - \350\257\264\346\230\216.md"	
@@ -0,0 +1,96 @@
+# 1、分布式系统
+
+## 1.1 为什么要进行系统拆分？
+（1）为什么要进行系统拆分？如何进行系统拆分？拆分后不用dubbo可以吗？dubbo和thrift有什么区别呢？
+
+##  1.2 分布式服务框架
+（1）说一下的dubbo的工作原理？注册中心挂了可以继续通信吗？
+
+（2）dubbo支持哪些序列化协议？说一下hessian的数据结构？PB知道吗？为什么PB的效率是最高的？
+
+（3）dubbo负载均衡策略和高可用策略都有哪些？动态代理策略呢？
+
+（4）dubbo的spi思想是什么？
+
+（5）如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试？
+
+（6）分布式服务接口的幂等性如何设计（比如不能重复扣款）？
+
+（7）分布式服务接口请求的顺序性如何保证？
+
+（8）如何自己设计一个类似dubbo的rpc框架？
+##  1.3 分布式锁
+（1）使用redis如何设计分布式锁？使用zk来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
+##  1.4 分布式事务
+（1）分布式事务了解吗？你们如何解决分布式事务问题的？TCC如果出现网络连不通怎么办？XA的一致性如何保证？
+##  1.5 分布式会话
+（1）集群部署时的分布式session如何实现？
+# 2、高并发架构
+##  2.1 如何设计一个高并发系统？
+##  2.2 消息队列
+（1）为什么使用消息队列啊？消息队列有什么优点和缺点啊？kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊？
+
+（2）如何保证消息队列的高可用啊？
+
+（3）如何保证消息不被重复消费啊（如何进行消息队列的幂等性问题）？
+
+（4）如何保证消息的可靠性传输（如何处理消息丢失的问题）？
+
+（5）如何保证消息的顺序性？
+
+（6）如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
+
+（7）如果让你写一个消息队列，该如何进行架构设计啊？说一下你的思路
+##  2.3 搜索引擎
+（1）es的分布式架构原理能说一下么（es是如何实现分布式的啊）？
+
+（2）es写入数据的工作原理是什么啊？es查询数据的工作原理是什么啊？底层的lucene介绍一下呗？倒排索引了解吗？
+
+（3）es在数据量很大的情况下（数十亿级别）如何提高查询效率啊？
+
+（4）es生产集群的部署架构是什么？每个索引的数据量大概有多少？每个索引大概有多少个分片？
+##  2.4 缓存
+（1）在项目中缓存是如何使用的？缓存如果使用不当会造成什么后果？
+
+（2）redis和memcached有什么区别？redis的线程模型是什么？为什么单线程的redis比多线程的memcached效率要高得多？
+
+（3）redis都有哪些数据类型？分别在哪些场景下使用比较合适？
+
+（5）redis的过期策略都有哪些？手写一下LRU代码实现？
+
+（6）如何保证Redis高并发、高可用、持久化？redis的主从复制原理能介绍一下么？redis的哨兵原理能介绍一下么？
+
+（7）redis的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？
+
+（8）redis集群模式的工作原理能说一下么？在集群模式下，redis的key是如何寻址的？分布式寻址都有哪些算法？了解一致性hash算法吗？如何动态增加和删除一个节点？
+
+（9）了解什么是redis的雪崩和穿透？redis崩溃之后会怎么样？系统该如何应对这种情况？如何处理redis的穿透？
+
+（10）如何保证缓存与数据库的双写一致性？
+
+（11）redis的并发竞争问题是什么？如何解决这个问题？了解Redis事务的CAS方案吗？
+
+（12）生产环境中的redis是怎么部署的？
+##  2.5 分库分表
+
+（2）为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？
+
+（3）现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？
+
+（4）如何设计可以动态扩容缩容的分库分表方案？
+
+（5）分库分表之后，id主键如何处理？
+
+##  2.6 读写分离
+（1）如何实现mysql的读写分离？MySQL主从复制原理的是啥？如何解决mysql主从同步的延时问题？
+# 3、高可用架构
+##  3.1 如何设计一个高可用系统？
+##  3.2 限流
+（1）如何限流？在工作中是怎么做的？说一下具体的实现？
+##  3.3 熔断
+（1）如何进行熔断？熔断框架都有哪些？具体实现原理知道吗？
+##  3.4 降级
+（1）如何进行降级？
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(01)-\347\216\260\344\273\243\344\272\222\350\201\224\347\275\221java\345\267\245\347\250\213\345\270\210\346\213\233\350\201\230JD.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(01)-\347\216\260\344\273\243\344\272\222\350\201\224\347\275\221java\345\267\245\347\250\213\345\270\210\346\213\233\350\201\230JD.md"
new file mode 100644
index 0000000000..fad31b5df3
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(01)-\347\216\260\344\273\243\344\272\222\350\201\224\347\275\221java\345\267\245\347\250\213\345\270\210\346\213\233\350\201\230JD.md"
@@ -0,0 +1,21 @@
+![](https://img-blog.csdnimg.cn/20190625124918785.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+上面是我在拉钩随便找的一个职位，你现在去随便找个职位jd，起码都有这些要素，java基本功是起码的，那些开源框架也是起码的，但是这几年跟前几年不一样的一点在于，现在招聘java，一般都会加一句，要求熟悉分布式系统开发，包括缓存、消息队列、搜索引擎等等，然后要求熟悉dubbo等服务框架。
+
+这就是现在比较典型的互联网java岗位招聘要求
+
+但是不幸的是，好多的同学可能没搞过那些东西，或者之前自己看过一些，知道点demo和概念，略知一二，就是面试的时候容易被面试官几个连环炮打蒙，然后面试就挂了，针对这类同学。
+
+因此该教程定位就是2周内快速突击普通的互联网java岗位对应的技术体系相关的常见面试题，出去面试的时候不要上来就被打蒙，起码支撑了五到八轮之后再被打蒙，那个时候跟面试官认怂也可以了。
+
+起码别人第一轮就被打蒙，你得坚持到第八轮再被打蒙，那么矬子里拔将军，面试官对你印象至少比别人要很多，你的竞争力、面试通过率自然也就比别人高了很多
+
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(02) - Redis\345\246\202\344\275\225\351\200\232\350\277\207\350\257\273\345\206\231\345\210\206\347\246\273\346\235\245\346\211\277\350\275\275\350\257\273\350\257\267\346\261\202QPS\350\266\205\350\277\20710\344\270\207+\357\274\237.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(02) - Redis\345\246\202\344\275\225\351\200\232\350\277\207\350\257\273\345\206\231\345\210\206\347\246\273\346\235\245\346\211\277\350\275\275\350\257\273\350\257\267\346\261\202QPS\350\266\205\350\277\20710\344\270\207+\357\274\237.md"
new file mode 100644
index 0000000000..9d34f18d49
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(02) - Redis\345\246\202\344\275\225\351\200\232\350\277\207\350\257\273\345\206\231\345\210\206\347\246\273\346\235\245\346\211\277\350\275\275\350\257\273\350\257\267\346\261\202QPS\350\266\205\350\277\20710\344\270\207+\357\274\237.md"	
@@ -0,0 +1,45 @@
+
+# 1 Redis高并发跟整个系统的高并发之间的关系
+Redis，你要搞高并发的话，不可避免，要把底层的缓存搞得很好
+
+MySQL高并发，做到了，那么也是通过一系列复杂的分库分表，订单系统，事务要求的，QPS到几万，比较高了
+
+要做一些电商的商品详情页，真正的超高并发，QPS上十万，甚至是百万，一秒钟百万的请求量
+
+光是Redis是不够的，但是Redis是整个大型的缓存架构中，支撑高并发的架构里面，非常重要的一个环节
+
+- 首先，你的底层的缓存中间件，缓存系统，必须能够支撑的起我们说的那种高并发
+- 其次，再经过良好的整体的缓存架构的设计（多级缓存架构、热点缓存），支撑真正的上十万，甚至上百万的高并发
+
+# 2 Redis不能支撑高并发的瓶颈
+单机
+![](https://img-blog.csdnimg.cn/20190506220559684.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 3 如果redis要支撑超过10万+的并发，何如？
+单机的Redis几乎不太可能说QPS超过10万+，除非一些特殊情况，比如你的机器性能特别好，配置特别高，物理机，维护做的特别好，而且你的整体的操作不是太复杂
+
+单机在几万
+
+读写分离，一般来说，对缓存，一般都是用来支撑读高并发的，写的请求是比较少的，可能写请求也就一秒钟几千，一两千
+
+大量的请求都是读，一秒钟二十万次读
+
+读写分离
+
+主从架构 -> 读写分离 -> 支撑10万+读QPS的架构
+
+![](https://img-blog.csdnimg.cn/20190506220626223.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 4 接下来要讲解的一个topic
+redis replication
+
+redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(03)-\345\205\263\344\272\216\344\272\222\350\201\224\347\275\221Java\345\267\245\347\250\213\345\270\210\351\235\242\350\257\225\347\252\201\345\207\273\350\256\255\347\273\203\350\257\276\347\250\213\347\232\204\345\207\240\347\202\271\350\257\264\346\230\216.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(03)-\345\205\263\344\272\216\344\272\222\350\201\224\347\275\221Java\345\267\245\347\250\213\345\270\210\351\235\242\350\257\225\347\252\201\345\207\273\350\256\255\347\273\203\350\257\276\347\250\213\347\232\204\345\207\240\347\202\271\350\257\264\346\230\216.md"
new file mode 100644
index 0000000000..691a724675
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(03)-\345\205\263\344\272\216\344\272\222\350\201\224\347\275\221Java\345\267\245\347\250\213\345\270\210\351\235\242\350\257\225\347\252\201\345\207\273\350\256\255\347\273\203\350\257\276\347\250\213\347\232\204\345\207\240\347\202\271\350\257\264\346\230\216.md"
@@ -0,0 +1,47 @@
+# 1 针对的人群
+- 好多同学出去面试，尤其是面互联网行业的Java职位，经常会问一些消息队列、缓存、分库分表、分布式系统之类的问题
+但是可能不少同学之前没有搞过这些，或者略知一二，但是被面试官几个连环炮就给打蒙了
+
+- 不少同学很长时间不面试了，最近要找工作，需要短期突击快速准备一下常见的面试题，至少先给自己热个身，不至于面试的时候一问三不知
+
+- 不面试，但是对这套技术体系不怎么会的同学，可以用这个课程算是扫盲，快速夯实一下互联网公司技术栈的一些基础
+
+- 如果你看一眼，觉得自己基本都会，那么可以绕行
+
+# 2 教程定位
+（1）两周让你快速突击完整的互联网java工程师面试中要掌握的技术体系
+
+（2）针对的是互联网行业的普通java岗位常问的一些面试题，不是针对一些高级、资深、专家等高阶岗位的面试，因为你要是面那些高阶岗位，靠两三周突击是不可能的
+
+（3）所以这里很多问题以及问题的解答，基本可能都是属于科普性的，有一些技术实力比较好的同学
+
+（4）讲解方式走短平快路线，大白话+手工画图，语言精简不拖拉，不说废话，每个问题都直击问题要点即可。课程出发点是帮助那些想要在2周之内完成面试准备，出去找工作的那帮同学
+
+（5）对每个面试题都给你先剖析一下面试官问这个面试题背后的愿意是什么？他为什么要问你这个问题？
+
+（6）能解答每个问题背后的基本原理，至少被问到这些问题别一无所知，自己能回答出来一些原理以及技术方案，代表至少你有这个知识积累
+
+（7）能在面试现场动手画图讲解
+
+（8）能对常见的要求写代码的环节现场手写代码
+
+（9）试想，面试考察范围那么大，如果你每个技术都想要深入学习达到精通，上手能用，能做项目，那你任何一个技术都要学习很长时间。但是面试的时候可不是那么问的，不会问你api和具体操作步骤，主要考察思想、原理以及经验。所以这里我们为了面试准备，就是对每个技术讲解面试的时候常问的一些问题。
+
+能达到这个标准，那么可以短期内快速提升你对常见面试题的应答能力，让很多同学也许在一些互联网java面试时，也许原本很多题目都几乎说不出什么回答，到现在学完这个课程之后可以基本回答常见的技术体系内的面试题
+
+主要设计思想就是针对有面试需求的同学，短期内，短平快的突击一下，大幅度增强你在面试现场的一个表现，增加你通过面试的机会，让你跟很多普通的工程师在面试时的表现迅速拉开差距
+
+所以针对这个定位，我进行几点说明：
+
+1、面试题剖析如何回答时，我会剔除掉很多不必要的细节，就突出很重点。比如有的技术，网上一些博客也许会零零散散写几十点，但是面试的时候你不是背书，不是背博客来回答的，就是讲出来几个重点就可以了。所以有些东西也许我没讲，但是大家要明白不是我不讲，是因为我们要挑重点了解，在面试的时候挑重点来说。
+
+2、对大部分技术点，不会动手去落地实践，比如说RabbitMQ的高可用性，我们就是剖析MQ高可用部署的一个原理，现场大量手工绘图讲清楚如何回答这个东西，确保你被问到的时候，能说清楚整个高可用部署架构以及现场动手画图。但是我不会带着你去安装虚拟机，然后安装rabbitmq，然后再部署高可用架构，然后再进行高可用容灾演练。因为我们的定位是短期内快随突击面试题，转为面试准备，不是动手项目实战课程。
+
+3、对很多技术，我们的定位就是面试被问到的时候，你可以回答出其基本原理，我们不可能对有些技术点刨根问底，深挖到源码级别，那是需要大量时间去讲解的，不是所谓的两三周短平快可以突击的完的。所以确实有可能对于一些要求很高的公司，是可能存在一个问题，人家问你一个问题，你答出来了，接着深挖，你答不出来了，那么此时是没办法的，你要想对各种技术都有深入底层的功底，那不是两三周的事儿，而是两三年的苦功夫才能得到的。
+
+4、有些特别简单的问题，明显只要是个java工程师，学过java的都该知道的问题，我就不讲了。比如说equals和hashcode是啥关系？string类为啥是final的？这类问题，实在是太过基础。
+
+所以特别用几分钟时间跟大家说明白这个问题，大家了解一下这个课程定位，后面学习的时候相信就不会产生什么歧义、误会以及不满了。
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(05)- \346\266\210\346\201\257\351\230\237\345\210\227\346\212\200\346\234\257\351\200\211\345\236\213.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(05)- \346\266\210\346\201\257\351\230\237\345\210\227\346\212\200\346\234\257\351\200\211\345\236\213.md"
new file mode 100644
index 0000000000..c0d6da8bb9
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(05)- \346\266\210\346\201\257\351\230\237\345\210\227\346\212\200\346\234\257\351\200\211\345\236\213.md"	
@@ -0,0 +1,131 @@
+# 1 面试题
+消息队列(以下简称MQ),面试必问技术,工作必会技术,掌握它,是你的义务!!!
+
+- 为什么使用MQ啊？
+- MQ有什么优点和缺点啊？
+- kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景？
+
+# 2 考点分析
+其实面试官主要是想看看：
+
+## 2.1 知否系统缘何使用MQ？
+大量的候选人，说自己项目里用了redis、mq，但是其实他并不知道自己为什么要用这个东西。
+其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾没思考过!!!
+
+没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为进了团队担心你就木头木脑的干呆活儿，不会自己思考。
+
+## 2.2 既然用MQ，知否好处？
+系统中引入MQ之后会不会有什么坏处？
+你要是没考虑过这个，那你盲目弄个MQ进系统里，后面出了问题你是不是就自己删库跑路给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。
+
+就怕你干1年挖一堆坑，自己跑路了，给公司后患无穷,你还野火烧不尽
+
+## 2.3 既然你用了某种MQ,做过调研否？
+你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个MQ，比如kafka。
+甚至都从没调研过业界到底流行的MQ有哪几种？
+每一个MQ的优点和缺点是什么？
+每一个MQ没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。
+
+如果是一个不考虑技术选型的候选人招进了团队，面试官交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑
+
+> 同学啊，如果你看到这里，连activemq、rabbitmq、rocketmq、kafka是什么都不知道？连个hello world demo都没写过？那你。。。还不快关注我的公众号去学习这些!!!
+通过网上查阅技术资料和博客，用于快速入门，是比较合适的
+但是如果要比如系统梳理你的面试技术体系，或者是系统的深入的研究和学习一些东西，看博客实际上是不太合适的
+那也没事，这个教程的定位是不会去讲这些的，建议你马上暂停一下，然后搜一下我的博客，这4个东西是什么？每个东西找一个教你hello world的博客，自己跟着做一遍。我保证你1个小时之内就可以快速入门这几个东西。
+等你先知道这几个东西是什么，同时写过hello world之后，你再来继续看我们的教程
+
+# 3 面试题详解
+## 3.1 缘何使用MQ
+其实就是问问你
+- 消息队列都有哪些使用场景
+- 你项目里具体是什么场景
+- 说说你在这个场景里用消息队列搞什么
+
+面试官问你这个问题，期望的一个回答是说，你有个什么业务场景，这个业务场景有个什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ之后带给了你很多的好处
+
+先说一下
+### 3.1.1 消息队列的常见使用场景
+其实场景有很多，但是比较核心的有3个：解耦、异步、削峰
+
+####  3.1.1.1 解耦
+![](https://img-blog.csdnimg.cn/20190516174449953.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+A系统发送个数据到BCD三个系统，接口调用发送
+
+那如果E系统也要这个数据呢？
+那如果C系统现在不需要了呢？
+现在A系统又要发送第二种数据了呢？
+
+A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头都秃了啊!!!
+
+##### 面试技巧
+你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。
+但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ作解耦。
+
+####  3.1.1.2 异步
+![](https://img-blog.csdnimg.cn/20190516175129333.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+- 使用MQ进行异步化之后的接口性能优化
+![在这里插入图片描述](https://img-blog.csdnimg.cn/2019051617523565.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库
+自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms
+最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了!!!卸载!
+![](https://img-blog.csdnimg.cn/20190516175419852.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+![](https://img-blog.csdnimg.cn/20190516175503573.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+####  3.1.1.3 削峰
+![](https://img-blog.csdnimg.cn/20190516175633796.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。
+![](https://img-blog.csdnimg.cn/20190516175748284.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+
+## 3.2 MQ的优缺点
+
+优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰
+
+缺点呢？显而易见的
+
+### 3.2.1 系统可用性降低
+![](https://img-blog.csdnimg.cn/20190516175809538.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题
+你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。
+
+### 3.2.2 系统复杂性提高
+硬生生加个MQ进来
+- 你怎么保证消息没有重复消费？
+- 怎么处理消息丢失的情况？
+- 怎么保证消息传递的顺序性？
+
+头大头大，问题一大堆，痛苦不已
+
+一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
+
+所以MQ实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。。。
+
+## 3.3 kafka、activemq、rabbitmq、rocketmq各自的优缺点
+常见的MQ其实就这几种，别的还有很多其他MQ，但是比较冷门的，那么就别多说了
+
+作为一个码农，你起码得知道各种mq的优点和缺点吧，咱们来画个表格看看
+![](https://img-blog.csdnimg.cn/20190516180246505.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+综上所述，各种对比之后，倾向于是：
+
+一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
+
+后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高；
+
+不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄
+
+所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择
+
+如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(06)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\253\230\345\217\257\347\224\250\346\200\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(06)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\253\230\345\217\257\347\224\250\346\200\247.md"
new file mode 100644
index 0000000000..25e8ac3412
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(06)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\253\230\345\217\257\347\224\250\346\200\247.md"
@@ -0,0 +1,99 @@
+
+# 0  [Github](https://github.com/Wasabi1234)
+# 1 面试题
+如何保证消息队列的高可用性
+
+# 2 考点分析
+高可用是必问的，因为MQ的缺点很多，导致系统可用性降低。
+所以只要你用了MQ，接下来问的一些要点肯定就是围绕着MQ的那些缺点怎么解决.
+
+要是你傻乎乎的就干用了一个MQ，各种问题从来没考虑过，那你就杯具了，面试官对你的印象就是，只会简单实用一些技术，没任何思考，马上对你的印象就不太好了。
+这样的同学招进来要是做个20k薪资以内的普通小弟还凑合。如果招进来做薪资20多k的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。
+
+# 3 面试题详解
+> 这个问题这么问是很好的，因为不能问你kafka的高可用性怎么保证啊？ActiveMQ的高可用性怎么保证啊？一个面试官要是这么问就显得很没水平，人家可能用的就是RabbitMQ，没用过Kafka，你上来问人家kafka干什么？这不是摆明了刁难人么。
+
+所以有水平的面试官，问的是MQ的高可用性怎么保证？这样就是你用过哪个MQ，你就说说你对那个MQ的高可用性的理解。
+
+## 3.1 RabbitMQ的高可用性
+RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。
+
+rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
+
+### 3.1.1 单机模式
+
+就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
+
+### 3.1.2 普通集群模式
+#### 在多台机器上启动多个RabbitMQ实例，每个机器启动一个
+
+但是你创建的queue，只会放在一个RabbitMQ实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
+
+这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。
+因为这导致
+- 要么消费者每次随机连接一个实例然后拉取数据
+有数据拉取的开销
+- 要么固定连接那个queue所在实例消费数据
+存在单实例的性能瓶颈
+
+而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让RabbitMQ落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
+
+所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
+
+- 架构图如下所示
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561442393591_20190625134112976.png)
+
+
+### 3.1.3 镜像集群模式
+这种才是所谓的RabbitMQ的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
+
+#### 好处
+任何一个机器宕机了，没事儿，别的机器都可以用
+#### 坏处
+- 性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！
+- 这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
+
+那么怎么开启这个镜像集群模式呢？其实很简单RabbitMQ有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
+
+- 架构图如下所示![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561442393691_2019062513562281.png)
+## 3.2 kafka的高可用性
+kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。
+
+这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。
+
+实际上RabbitMQ之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，RabbitMQ一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。
+
+kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
+
+kafka 0.8以后，提供了HA机制，就是replica副本机制
+- 每个partition的数据都会同步到其他机器上，形成自己的多个replica副本
+- 然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道
+- 其他replica就是follower
+
+如此一来
+- 写的时候，leader会负责把数据同步到所有follower上去
+- 读的时候就直接读leader上数据即可
+
+只能读写leader?
+很简单，要是你可以随意读写每个follower，那么就要关心数据一致性的问题，系统复杂度太高，很容易出问题
+kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。
+
+这么搞，就有所谓的`高可用性`了
+因为如果某个broker宕机了，没事儿，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性
+
+写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
+
+消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。
+
+实际上这块机制，讲深了，是可以非常之深入的，但是我还是回到我们这个课程的主题和定位，聚焦面试，至少你听到这里大致明白了kafka是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要遇上面试官确实是kafka高手，深挖了问，那你只能说不好意思，太深入的你没研究过。
+
+但是大家一定要明白，这个事情是要权衡的，你现在是要快速突击常见面试题体系，而不是要深入学习kafka，要深入学习kafka，你是没那么多时间的。你只能确保，你之前也许压根儿不知道这块，但是现在你知道了，面试被问到，你大概可以说一说。然后很多其他的候选人，也许还不如你，没看过这个，被问到了压根儿答不出来，相比之下，你还能说点出来，大概就是这个意思了
+
+- 架构图如下所示
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561442393646_20190625135733326.png)
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+> 更多干货请关注JavaEdge公众号
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(07)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\344\270\215\351\207\215\345\244\215\346\266\210\350\264\271\346\225\260\346\215\256.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(07)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\344\270\215\351\207\215\345\244\215\346\266\210\350\264\271\346\225\260\346\215\256.md"
new file mode 100644
index 0000000000..0df10b499b
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(07)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\344\270\215\351\207\215\345\244\215\346\266\210\350\264\271\346\225\260\346\215\256.md"
@@ -0,0 +1,60 @@
+# 1 面试题
+如何保证消息队列不重复消费数据,即如何保证消息消费时的幂等性?
+
+# 2 考点分析
+消费消息，那肯定要考虑考虑会不会重复消费.
+能不能避免重复消费,或者重复消费了也别造成系统异常可以嘛?
+
+这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题。
+
+面试官问你，肯定是必问的，这是你要考虑的实际生产上的系统设计问题。
+
+# 3 详解
+先大概说一说可能会有哪些重复消费的问题。
+
+首先就是比如rabbitmq、rocketmq、kafka，都有可能会出现消费重复消费的问题.
+因为这问题通常不是mq自己保证的，是给你保证的.
+
+我们挑一个kafka来举个例子，说说
+## 3.1 如何重复消费
+kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的offset来继续消费吧.
+
+但是凡事总有意外，有时候重启系统，看你怎么重启了，如果碰到点着急的，直接kill进程了，再重启。这会导致consumer有些消息处理了，但是没来得及提交offset
+尴尬了!重启之后，少数消息会再次消费一次。
+
+其实重复消费不可怕，可怕的是你没考虑到重复消费之后，怎么保证幂等性。
+
+给你举个例子吧。假设你有个系统，消费一条往数据库里插入一条，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？
+但是你要是消费到第二次的时候，自己判断一下已经消费过了，直接扔了，不就保留了一条数据？
+
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561445338875_20190625142648438.png)
+
+一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性
+
+> 幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错。
+
+那所以第二个问题来了
+## 3.2 怎么保证消息队列消费的幂等性？
+其实还是得结合业务来思考，这里给几个思路：
+- 比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下好嘛
+- 比如你是写redis，那没问题了，反正每次都是set，天然幂等性
+- 比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你消费后，先根据该id去比如redis里查询，之前消费过吗？
+  - 未消费，就处理，然后将该id写redis
+  - 已消费，就别处理了，保证不重复处理相同的消息即可。
+
+还有比如基于数据库的唯一键来保证重复数据不会重复插入多条
+> 拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据
+
+
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561445338863_20190625142719969.png)
+如何保证MQ的消费是幂等性的，是需要结合具体的业务来看的
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(10)-\347\231\276\344\270\207\346\266\210\346\201\257\345\234\250\346\266\210\346\201\257\351\230\237\345\210\227\351\207\214\347\247\257\345\216\213\344\272\206\345\207\240\344\270\252\345\260\217\346\227\266.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(10)-\347\231\276\344\270\207\346\266\210\346\201\257\345\234\250\346\266\210\346\201\257\351\230\237\345\210\227\351\207\214\347\247\257\345\216\213\344\272\206\345\207\240\344\270\252\345\260\217\346\227\266.md"
new file mode 100644
index 0000000000..225b4fda04
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(10)-\347\231\276\344\270\207\346\266\210\346\201\257\345\234\250\346\266\210\346\201\257\351\230\237\345\210\227\351\207\214\347\247\257\345\216\213\344\272\206\345\207\240\344\270\252\345\260\217\346\227\266.md"
@@ -0,0 +1,60 @@
+# 1 面试题
+如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
+
+# 2 考点分析
+你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了，或者消费的极其极其慢。
+接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？
+或者是整个这就积压了几个小时，你这个时候怎么办？
+或者是你积压的时间太长了，导致比如rabbitmq设置了消息过期时间后就没了怎么办？
+
+所以就这事儿，其实线上挺常见的，一般不出，一出就是大事件.
+
+举个例子，消费端每次消费之后要写MySQL，结果MySQL挂了，消费端hang那儿了，不动了。或者是消费端出了个什么叉子，导致消费速度极其慢。
+
+# 3 详解
+先假设一个场景，我们现在消费端出故障了，然后大量消息在mq里积压，现在事故了，慌了
+
+## 3.1 大量消息在mq里积压了几小时了还没解决
+几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多
+
+这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。
+
+一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条
+
+所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来
+
+一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下：
+
+1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
+2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
+3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
+4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
+5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
+6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息
+
+## 3.2 第二坑
+假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。
+
+这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。
+
+这个情况下，就不是说要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。
+我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。
+就是大量积压的时候，就直接丢弃数据，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。
+
+这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。
+
+假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次
+
+## 3.3 第三坑
+如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？
+这个还有别的办法吗？没有.
+谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。
+然后走第二个方案，到了晚上再补数据吧。
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(11)-\344\275\240\346\200\216\344\271\210\350\256\276\350\256\241\344\270\200\344\270\252\346\266\210\346\201\257\351\230\237\345\210\227?.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(11)-\344\275\240\346\200\216\344\271\210\350\256\276\350\256\241\344\270\200\344\270\252\346\266\210\346\201\257\351\230\237\345\210\227?.md"
new file mode 100644
index 0000000000..d299b45259
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(11)-\344\275\240\346\200\216\344\271\210\350\256\276\350\256\241\344\270\200\344\270\252\346\266\210\346\201\257\351\230\237\345\210\227?.md"
@@ -0,0 +1,46 @@
+# 1 面试题
+
+如果让你写一个消息队列，该如何进行架构设计啊？说一下你的思路
+
+# 2 考点分析
+
+一般面试官要考察两块：
+
+（1）你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个mq的架构原理
+
+（2）看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来
+
+> 说实话，一般面类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。
+类似的问题，我=经常问的还有，如果让你来设计一个spring框架你会怎么做？如果让你来设计一个dubbo框架你会怎么做？如果让你来设计一个mybatis框架你会怎么做？
+
+# 3 详解
+其实回答这类问题，说白了，不求你看过那技术的源码，起码你大概知道那个技术的基本原理，核心组成部分，基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好
+
+比如说这个消息队列系统，我们来从以下几个角度来考虑一下
+
+## 3.1 支持可伸缩性
+需要的时候快速扩容，就可增加吞吐量和容量，那怎么搞？
+设计个分布式的系统呗，参照一下kafka的设计理念，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？
+
+## 3.2 数据落地
+
+那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。
+
+## 3.3 其次你考虑一下你的mq的可用性啊
+这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。
+
+## 3.4 支持数据0丢失
+可以的，参考我们之前说的那个kafka数据零丢失方案
+
+其实一个mq肯定是很复杂的，面试官问你这个问题，其实是个开放题，他就是看看你有没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人，因为大部分人平时不思考这些东西。
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://upload-images.jianshu.io/upload_images/16782311-8d7acde57fdce062.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(12) - \346\200\273\347\273\223\346\266\210\346\201\257\351\230\237\345\210\227\347\233\270\345\205\263\351\227\256\351\242\230\347\232\204\351\235\242\350\257\225\346\212\200\345\267\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(12) - \346\200\273\347\273\223\346\266\210\346\201\257\351\230\237\345\210\227\347\233\270\345\205\263\351\227\256\351\242\230\347\232\204\351\235\242\350\257\225\346\212\200\345\267\247.md"
new file mode 100644
index 0000000000..82ecbe1fd4
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(12) - \346\200\273\347\273\223\346\266\210\346\201\257\351\230\237\345\210\227\347\233\270\345\205\263\351\227\256\351\242\230\347\232\204\351\235\242\350\257\225\346\212\200\345\267\247.md"	
@@ -0,0 +1,24 @@
+
+一般而言，如果一个面试官水平还算不错，会沿着从浅入深的环节深入挖一个点。
+
+其实按照这个思路可以一直问下去，除了这里的7个问题之外，甚至能挑着你熟悉的一个mq一直问到源码级别非常底层。
+
+还可能会结合项目来仔细问，可能会先让你给我详细说说你的业务细节，然后将你的业务跟这些mq的问题场景结合起来，看看你每个细节是怎么处理的。
+
+但是确实因为我们这个是面试突破型教程，不是什么kafka源码剖析课，也不是什么RocketMQ高并发架构项目实战课程，所以只能讲到这个程度。
+
+所以我们这个课程只能让你从大面儿上，基本常见问题可以回答出来。基本上mq这块你能答到这个程度，你基本知识面儿是有了，但是深度是绝对没有的。所以如果一个面试官就问问这些问题，感觉你面儿上过的去了，那就恭喜你了。但是如果碰到我这种难缠的面试官，喜欢深挖底层，细扣项目细节的，那可能确实是不行的。
+
+如果你碰到人家在7个问题之外还死扣着你问的，那你最好是认一下怂，就说你确实没研究那么深过，如果你面的就是个一般的职位，那可能就过去了。就我而言，如果招聘的就是个普通职位，而你能答到这个程度，那么就觉得说的过去了。毕竟说实话，相当大比例的程序员出去面java职位的时候，mq这块还回答不到这个程度呢。你能答好这些，至少比之前一无所知的你好了一些，也比很多没准备过的程序员都好了很多。
+
+最后说一个技巧，要是确实碰一个面试官连这7个问题都没问满，只要他提到mq，你自己就和盘托出一整套的东西，你就说，mq你们之前遇到过什么问题，巴拉巴拉，你们的方案是什么，自己突出自己会的东西
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://upload-images.jianshu.io/upload_images/16782311-8d7acde57fdce062.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(13)\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\350\277\236\347\216\257\347\202\256.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(13)\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\350\277\236\347\216\257\347\202\256.md"
new file mode 100644
index 0000000000..be8b5f332c
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(13)\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\350\277\236\347\216\257\347\202\256.md"
@@ -0,0 +1,32 @@
+业内目前来说事实上的一个标准，就是分布式搜索引擎一般大家都用elasticsearch
+
+
+# lucene
+如果你确实真的不连lucene都不知道是什么？我觉得你确实不应该，lucene底层的原理是一个东西，叫做倒排索引。太基础了。
+
+百度，搜索一下lucene入门，了解一下lucene是什么？倒排索引是什么？全文检索是什么？写个lucene的demo程序体验一把。
+
+# elasticsearch
+
+百度，搜索一下：elasticsearch入门，初步至少知道es的一些基本概念，然后包括es的基本部署和基本的使用
+
+
+# 面试官可能会怎么问？
+
+（1）es的分布式架构原理能说一下么（es是如何实现分布式的啊）？
+
+（2）es写入数据的工作原理是什么啊？es查询数据的工作原理是什么啊？
+
+（3）es在数据量很大的情况下（数十亿级别）如何提高查询性能啊？
+
+（4）es生产集群的部署架构是什么？每个索引的数据量大概有多少？每个索引大概有多少个分片？
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://upload-images.jianshu.io/upload_images/16782311-8d7acde57fdce062.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(14)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\347\232\204\346\236\266\346\236\204.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(14)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\347\232\204\346\236\266\346\236\204.md"
new file mode 100644
index 0000000000..8fab13a554
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(14)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\347\232\204\346\236\266\346\236\204.md"
@@ -0,0 +1,103 @@
+> 以下用ES表Elastic Search
+# 1 面试题
+说说ES的分布式架构原理
+
+# 2 考点分析
+在搜索这块，曾经lucene 是最流行的搜索库.
+几年前业内一般都问，你了解 lucene 吗？你知道倒排索引的原理吗？
+但现在不问了,因为现在项目基本都是采用基于 lucene 的分布式搜索引擎—— ElasticSearch.
+
+现在分布式搜索基本已经成为互联网系统的标配，其中尤为流行的就是 ES，前几年一般用 solr。但是最近基本大部分企业和项目都开始转向 ES.
+
+所以互联网面试，肯定会跟你聊聊分布式搜索引擎，就一定会聊到ES!
+
+如果面试官问你第一个问题，确实一般都会问你 es 的分布式架构设计能介绍一下么？就看看你对分布式搜索引擎架构的一个基本理解。
+
+# 3 详解
+ES的设计理念就是分布式搜索引擎，底层其实还是基于 lucene 的.
+`核心思想`就是在多台机器上启动多ES进程实例，组成ES集群.
+
+## 3.1 基本单位
+ES 中存储数据的`基本单位`是**索引**.
+比如说你现在要在 ES 中存储一些订单数据，应该在 ES 中创建一个索引 `order_idx`,所有的订单数据就会写到该索引中.
+一个索引概念上差不多就相当于MySQL 中的一张表.
+
+```
+index -> type -> mapping -> document -> field。
+```
+
+## 3.2 实例
+为便于理解,我在这里做个类比.切记,仅仅是类比!绝不等同!
+
+index 相当于 MySQL 里的一张表;
+而 type 没法跟 MySQL 里去类比;
+一个 index 里可以有多个 type，每个 type 的字段都是差不多的，也有略微差别.
+
+假设有一个订单 index，专门存放订单数据.
+就好比说你在 MySQL 中建表
+- 有些订单是实物商品的订单，比如一件衣服、一双鞋子
+- 有些订单是虚拟商品的订单，比如游戏点卡，话费充值
+
+这两种订单大部分字段是一样的，但是少部分字段还是有略微差别.
+
+类似地,ES就会在订单 index,建两个 type
+- 一个是实物商品订单 type
+- 一个是虚拟商品订单 type
+
+这两个 type 大部分字段是一样的，少部分字段是不一样的。
+
+很多情况下，一个 index 里可能就一个 type，但是确实如果说是一个 index 里有多个 type 的情况
+
+> `mapping types` 这个概念在 ElasticSearch 7.X 已被完全移除，详细说明参考[官方文档](https://github.com/elastic/elasticsearch/blob/6.5/docs/reference/mapping/removal_of_types.asciidoc)
+
+你可以认为 index 是一个类别的表，具体的每个 type 代表了 MySQL 中的一个表.
+每个 type 有一个 mapping,如果假设一个 type 是具体的一个表,index 就代表多个 type 同属于的一个类型,而 mapping 就是这个 type 的**表结构定义**.
+你在 MySQL 中创建一个表，肯定是要定义表结构的，里面有哪些字段，每个字段是什么类型.
+实际上你往 index 里的一个 type 里面写的一条数据，叫做一条 document;
+一条 document 就类似 MySQL 中某个表里的一行;
+每个 document 有多个 field;
+每个 field 就代表该 document 中的一个字段的值.
+
+## 3.3 结构原理
+
+![](https://uploadfiles.nowcoder.com/files/20190626/5088755_1561482860411_es-index-type-mapping-document-field.png)
+
+你建立一个索引,该索引又可拆分成多个 `shard`,每个 shard 存储部分数据.
+拆分成多个 shard 是有好处的
+- **支持横向扩展**
+比如你数据量 3T，3 个 shard,每个 shard 就 1T 的数据,若现在数据量增到 4T,怎么扩展?
+so easy!新建一个有 4 个 shard 的索引，将数据导入
+- **提高性能**
+数据分布在多个 shard,即多台服务器上,所有的操作,都会在多台机器上并行分布式执行,提高了系统的吞吐量和性能.
+
+接着就是这个 shard 的数据实际是有多个备份,即每个 `shard` 都有一个 `primary shard`负责写入数据,还有几个 `replica shard`.
+`primary shard` 写入数据后,会将数据同步到其他几个 `replica shard` 中.
+
+![](https://uploadfiles.nowcoder.com/files/20190626/5088755_1561482858175_20190626004810113.png)
+通过 replica 方案,每个 shard 数据都有多个备份.
+即使某个节点宕机,其他节点上还有数据,满足高可用性.
+
+## 3.4 主从特性
+ES 集群的多个节点,会自动选举一个节点为 master 节点;
+master 节点负责一些管理工作,比如维护索引元数据、切换` primary shard` 和` replica shard` 身份等;
+若 master 节点宕机,则会重新选举一个节点为 master.
+
+若非 master 节点宕机了,则 master 节点会使宕机节点上的` primary shard `的身份转移到其他可用节点上的 `replica shard`.
+接着你要是修复了那个宕机节点,重启后,master 节点会控制将缺失的` replica shard` 分配回去,并且同步后续修改的数据之类的,让集群恢复正常.
+
+更简单点,若某非 master 节点宕机了,那么该节点上的 `primary shard `不也就没了嘛.
+那好,master 会让` primary shard` 对应的 `replica shard`（在其他节点上）切换为` primary shard`.待宕机的节点修复了,修复后的节点也不再是 `primary shard`了,而是 `replica shard`.
+
+以上就是 ElasticSearch 作为分布式搜索引擎最基本的架构设计.
+
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+> 更多干货资源请关注JavaEdge公众号
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(15)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216Elastic Search\347\232\204\345\267\245\344\275\234\346\265\201\347\250\213.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(15)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216Elastic Search\347\232\204\345\267\245\344\275\234\346\265\201\347\250\213.md"
new file mode 100644
index 0000000000..bfb75e5aee
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(15)-\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216Elastic Search\347\232\204\345\267\245\344\275\234\346\265\201\347\250\213.md"	
@@ -0,0 +1,142 @@
+> 以下用ES表Elastic Search
+
+# 1 面试题
+ES写入/查询数据的工作原理是什么呀？
+
+# 2 考点分析
+面试官就是想看看你是否了解ES的一些基本原理.
+ES无非就是写/查数据,你如果不明白你发起写入/搜索请求后,ES做了什么,那你该劝退了.
+
+# 3 详解
+## 3.1 ES写数据的执行流程
+- 客户端选择一个node发送请求过去,该node就是coordinating node(协调节点);
+- coordinating node对document进行路由,将请求转发给对应的node(有primary shard);
+- 实际的node上的primary shard处理请求,然后将数据同步到replica node;
+- coordinating node若发现primary node和所有replica node都响应完操作后,就返回结果给客户端.
+
+## 3.2 ES读数据的执行流程
+查询，GET某一条数据，写入了某个document,该document会自动给你分配一个全局唯一id-doc id,同时也是根据doc id进行hash路由到对应的primary shard上面去.也可以手动指定doc id,比如用订单id,用户id.
+
+可以通过doc id来查询,会根据doc id进行hash,判断出当时把doc id分配到了哪个shard,从那个shard去查询
+
+- 客户端发送请求到任意一个node，成为coordinate node
+- coordinate node对document路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法，在primary shard及其所有replica中随机选择，使读请求负载均衡
+- 接收请求的node返回document给coordinate node
+- coordinate node返回document给客户端
+
+## 3.3 ES查询数据的执行流程
+最强大的是做全文检索,比如有三条数据
+```
+JavaEdge公众号呀
+Java学习者们建议关注哦
+java就很好学了呢
+```
+> 注意这里的字母大小写哟~
+
+根据Java关键词来搜索,将包含Java的document给搜索出来
+
+ES就会给你返回：JavaEdge公众号呀,Java学习者们建议关注哦
+
+- 客户端发送请求到一个coordinate node
+- 协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard
+- query phase
+每个shard将自己的搜索结果（本质上就是一些doc id），返回给coordinate node，由coordinate node进行数据的合并、排序、分页等,以生成最终结果
+- fetch phase
+接着由coordinate node,根据doc id去各节点中拉取实际的document数据,最终返回给客户端
+
+## 3.4 搜索的底层原理 - 倒排索引
+### 画图说明传统数据库和倒排索引的区别
+(待更新...)
+## 3.5 ES 写数据的执行流程
+- ES读写底层原理示意图
+![](https://uploadfiles.nowcoder.com/files/20190627/5088755_1561579921192_20190627022247544.png)
+
+
+(1)  先写入buffer,在buffer里的时候数据是搜索不到的;同时将数据写入translog日志文件
+(2)  如果buffer将满,或者定时,就会将buffer中的数据refresh到一个新的segment file中
+但此时数据不是直接进入segment file磁盘文件的,而是先进入os cache,即refresh.
+
+每1s,ES 将buffer中的数据写到一个**新的segment file**,segment file磁盘文件每 s 生成一个,其只存储最近1s内buffer中写入的数据
+
+- 如果buffer中此时无数据,自然不会执行refresh操作
+- 如果buffer中有数据,默认每1s执行一次refresh,刷入一个新的segment file中
+
+在操作系统的磁盘文件中都有os cache(操作系统缓存),即数据写入磁盘文件前,会先进入os cache,即进入OS级别的一个内存缓存
+
+只要buffer中的数据被refresh刷入os cache,该数据就可被搜索到
+
+为什么称 ES 是准实时(NRT，near real-time)的?
+默认每1 s refresh一次,所以 ES 是准实时的,写入的数据1s之后才能被观测到.
+可以通过ES的RESRful API或者Java API,手动执行一次refresh,即手动将buffer中数据刷入os cache,让数据立马就可被搜索到.只要数据被输入os cache中,buffer就会被清空,因为不需要保留缓存了,数据在translog里面已经持久化到磁盘.
+
+(3) 只要数据进入os cache，此时就可以让这个segment file的数据对外提供搜索服务了.
+
+(4) 重复1~3步骤,新数据不断进入buffer和translog,不断将buffer数据写入一个个segment file,每次refresh完,清空buffer,保留translog.
+随着该过程不断推进,translog会变臃肿,当translog达到一定大小时,就会触发commit操作.
+
+> buffer中的数据，倒是好，每隔1秒就被刷到os cache中去，然后这个buffer就被清空了。所以说这个buffer的数据始终是可以保持住不会填满es进程的内存的。
+每次一条数据写入buffer，同时会写入一条日志到translog日志文件中去，所以这个translog日志文件是不断变大的，当translog日志文件大到一定程度的时候，就会执行commit操作。
+
+(5) commit操作第一步,就是将buffer中现有数据refresh到os cache,清空buffer
+
+(6）将一个commit point写到磁盘,以标识该commit point对应的所有segment file
+
+(7）强行将os cache中所有数据都fsync到磁盘
+
+> translog日志文件的作用是什么？
+就是在你执行commit之前,数据要么是停留在buffer中,要么os cache中
+无论是buffer还是os cache都是内存,一旦这台机器宕掉,数据就会全丢
+所以需要将数据对应的操作写入一个专门的日志文件，translog日志文件中，一旦此时机器宕机，再次重启的时候，ES会自动读取translog日志文件中的数据，恢复到内存buffer和os cache中去。
+
+#### commit操作
+- 写commit point
+- 将os cache数据fsync强刷到磁盘上去
+- 清空translog日志文件
+
+(8) 将现有的translog清空,接着重启启用一个translog，此时commit操作完成。默认每隔30分钟会自动执行一次commit，但是如果translog过大，也会触发commit。整个commit的过程，叫做flush操作。我们可以手动执行flush操作，就是将所有os cache数据刷到磁盘文件中去。
+
+不叫做commit操作，flush操作。es中的flush操作，就对应着commit的全过程。我们也可以通过es api，手动执行flush操作，手动将os cache中的数据fsync强刷到磁盘上去，记录一个commit point，清空translog日志文件。
+
+9）translog其实也是先写入os cache,默认每5s刷到磁盘
+所以默认情况下,可能有5秒的数据仅仅驻存在buffer或者translog文件的os cache中,若此时机器宕机,会丢失5s的数据.
+但是这样性能比较好,最多丢5s的数据.也可将translog设置成每次写操作必须是直接fsync到磁盘，但是性能会差很多.
+
+> 实际上在这里,若面试官没有问你ES丢数据的问题,就可在这里给面试官炫一把:
+其实ES第一是准实时性的,数据写入1s后可以搜索到;
+可能会丢失数据，你的数据有5s会停留在buffer/translog os cache/segment file os cache中,有5s的数据不在磁盘上,此时如果宕机,会导致这5s的数据丢失.
+
+如果你希望一定不能丢失数据的话，你可以设置个参数，官方文档，百度一下.
+每次写入一条数据，都是写入buffer，同时写入磁盘上的translog，但是这会导致写性能、写入吞吐量会下降一个数量级.
+本来一秒钟可以写2000条，现在你一秒钟只能写200条，都有可能.
+
+
+### 小结
+数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）.
+每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中.
+
+> 数据写入 segment file 之后，同时就建立好了倒排索引。
+
+## 3.6 ES 删除数据的执行流程
+(1) commit时会生成一个.del文件,将某个doc标识为deleted态,那么搜索的时候根据.del文件就知道该doc已被删除
+
+## 3.7 ES 更新数据的执行流程
+(1) 将原来的doc标识为deleted状态，然后新写入一条数据
+
+(2) buffer每refresh一次，就会产生一个segment file，所以默认情况下是1s一个segment file，segment file会越来越多，此时会定期执行merge
+
+(3) 每次merge时,会将多个segment file合并成一个，同时这里会将标识为deleted的doc给**物理删除**掉，然后将新的segment file写入磁盘，这里会写一个commit point，标识所有新的segment file，然后打开segment file供搜索使用，同时删除旧的segment file.
+
+> ES 里的写流程，有4个底层的核心概念，refresh、flush、translog、merge
+当segment file多到一定程度的时候，es就会自动触发merge操作，将多个segment file给merge成一个segment file。
+
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+> 更多干货请关注JavaEdge公众号
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(17)-\344\275\240\344\273\254\345\205\254\345\217\270\347\224\237\344\272\247\347\216\257\345\242\203\347\232\204\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\346\230\257\346\200\216\344\271\210\351\203\250\347\275\262\347\232\204\345\221\242.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(17)-\344\275\240\344\273\254\345\205\254\345\217\270\347\224\237\344\272\247\347\216\257\345\242\203\347\232\204\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\346\230\257\346\200\216\344\271\210\351\203\250\347\275\262\347\232\204\345\221\242.md"
new file mode 100644
index 0000000000..c54ebba9e6
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(17)-\344\275\240\344\273\254\345\205\254\345\217\270\347\224\237\344\272\247\347\216\257\345\242\203\347\232\204\345\210\206\345\270\203\345\274\217\346\220\234\347\264\242\345\274\225\346\223\216\346\230\257\346\200\216\344\271\210\351\203\250\347\275\262\347\232\204\345\221\242.md"
@@ -0,0 +1,27 @@
+# 1 面试题
+- ES集群部署架构如何
+- 每个索引的数据量大概多少
+- 每个索引大概有多少分片
+
+# 2 考点分析
+问你生产环境咋部署的,说白了,没啥技术含量,就是看你有没有在真正的生产环境里做过ES!
+
+有些同学可能没在生产环境做过,没在线上部署过ES集群,也没实际玩过,也没往ES集群里面导入过几千万甚至是几亿的数据量,可能你就不太清楚这里面的一些生产项目中的细节
+
+如果你是自己就玩过demo,没碰过真实的ES集群,那你可能此时会懵,但是别怕!
+你一定要云淡风轻的回答,表示你确实干过ES!
+
+# 3 详解
+如果你确实干过ES,那你肯定了解你们生产es集群的实际情况，部署了几台机器？有多少个索引？每个索引有多大数据量？每个索引给了多少个分片？你肯定知道！
+
+但是如果你确实没干过，也别虚，我给你说一个基本的版本，你到时候就简单说一下就好了
+
+- ES生产集群我们部署了5台机器，每台机器是6核64G的，集群总内存是320G
+- 我们ES集群的日增量数据大概是2000万条，每天日增量数据大概是500MB，每月增量数据大概是6亿，15G。目前系统已经运行了几个月，现在es集群里数据总量大概是100G左右
+- 目前线上有5个索引（这个结合你们自己业务来，看看自己有哪些数据可以放ES的），每个索引的数据量大概是20G，所以这个数据量之内，我们每个索引分配的是8个shard，比默认的5个shard多了3个shard
+
+大概就这么意思一下就OK!
+
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(18)-\346\266\210\346\201\257\351\230\237\345\210\227\351\235\242\350\257\225\346\212\200\345\267\247\346\200\273\347\273\223.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(18)-\346\266\210\346\201\257\351\230\237\345\210\227\351\235\242\350\257\225\346\212\200\345\267\247\346\200\273\347\273\223.md"
new file mode 100644
index 0000000000..e69de29bb2
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(19) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\347\232\204\347\254\254\344\270\200\344\270\252\351\227\256\351\242\230.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(19) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\347\232\204\347\254\254\344\270\200\344\270\252\351\227\256\351\242\230.md"
new file mode 100644
index 0000000000..6e51200089
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(19) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\347\232\204\347\254\254\344\270\200\344\270\252\351\227\256\351\242\230.md"	
@@ -0,0 +1,61 @@
+
+# 1 面试题
+在项目中缓存是如何使用的？缓存如果使用不当会造成什么后果？
+
+# 2 考点分析
+这个问题，互联网公司必问，要是一个人连缓存都不太清楚，那确实比较尴尬
+
+只要问到缓存，上来第一个问题，肯定能是先问问你项目哪里用了缓存？为啥要用？不用行不行？如果用了以后可能会有什么不良的后果？
+
+这就是看看你对你用缓存这个东西背后，有没有思考，如果你就是傻乎乎的瞎用，没法给面试官一个合理的解答。那我只能说，面试官对你印象肯定不太好，觉得你平时思考太少，就知道干活儿。
+
+#  3 详解
+一个一个来看
+
+## 3.1 在项目中缓存是如何使用的？
+这个，你结合你自己项目的业务来，你如果用了那恭喜你，你如果没用那不好意思，你硬加也得加一个场景吧
+
+## 3.2 为啥在项目里要用缓存呢？
+用缓存，主要是俩用途，高性能和高并发
+
+### 3.2.1 高性能
+- 缓存是如何实现高性能的
+![](https://img-blog.csdnimg.cn/20190511193932111.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+假设这么个场景，你有个操作，一个请求过来，吭哧吭哧你各种乱七八糟操作mysql，半天查出来一个结果，耗时600ms。但是这个结果可能接下来几个小时都不会变了，或者变了也可以不用立即反馈给用户。那么此时咋办？
+
+缓存啊，折腾600ms查出来的结果，扔缓存里，一个key对应一个value，下次再有人查，别走mysql折腾600ms了。直接从缓存里，通过一个key查出来一个value，2ms搞定。性能提升300倍。
+
+这就是所谓的高性能。
+
+就是把你一些复杂操作耗时查出来的结果，如果确定后面不咋变了，然后但是马上还有很多读请求，那么直接结果放缓存，后面直接读缓存就好了。
+
+### 3.2.2 高并发
+- 缓存是如何实现高并发的
+![](https://img-blog.csdnimg.cn/2019051119400978.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+mysql这么重的数据库，压根儿设计不是让你玩儿高并发的，虽然也可以玩儿，但是天然支持不好。mysql单机支撑到2000qps也开始容易报警了。
+
+所以要是你有个系统，高峰期一秒钟过来的请求有1万，那一个mysql单机绝对会死掉。你这个时候就只能上缓存，把很多数据放缓存，别放mysql。缓存功能简单，说白了就是key-value式操作，单机支撑的并发量轻松一秒几万十几万，支撑高并发so easy。单机承载并发量是mysql单机的几十倍。
+
+## 3.3 所以你要结合这俩场景考虑一下，你为啥要用缓存？
+一般很多同学项目里没啥高并发场景，那就别折腾了，直接用高性能那个场景吧，就思考有没有可以缓存结果的复杂查询场景，后续可以大幅度提升性能，优化用户体验，有，就说这个理由，没有？？那你也得编一个出来吧，不然你不是在搞笑么
+
+## 3.4 缓存的不良后果
+呵呵。。。你要是没考虑过这个问题，那你就尴尬了，面试官会觉得你头脑简单，四肢也不发达。你别光是傻用一个东西，多考虑考虑背后的一些事儿。
+
+常见的缓存问题有以下几点
+- 缓存与数据库双写不一致
+- 缓存雪崩
+- 缓存穿透
+- 缓存并发竞争
+
+这是常见面试题，后面我要讲，大家看到后面自然就知道了，但是人要是问你，你至少自己能说出来，并且给出对应的解决方案
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(20)-Redis\347\272\277\347\250\213\346\250\241\345\236\213.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(20)-Redis\347\272\277\347\250\213\346\250\241\345\236\213.md"
new file mode 100644
index 0000000000..d7ee6c915b
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(20)-Redis\347\272\277\347\250\213\346\250\241\345\236\213.md"
@@ -0,0 +1,92 @@
+
+# 1 面试题
+redis和memcached有什么区别？redis的线程模型是什么？为什么单线程的redis比多线程的memcached效率要高得多（为什么redis是单线程的但是还可以支撑高并发）？
+
+# 2 考点分析
+这个是问redis的时候，最基本的问题，redis最基本的一个内部原理和特点，就是redis实际上是个单线程工作模型，你要是这个都不知道，那后面玩儿redis的时候，出了问题岂不是什么都不知道？
+
+还有可能面试官会问问你redis和memcached的区别，不过说实话，最近这两年，作为面试官都不太喜欢这么问了，memched是早些年各大互联网公司常用的缓存方案，但是现在近几年基本都是redis，没什么公司用memcached了
+
+> 额外的友情提示
+同学，你要是现在还不知道redis和memcached是啥？那你赶紧百度一下redis入门和memcahced入门，简单启动一下，然后试一下几个简单操作，先感受一下。接着回来继续看，我觉得1小时以内你就搞定了。
+另外一个友情提示，要听明白redis的线程模型，你需要了解socket网络相关的基本知识，如果不懂,那我觉得你java没学好吧。初学者都该学习java的socket网络通信相关知识
+
+# 4 详解
+## 4.1 redis和memcached的区别
+
+这个事儿吧，你可以比较出N多个区别来，但是我还是采取redis作者给出的几个比较吧
+
+###  4.1.1 Redis支持服务器端的数据操作
+Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作
+- 通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去,这大大增加了网络IO的次数和数据体积
+- 在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
+
+###  4.1.2 内存使用效率对比
+使用简单的KV存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
+
+###  4.1.3 性能对比
+- Redis只使用单核
+- Memcached可以使用多核
+
+所以平均每一个核上Redis在存储小数据时比Memcached性能更高
+而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，稍有逊色。
+
+###  4.1.4 集群模式
+- memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据
+- 但是redis目前是原生支持cluster模式的，redis官方就是支持redis cluster集群模式的，比memcached来说要更好
+
+## 4.2 Redis的线程模型
+![](https://img-blog.csdnimg.cn/20190511180551350.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+### 4.2.1 文件事件处理器
+redis基于reactor模式开发了网络事件处理器，这个处理器叫做文件事件处理器，file event handler
+
+这个文件事件处理器，是单线程的，redis才叫做单线程的模型，采用IO多路复用机制同时监听多个socket，根据socket上的事件来选择对应的事件处理器来处理这个事件。
+
+如果被监听的socket准备好执行`accept`、`read`、`write`、`close`等操作时，跟操作对应的文件事件就会产生，这个时候文件事件处理器就会调用之前关联好的事件处理器来处理对应事件。
+
+文件事件处理器是单线程模式运行的，但是通过IO多路复用机制监听多个socket，实现高性能的网络通信模型，又可以跟内部其他单线程的模块进行对接，保证了redis内部的线程模型的简单性。
+
+文件事件处理器的结构包含4个部分
+- 多个socket
+- IO多路复用程序
+- 文件事件分派器
+- 事件处理器（命令请求处理器、命令回复处理器、连接应答处理器，等等）
+
+多个socket可能并发的产生不同的操作，每个操作对应不同的文件事件，但是IO多路复用程序会监听多个socket，但是会将socket放入一个队列中排队，每次从队列中取出一个socket给事件分派器，事件分派器把socket给对应的事件处理器。
+
+然后一个socket的事件处理完之后，IO多路复用程序才会将队列中的下一个socket给事件分派器。文件事件分派器会根据每个socket当前产生的事件，来选择对应的事件处理器来处理。
+
+### 4.2.2 文件事件
+当socket变得可读时（比如客户端对redis执行`write`/`close`操作），或者有新的可以应答的sccket出现时（客户端对redis执行`connect`操作），socket就会产生一个`AE_READABLE`事件
+
+当socket变得可写的时候（客户端对redis执行read操作），socket会产生一个AE_WRITABLE事件。
+
+IO多路复用程序可以同时监听AE_REABLE和AE_WRITABLE两种事件，要是一个socket同时产生了AE_READABLE和AE_WRITABLE两种事件，那么文件事件分派器优先处理AE_REABLE事件，然后才是AE_WRITABLE事件。
+
+### 4.2.3 文件事件处理器
+如果是客户端要连接redis，那么会为socket关联连接应答处理器
+如果是客户端要写数据到redis，那么会为socket关联命令请求处理器
+如果是客户端要从redis读数据，那么会为socket关联命令回复处理器
+
+### 4.2.4 客户端与redis通信的一次流程
+在redis启动初始化的时候，redis会将连接应答处理器跟AE_READABLE事件关联起来，接着如果一个客户端跟redis发起连接，此时会产生一个AE_READABLE事件，然后由连接应答处理器来处理跟客户端建立连接，创建客户端对应的socket，同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来。
+
+当客户端向redis发起请求的时候（不管是读请求还是写请求，都一样），首先就会在socket产生一个AE_READABLE事件，然后由对应的命令请求处理器来处理。这个命令请求处理器就会从socket中读取请求相关数据，然后进行执行和处理。
+
+接着redis这边准备好了给客户端的响应数据之后，就会将socket的AE_WRITABLE事件跟命令回复处理器关联起来，当客户端这边准备好读取响应数据时，就会在socket上产生一个AE_WRITABLE事件，会由对应的命令回复处理器来处理，就是将准备好的响应数据写入socket，供客户端来读取。
+
+命令回复处理器写完之后，就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系。
+
+## 4.3 redis的单线程模型为何效率高
+- 纯内存操作
+- 核心是基于非阻塞的IO多路复用机制
+- 单线程反而避免了多线程的频繁上下文切换问题
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(21) - redis\346\234\211\345\223\252\344\272\233\346\225\260\346\215\256\347\261\273\345\236\213,\350\260\210\350\260\210\351\200\202\347\224\250\345\234\272\346\231\257.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(21) - redis\346\234\211\345\223\252\344\272\233\346\225\260\346\215\256\347\261\273\345\236\213,\350\260\210\350\260\210\351\200\202\347\224\250\345\234\272\346\231\257.md"
new file mode 100644
index 0000000000..3d7d2da964
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(21) - redis\346\234\211\345\223\252\344\272\233\346\225\260\346\215\256\347\261\273\345\236\213,\350\260\210\350\260\210\351\200\202\347\224\250\345\234\272\346\231\257.md"	
@@ -0,0 +1,108 @@
+# 1 面试题
+
+redis都有哪些数据类型？分别在哪些场景下使用比较合适？
+
+# 2 考点分析
+除非是感觉看你简历，就是工作3年以内的比较初级的一个同学，可能对技术没有很深入的研究过，我才会问这类问题，在宝贵的面试时间里，我实在是不想多问
+
+其实问这个问题,主要就俩原因
+- 看看你到底有没有全面的了解redis有哪些功能，一般怎么来用，啥场景用什么，就怕你别就会最简单的kv操作
+- 看看你在实际项目里都怎么玩儿过redis
+
+要是你回答的不好，没说出几种数据类型，也没说什么场景，你完了，面试官对你印象肯定不好，觉得你平时就是做个简单的set和get。
+
+# 3 详解
+## 3.1 string
+
+这是最基本的类型了，没啥可说的，就是普通的set和get，做简单的kv缓存
+
+## 3.2 hash
+
+这个是类似map的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在redis里，然后每次读写缓存的时候，可以就操作hash里的某个字段。
+```
+key=150
+
+value={
+  “id”: 150,
+  “name”: “zhangsan”,
+  “age”: 20
+}
+```
+hash类的数据结构，主要是用来存放一些对象，把一些简单的对象给缓存起来，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值
+```
+value={
+  “id”: 150,
+  “name”: “zhangsan”,
+  “age”: 21
+}
+```
+
+## 3.3 list
+有序列表，这个是可以玩儿出很多花样的
+
+微博，某个大v的粉丝，就可以以list的格式放在redis里去缓存
+```
+key=某大v
+
+value=[zhangsan, lisi, wangwu]
+```
+比如可以通过list存储一些列表型的数据结构，类似粉丝列表了、文章的评论列表之类的东西
+
+比如可以通过lrange命令，就是从某个元素开始读取多少个元素，可以基于list实现分页查询，这个很棒的一个功能，基于redis实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西，性能高，就一页一页走
+
+比如可以搞个简单的消息队列，从list头怼进去，从list尾巴那里弄出来
+
+## 3.4 set
+无序集合，自动去重
+
+直接基于set将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于jvm内存里的HashSet进行去重，但是如果你的某个系统部署在多台机器上呢？
+
+得基于redis进行全局的set去重
+
+可以基于set玩儿交集、并集、差集的操作，比如交集吧，可以把两个人的粉丝列表整一个交集，看看俩人的共同好友是谁？对吧
+
+把两个大v的粉丝都放在两个set中，对两个set做交集
+
+## 3.5 sorted set
+排序的set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序，这个可以玩儿很多的花样，最大的特点是有个分数可以自定义排序规则
+
+比如说你要是想根据时间对数据排序，那么可以写入进去的时候用某个时间作为分数，人家自动给你按照时间排序了
+
+排行榜：将每个用户以及其对应的什么分数写入进去，zadd board score username，接着zrevrange board 0 99，就可以获取排名前100的用户；zrank board username，可以看到用户在排行榜里的排名
+```
+zadd board 85 zhangsan
+zadd board 72 wangwu
+zadd board 96 lisi
+zadd board 62 zhaoliu
+
+96 lisi
+85 zhangsan
+72 wangwu
+62 zhaoliu
+
+zrevrange board 0 3
+```
+获取排名前3的用户
+```
+96 lisi
+85 zhangsan
+72 wangwu
+
+zrank board zhaoliu
+
+4
+
+```
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(22) - Redis\347\232\204\350\277\207\346\234\237\347\255\226\347\225\245\357\274\237\346\211\213\345\206\231\344\270\200\344\270\252LRU\357\274\237.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(22) - Redis\347\232\204\350\277\207\346\234\237\347\255\226\347\225\245\357\274\237\346\211\213\345\206\231\344\270\200\344\270\252LRU\357\274\237.md"
new file mode 100644
index 0000000000..e0016b85d5
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(22) - Redis\347\232\204\350\277\207\346\234\237\347\255\226\347\225\245\357\274\237\346\211\213\345\206\231\344\270\200\344\270\252LRU\357\274\237.md"	
@@ -0,0 +1,110 @@
+
+# 1 面试题
+Redis的过期策略都有哪些？内存淘汰机制都有哪些？手写一下LRU代码实现？
+
+# 2 考点分析
+## 1）我往redis里写的数据怎么没了？
+
+我们生产环境的redis怎么经常会丢掉一些数据？写进去了，过一会儿可能就没了。
+我的天，同学，你问这个问题就说明redis你就没用对啊。redis是缓存，你给当存储了是吧？
+
+啥叫缓存？用内存当缓存。内存是无限的吗，内存是很宝贵而且是有限的，磁盘是廉价而且是大量的。可能一台机器就几十个G的内存，但是可以有几个T的硬盘空间。redis主要是基于内存来进行高性能、高并发的读写操作的。
+
+那既然内存是有限的，比如redis就只能用10个G，你要是往里面写了20个G的数据，会咋办？当然会干掉10个G的数据，然后就保留10个G的数据了。那干掉哪些数据？保留哪些数据？当然是干掉不常用的数据，保留常用的数据了。
+
+所以说，这是缓存的一个最基本的概念，数据是会过期的，要么是你自己设置个过期时间，要么是redis自己给干掉。
+
+```
+set key value 过期时间（1小时）
+```
+set进去的key，1小时之后就没了，就失效了
+
+## 2）我的数据明明都过期了，怎么还占用着内存啊？
+还有一种就是如果你设置好了一个过期时间，你知道redis是怎么给你弄成过期的吗？什么时候删除掉？如果你不知道，之前有个人就问了，为啥好多数据明明应该过期了，结果发现redis内存占用还是很高？那是因为你不知道redis是怎么删除那些过期key的。
+
+redis 内存一共是10g，你现在往里面写了5g的数据，结果这些数据明明你都设置了过期时间，要求这些数据1小时之后都会过期，结果1小时之后，你回来一看，redis机器，怎么内存占用还是50%呢？5g数据过期了，我从redis里查，是查不到了，结果过期的数据还占用着redis的内存。
+
+如果你连这个问题都不知道，上来就懵了，回答不出来，那线上你写代码的时候，想当然的认为写进redis的数据就一定会存在，后面导致系统各种漏洞和bug，谁来负责？
+
+# 3 详解
+##  3.1 设置过期时间
+
+我们set key的时候，都可以给一个`expire time`，就是过期时间，指定这个key比如说只能存活1个小时？10分钟？这个很有用，我们自己可以指定缓存到期就失效。
+
+如果假设你设置一个一批key只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？
+
+> 答案是：定期删除+惰性删除
+
+所谓定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。
+
+但是问题是，定期删除可能会导致很多过期key到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。这就是说，在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。
+
+并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下
+
+通过上述两种手段结合起来，保证过期的key一定会被干掉。
+
+很简单，就是说，你的过期key，靠定期删除没有被删除掉，还停留在内存里，占用着你的内存呢，除非你的系统去查一下那个key，才会被redis给删除掉。
+
+但是实际上这还是有问题的，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了，咋整？
+
+答案是：走内存淘汰机制。
+
+## 3.2 内存淘汰
+
+如果redis的内存占用过多的时候，此时会进行内存淘汰，有如下一些策略：
+
+redis 10个key，现在已经满了，redis需要删除掉5个key
+
+1个key，最近1分钟被查询了100次
+1个key，最近10分钟被查询了50次
+1个key，最近1个小时倍查询了1次
+
+1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了
+2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
+3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊
+4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）
+5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
+6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除
+
+百度，问题啊，网上鱼龙混杂
+
+如果百度一些api操作，入门的知识，ok的，随便找一个博客都可以
+
+一些高级别的，redis单线程模型
+
+很简单，你写的数据太多，内存满了，或者触发了什么条件，redis lru，自动给你清理掉了一些最近很少使用的数据
+
+## 3.3 要不你手写一个LRU算法？
+确实有时会问这个，因为有些候选人如果确实过五关斩六将，前面的问题都答的很好，那么其实让他写一下LRU算法，可以考察一下编码功底
+
+你可以现场手写最原始的LRU算法，那个代码量太大了，不太现实
+```
+public class LRUCache<K, V> extends LinkedHashMap<K, V> {
+    
+private final int CACHE_SIZE;
+
+    // 这里就是传递进来最多能缓存多少数据
+    public LRUCache(int cacheSize) {
+        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true); // 这块就是设置一个hashmap的初始大小，同时最后一个true指的是让linkedhashmap按照访问顺序来进行排序，最近访问的放在头，最老访问的就在尾
+        CACHE_SIZE = cacheSize;
+    }
+
+    @Override
+    protected boolean removeEldestEntry(Map.Entry eldest) {
+        return size() > CACHE_SIZE; // 这个意思就是说当map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据
+    }
+
+}
+```
+我给你看上面的代码，是告诉你最起码你也得写出来上面那种代码，不求自己纯手工从底层开始打造出自己的LRU，但是起码知道如何利用已有的jdk数据结构实现一个java版的LRU
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23)-\345\246\202\344\275\225\344\277\235\350\257\201redis\351\253\230\345\271\266\345\217\221\345\217\212\351\253\230\345\217\257\347\224\250.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23)-\345\246\202\344\275\225\344\277\235\350\257\201redis\351\253\230\345\271\266\345\217\221\345\217\212\351\253\230\345\217\257\347\224\250.md"
new file mode 100644
index 0000000000..3ca721e225
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23)-\345\246\202\344\275\225\344\277\235\350\257\201redis\351\253\230\345\271\266\345\217\221\345\217\212\351\253\230\345\217\257\347\224\250.md"
@@ -0,0 +1,35 @@
+# 1 面试题
+
+如何保证Redis的高并发和高可用？redis的主从复制原理能介绍一下么？redis的哨兵原理能介绍一下么？
+
+# 2 考点分析
+其实问这个问题，主要是考考你，redis单机能承载多高并发？
+如果单机扛不住如何扩容抗更多的并发？
+redis会不会挂？
+既然redis会挂那怎么保证redis是高可用的？
+
+其实针对的都是项目中你肯定要考虑的一些问题，如果你没考虑过，那确实你对生产系统中的问题思考太少。
+
+# 3 详解
+就是如果你用[Redis缓存](https://zhuanlan.zhihu.com/p/64860651)技术的话，肯定要考虑如何用redis来加多台机器，保证redis是高并发的，还有就是如何让Redis保证自己不是挂掉以后就直接死掉了
+
+## 3.1 redis高并发
+主从架构，一主多从，一般来说，很多项目其实就足够了，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒10万的QPS。
+
+redis高并发的同时，还需要
+## 3.2 容纳大量的数据
+一主多从，每个实例都容纳了完整的数据，比如redis主就10G的内存量，其实你就最对只能容纳10g的数据量。
+如果你的缓存要容纳的数据量很大，达到了几十g，甚至几百g，或者是几t，那你就需要[Redis集群](https://zhuanlan.zhihu.com/p/64860002)，而且用redis集群之后，可以提供可能每秒几十万的读写并发。
+
+## 3.3 redis高可用
+如果你做主从架构部署，其实就是加上[哨兵](https://zhuanlan.zhihu.com/p/64859326)就可以了，就可以实现，任何一个实例宕机，自动会进行主备切换。
+
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-4)-\345\206\215\346\267\261\345\205\245Redis Replication\347\232\204\345\256\214\346\225\264\346\211\247\350\241\214\346\265\201\347\250\213\345\217\212\345\216\237\347\220\206.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-4)-\345\206\215\346\267\261\345\205\245Redis Replication\347\232\204\345\256\214\346\225\264\346\211\247\350\241\214\346\265\201\347\250\213\345\217\212\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..e69f951516
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-4)-\345\206\215\346\267\261\345\205\245Redis Replication\347\232\204\345\256\214\346\225\264\346\211\247\350\241\214\346\265\201\347\250\213\345\217\212\345\216\237\347\220\206.md"	
@@ -0,0 +1,92 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+# 1 复制的完整流程
+
+1. slave node启动，仅仅保存master node的信息，包括master node的`host`和`ip`，但复制流程尚未开始master host和ip配置在 `redis.conf` 中的 slaveof
+2. slave node内部有个定时任务，每s 检查是否有新的master node要连接和复制，若发现，就跟master node建立socket网络连接
+3. slave node发送ping命令给master node
+4. 口令认证 - 若master设置了requirepass，那么salve node必须同时发送masterauth的口令认证
+5. master node**第一次执行全量复制**，将所有数据发给slave node
+6. master node后续持续将写命令，异步复制给slave node
+- 完整复制的基本流程图
+
+![](https://ask.qcloudimg.com/http-save/1752328/wlaq0nlan3.png)
+
+# 2 数据同步相关的核心机制
+即第一次slave连接msater时，执行的全量复制过程中你必须知道的一些细节
+
+## 2.1 master和slave都会维护一个offset
+
+master会在自身基础上累加offset，slave亦是
+
+slave每秒都会上报自己的offset给master，同时master保存每个slave的offset
+
+倒不是说特定就用在全量复制场景，主要是master和slave都要知道各自的数据的offset，才能知晓互相之间的数据不一致的情况
+
+## 2.2 backlog
+
+master node有一个backlog，默认是1MB
+
+master node给slave node复制数据时，也会将数据在backlog中同步写一份
+
+backlog主要是用来做全量复制中断时候的增量复制
+
+## 2.3 master run id
+
+info server，可以看到master run id
+
+如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制
+
+如果需要不更改run id重启redis，可以使用
+
+```
+redis-cli debug reload
+```
+
+## 2.4 psync
+
+从节点使用`psync`从master node复制，psync runid offset
+
+master node会根据自身的情况返回响应信息
+
+- 可能是FULLRESYNC runid offset触发全量复制
+- 可能是CONTINUE触发增量复制
+
+# 3 全量复制
+
+1. master执行`bgsave`，在本地生成一份RDB快照client-output-buffer-limit slave 256MB 64MB 60
+2. master node将RDB快照发送给salve node，若RDB复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可适当调大该参数(对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s)
+3. master node在生成RDB时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
+4. 若在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
+5. slave node接收到RDB之后，清空自己的旧数据，然后重新加载RDB到自己的内存中，同时**基于旧的数据版本**对外提供服务
+6. 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
+
+RDB生成、RDB通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间
+
+如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟
+
+# 5 增量复制
+
+1. 如果全量复制过程中，master-slave网络连接中断，那么salve重连master时，会触发增量复制
+2. master直接从自己的backlog中获取部分丢失的数据，发送给slave node
+3. msater就是根据slave发送的psync中的offset来从backlog中获取数据的
+
+# 5 heartbeat
+
+主从节点互相都会发送heartbeat信息
+
+master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
+
+# 6 异步复制
+
+master每次接收到写命令之后，先在内部写入数据，然后异步发送给slave node
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-6)-\344\270\273\344\273\216\346\236\266\346\236\204\344\270\213\347\232\204Redis\345\246\202\344\275\225\345\201\232\345\210\260\351\253\230\345\217\257\347\224\250\346\200\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-6)-\344\270\273\344\273\216\346\236\266\346\236\204\344\270\213\347\232\204Redis\345\246\202\344\275\225\345\201\232\345\210\260\351\253\230\345\217\257\347\224\250\346\200\247.md"
new file mode 100644
index 0000000000..44bfaa1678
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-6)-\344\270\273\344\273\216\346\236\266\346\236\204\344\270\213\347\232\204Redis\345\246\202\344\275\225\345\201\232\345\210\260\351\253\230\345\217\257\347\224\250\346\200\247.md"
@@ -0,0 +1,25 @@
+​
+# 1 什么是99.99%高可用？
+![](https://uploadfiles.nowcoder.com/files/20190705/5088755_1562298513680_2019070511441966.png)
+架构上，高可用性，99.99%的高可用性
+
+讲的学术，99.99%，公式，系统可用的时间 / 系统故障的时间，365天，在365天 * 99.99%的时间内，你的系统都是可以哗哗对外提供服务的，那就是高可用性
+
+系统可用的时间 / 总的时间 = 高可用性，然后会对各种时间的概念，说一大堆解释
+
+# 2 redis不可用是什么？单实例不可用？主从架构不可用？不可用的后果是什么？
+![](https://uploadfiles.nowcoder.com/files/20190705/5088755_1562298513592_20190705114519608.png)
+- redis的不可用
+![](https://uploadfiles.nowcoder.com/files/20190705/5088755_1562298513649_20190705114547103.png)
+
+# 3 redis怎么才能做到高可用？
+![](https://uploadfiles.nowcoder.com/files/20190705/5088755_1562298513660_20190705114614428.png)
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-7) - Redis\347\232\204\345\223\250\345\205\265\346\236\266\346\236\204.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-7) - Redis\347\232\204\345\223\250\345\205\265\346\236\266\346\236\204.md"
new file mode 100644
index 0000000000..2ad98f6440
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-7) - Redis\347\232\204\345\223\250\345\205\265\346\236\266\346\236\204.md"	
@@ -0,0 +1,82 @@
+
+# 1 Redis Sentinal机制
+sentinal，中文名哨兵
+
+哨兵是redis集群架构中非常重要的一个组件，主要功能如下
+- 集群监控
+监控Redis master和slave进程的正常工作
+- 消息通知
+如果某个Redis实例有故障，那么哨兵负责发送报警消息给管理员
+- 故障转移
+若master node宕机，会自动转移到slave node上
+- 配置中心
+若发生故障转移，通知client客户端新的master地址
+
+哨兵本身也是分布式的，作为一个哨兵集群去运行，协同工作
+- 故障转移时，判断一个master node是否宕机，需要大部分的哨兵都同意，涉及到了分布式选举问题
+- 即使部分哨兵节点宕机，哨兵集群还是能正常工作的
+
+
+> 目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单
+
+# 2 哨兵的核心知识
+1. 哨兵需要至少3个实例，保证自己的健壮性
+2. 哨兵 + Redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
+3. 对于哨兵 + Redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练
+
+# 3 为什么仅2个节点时无法正常工作
+必须部署2个以上的节点
+
+若仅部署2个实例，quorum=1
+
+```
++----+         +----+
+| M1 |---------| R1 |
+| S1 |         | S2 |
++----+         +----+
+```
+
+Configuration: `quorum = 1`
+
+
+master宕机，s1和s2中只要有1个哨兵认为master宕机就可以进行切换，同时会在s1和s2中选举出一个执行故障转移.
+但此时，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2
+
+> 2个哨兵的majority=2
+> 3个哨兵的majority=2
+> 4个哨兵的majority=2
+> 5个哨兵的majority=3
+
+2个哨兵都运行着，就可以允许执行故障转移
+
+若整个M1和S1运行的机器宕机了，那么哨兵仅剩1个，此时就无majority来允许执行故障转移，虽然另外一台机器还有一个R1，但故障转移不会执行
+
+# 4 3-节点哨兵集群(经典)
+```
+       +----+
+       | M1 |
+       | S1 |
+       +----+
+          |
++----+    |    +----+
+| R2 |----+----| R3 |
+| S2 |         | S3 |
++----+         +----+
+```
+Configuration: quorum = 2，majority
+
+若M1节点宕机了，还剩下2个哨兵，S2和S3可以一致认为master宕机了，然后选举出一个来执行故障转移
+
+同时3个哨兵的`majority`是2，所以余存的2个哨兵运行着，就可执行故障转移
+
+
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-8) - Redis\345\223\250\345\205\265\344\270\273\345\244\207\345\210\207\346\215\242\347\232\204\346\225\260\346\215\256\344\270\242\345\244\261\351\227\256\351\242\230.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-8) - Redis\345\223\250\345\205\265\344\270\273\345\244\207\345\210\207\346\215\242\347\232\204\346\225\260\346\215\256\344\270\242\345\244\261\351\227\256\351\242\230.md"
new file mode 100644
index 0000000000..1b1efa6d2a
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-8) - Redis\345\223\250\345\205\265\344\270\273\345\244\207\345\210\207\346\215\242\347\232\204\346\225\260\346\215\256\344\270\242\345\244\261\351\227\256\351\242\230.md"	
@@ -0,0 +1,70 @@
+# 1 数据丢失的两个场景
+
+主备切换的过程，可能会导致数据丢失
+
+## 1.1 异步复制
+
+由于 `master => slave`的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机，于是这些数据就丢失了
+
+![](https://ask.qcloudimg.com/http-save/1752328/93jl4vswgy.png)
+
+## 1.2 脑裂导致
+
+脑裂，也就是说，某个master所在节点突然脱离正常的网络，无法和其他slave机器连接，但实际上master还运行着
+
+此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master
+
+这个时候，集群里就会有两个master，也就是所谓的`脑裂`
+
+此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了
+
+因此旧master再次恢复时，会被作为一个slave挂到新的master上去，自己的数据会被清空，重新从新的master复制数据
+
+![](https://ask.qcloudimg.com/http-save/1752328/q5320luqi1.png)
+
+# 2 数据丢失的解决方案
+
+如下配置可以减少异步复制和脑裂导致的数据丢失
+
+```
+min-slaves-to-write 1
+min-slaves-max-lag 10
+```
+
+配置要求至少有1个slave，数据复制和同步的延迟不能超过10秒
+
+一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，master就不再接收任何请求!
+
+## 2.1 异步复制数据丢失解决方案
+
+`min-slaves-max-lag` 配置
+
+即可确保，一旦slave复制数据和ack延时过长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求
+
+这样就可把master宕机时由于部分数据未同步到slave导致的数据丢失降低在可控范围
+
+![](https://ask.qcloudimg.com/http-save/1752328/znnqfrs21u.png)
+
+## 2.2 脑裂数据丢失解决方案
+
+若一个master出现了脑裂，跟其他slave失去连接，那么开始的两个配置可以确保
+
+若不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求
+
+这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失
+
+上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求
+
+因此在脑裂场景下，最多就丢失10秒的数据
+
+![](https://ask.qcloudimg.com/http-save/1752328/aamxilr8we.png)
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-9) - \346\267\261\345\205\245\350\247\243\346\236\220Redis\345\223\250\345\205\265\345\272\225\345\261\202\345\216\237\347\220\206.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-9) - \346\267\261\345\205\245\350\247\243\346\236\220Redis\345\223\250\345\205\265\345\272\225\345\261\202\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..38f05c73cb
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(23-9) - \346\267\261\345\205\245\350\247\243\346\236\220Redis\345\223\250\345\205\265\345\272\225\345\261\202\345\216\237\347\220\206.md"	
@@ -0,0 +1,84 @@
+# 1 sdown和odown转换机制
+> 两种失败状态
+
+## 1.1 概念
+- sdown主观宕机
+一个哨兵自己觉得一个master宕机
+- odown客观宕机
+quorum数量的哨兵都觉得一个master宕机
+
+## 1.2 达成条件
+- sdown
+一个哨兵ping一个master，超过`is-master-down-after-milliseconds`
+- odown
+一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown
+
+# 2 自动发现机制
+通过Redis的pub/sub实现哨兵互相之间的发现，每个哨兵都会往`__sentinel__:hello`这个channel发一个消息，此时所有其他哨兵都可消费到该消息，于是感知到其他哨兵的存在.
+
+每隔2s，哨兵都会往自己监控的某个master+slaves对应的`__sentinel__:hello `channel里发一个消息，内容为自己的host、ip和runid还有对该master的监控配置
+
+每个哨兵也会去监听自己监控的每个master+slaves对应的`__sentinel__:hello` channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
+
+每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
+
+# 3 slave配置的自动纠正
+哨兵会负责自动纠正slave的一些配置,比如
+- slave要成为潜在的master候选人，哨兵会确保slave复制现有master的数据
+- slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接至正确的master
+
+# 4 slave => master选举算法
+若一个master被认为odown了，而且majority数量的哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave,会考虑slave的一些信息
+- 跟master断开连接的时长
+- slave优先级
+- 复制offset
+- run id
+
+若一个slave跟master断开连接的时间已经超过`down-after-milliseconds`的10倍，外加master的宕机时长，那么slave就会被认为不适合选举为master
+```
+(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
+```
+
+接下来会对slave进行排序
+1. 按照slave优先级进行排序，slave priority越低，优先级就越高
+2. 如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
+3. 如果上面两个条件都相同，那么选择一个run id比较小的那个slave
+
+# 5 quorum和majority
+每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换
+该哨兵还得得到majority个哨兵的授权，才能正式执行切换
+
+- 若quorum < majority
+比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换
+
+- 若quorum >= majority
+那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换
+
+# 6 configuration epoch
+哨兵会监控一套Redis master+slave，并有相应的监控配置
+
+执行切换的哨兵，会从要切换到的新master（salve => master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的
+
+如果第一个选举出的哨兵切换失败，那么其他哨兵，会等待`failover-timeout`时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号
+
+# 7 configuraiton传播
+哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他哨兵
+> 这里是通过pub/sub机制传递的
+
+到了这里,之前提到的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的
+
+其他的哨兵也都是根据版本号的大小来更新自己的master配置的
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
+
+
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(24)-Redis\347\232\204\346\214\201\344\271\205\345\214\226\346\234\272\345\210\266.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(24)-Redis\347\232\204\346\214\201\344\271\205\345\214\226\346\234\272\345\210\266.md"
new file mode 100644
index 0000000000..2cf5ab1d37
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(24)-Redis\347\232\204\346\214\201\344\271\205\345\214\226\346\234\272\345\210\266.md"
@@ -0,0 +1,132 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+# 面试题
+
+Redis的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？
+
+# 考点分析
+
+Redis如果仅仅只是将数据缓存在内存里面，假若宕机了，再重启，内存里的数据就全部丢失了！
+
+你必须得用Redis的持久化机制，将数据写入内存的同时，异步的慢慢的将数据写入磁盘
+
+若Redis宕机了，重启启动，自动从磁盘上加载之前持久化的一些数据即可，也许会丢失少许数据，但至少不会将所有数据都弄丢 
+
+针对的都是Redis的生产环境可能遇到的一些问题，就是Redis要是挂了再重启，内存里的数据不就全丢了？能不能重启的时候把数据给恢复了？
+
+# 1 Redis持久化的意义
+
+很多同学，自己也看过一些redis的资料和书籍，当然可能也看过一些redis视频课程
+
+所有的资料，其实都会讲解redis持久化，但是有个问题，我到目前为止，没有看到有人很仔细的去讲解，redis的持久化意义
+
+redis的持久化，RDB，AOF，区别，各自的特点是什么，适合什么场景
+
+redis的企业级的持久化方案是什么，是用来跟哪些企业级的场景结合起来使用的？？？
+
+redis持久化的意义，在于故障恢复
+
+比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据
+
+如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据
+
+如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的
+
+![](https://ask.qcloudimg.com/http-save/1752328/yftp8qgfm9.png)
+
+我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的
+
+企业级redis集群架构：海量数据、高并发、高可用
+
+持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节
+
+比如你的Redis宕机，你要做的事情是让Redis变得可用，尽快变得可用!
+
+重启Redis，尽快让它对外提供服务，但就如上一讲所述，若你没做数据备份处理，即使Redis启动了，数据都没了!可用什么呢?
+
+很可能说，大量的请求过来，缓存全部无法命中，在Redis里根本找不到数据，这个时候就造成缓存雪崩，就会去MySQL数据库去找，突然MySQL承接高并发，宕机!
+
+MySQL宕机，你都没法去找数据恢复到Redis里面去，Redis的数据从哪儿来？就是从MySQL来的!
+
+> 具体的完整的缓存雪崩的场景，还有企业级的解决方案，到后面讲
+
+若你把Redis的持久化做好，备份和恢复方案也做到，那么即使你的Redis故障，也可通过备份数据，快速恢复，一旦恢复立即对外提供服务
+
+# 2 Redis的持久化机制
+
+- RDB和AOF的介绍
+![](https://ask.qcloudimg.com/http-save/1752328/yxna6xisjp.png)
+- RDB持久化机制
+对Redis中的数据执行周期性的持久化
+- AOF机制
+将每条写命令作为日志，以`append-only`模式写入一个日志文件，在Redis重启时，通过回放日志中的写入指令来重构整个数据
+
+> 如果我们希望Redis仅作为纯内存的缓存来用，亦可禁止RDB和AOF等所有的持久化机制
+
+通过RDB或AOF，都可以将Redis内存中的数据给持久化，然后可以再将这些数据备份到别的需要之地
+
+若Redis宕机，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重启Redis，Redis会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务
+
+如果同时使用RDB和AOF两种持久化机制，那么在Redis重启时，会使用AOF来重新构建数据，因为AOF中的数据更加完整!
+
+## 2.1 深入RDB
+
+### 2.1.1 RDB的优点
+
+- RDB会生成多个数据文件，每个数据文件都代表了某一个时刻Redis中的数据，这种多数据文件方式，**非常适合做冷备**，可以将这种完整的数据文件发送到某远程的安全存储，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份Redis中的数据
+- RDB对Redis对外提供的读写服务，影响非常小，可以让rRedis保持高性能，因为Redis主进程只要fork一个子进程，让子进程执行RDB
+- 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复Redis进程，更加快速
+
+### 2.1.2 RDB的缺点
+
+- 若想要在Redis故障时，尽可能少的丢失数据，那么RDB没有AOF好
+一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，若过程中Redis宕机，那么就会丢失最近未持久化的数据
+- RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒
+- RDB丢失数据的问题![](https://ask.qcloudimg.com/http-save/1752328/jfb6d56yn7.png)
+
+## 2.2 深入AOF
+
+![](https://ask.qcloudimg.com/http-save/1752328/t59ew3muns.png)
+
+- AOF rewrite原理剖析
+![](https://ask.qcloudimg.com/http-save/1752328/nn2nks9rdo.png)
+
+### 2.2.1 AOF的优点
+
+- 更好的避免数据丢失
+一般AOF会每隔1s，通过一个子进程执行一次fsync操作，最多丢失1s的数据
+- append-only模式写入
+所以没有任何磁盘寻址的开销，写入性能高，且文件不易破损，即使文件尾部破损，也易修复
+- 日志文件即使过大，出现后台重写操作，也不会影响客户端的读写
+因为在rewrite log时，会压缩其中的指令，创建出一份需要恢复数据的最小日志。在创建新日志时，旧日志文件还是照常写入。当新的merge后的日志文件准备好时，再交换新旧日志文件即可!
+- 命令通过非常可读的方式记录
+该特性非常适合做灾难性误删除操作的**紧急恢复**。
+比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，可立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可通过恢复机制，自动恢复所有数据
+
+### 2.2.2 AOF的缺点
+
+- 对于同一份数据，AOF日志一般比RDB快照更大
+- AOF开启后，写QPS会比RDB的低，因为AOF一般会配置成每s fsync一次日志文件，当然，每s一次fsync，性能也还是很高的
+- 以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来
+类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB的每次持久化一份完整的数据快照方式相比更加脆弱一些，易产生bug
+不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会更好
+
+# 3 抉择RDB & AOF
+
+1. 不要仅使用RDB，因为那样会导致你丢失很多数据
+2. 也不要仅使用AOF，因为那样有两个问题
+2.1 你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快
+2.2 RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
+3. 综合使用AOF和RDB
+3.1 用AOF保证数据不丢失，作为数据恢复的第一选择
+3.2 用RDB做不同程度的冷备，在AOF文件都丢失或损坏不可用时，还可使用RDB快速实现数据恢复
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(25) - Redis cluster\351\233\206\347\276\244\346\250\241\345\274\217\347\232\204\345\216\237\347\220\206.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(25) - Redis cluster\351\233\206\347\276\244\346\250\241\345\274\217\347\232\204\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..c827d973cf
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(25) - Redis cluster\351\233\206\347\276\244\346\250\241\345\274\217\347\232\204\345\216\237\347\220\206.md"	
@@ -0,0 +1,260 @@
+# 1 面试题
+
+Redis集群模式的工作原理说一下？在集群模式下，key是如何寻址的？寻址都有哪些算法？了解一致性hash吗？
+
+# 2 考点分析
+
+Redis不断在发展-Redis cluster集群模式，可以做到在多台机器上，部署多个实例，每个实例存储一部分的数据，同时每个实例可以带上Redis从实例，自动确保说，如果Redis主实例挂了，会自动切换到redis从实例顶上来。
+
+现在新版本，大家都是用Redis cluster的，也就是原生支持的集群模式，那么面试官肯定会就redis cluster对你来个几连炮。要是你没用过redis cluster，正常，以前很多人用codis之类的客户端来支持集群，但是起码你得研究一下redis cluster
+
+# 3 Redis如何在保持读写分离+高可用的架构下，还能横向扩容支撑1T+海量数据
+
+- redis单master架构的容量的瓶颈问题
+![](https://ask.qcloudimg.com/http-save/1752328/hosq404j9q.png)
+- redis如何通过master横向扩容支撑1T+数据量![](https://ask.qcloudimg.com/http-save/1752328/6yjg1upzbi.png)
+
+# 3 数据分布算法：hash+一致性hash+redis cluster的hash slot
+
+讲解分布式数据存储的核心算法，数据分布的算法
+
+hash算法 -> 一致性hash算法（memcached） -> redis cluster，hash slot算法
+
+用不同的算法，就决定了在多个master节点的时候，数据如何分布到这些节点上去，解决这个问题
+
+# 4 Redis cluster
+
+- 自动将数据分片，每个master上放一部分数据
+- 提供内置的高可用支持，部分master不可用时，还可继续工作
+
+在Redis cluster架构下，每个Redis要开放两个端口，比如一个是6379，另外一个就是加10000的端口号，比如16379
+
+16379端口用于节点间通信，也就是cluster bus集群总线
+
+cluster bus的通信，用来故障检测，配置更新，故障转移授权
+
+cluster bus用了另外一种二进制的协议 - gossip，主要用于节点间高效的数据交换，占用更少的网络带宽和处理时间
+
+- 最老土的hash算法和弊端（大量缓存重建） 
+![](https://ask.qcloudimg.com/http-save/1752328/1i0opt2jo7.png)
+
+3、一致性hash算法（自动缓存迁移）+虚拟节点（自动负载均衡）
+
+- 一致性hash算法的讲解和优点
+![](https://ask.qcloudimg.com/http-save/1752328/13nksjkgat.png)
+- 一致性hash算法的虚拟节点实现负载均衡
+![](https://ask.qcloudimg.com/http-save/1752328/gos1u9fp10.png)
+
+4、redis cluster的hash slot算法
+
+![](https://ask.qcloudimg.com/http-save/1752328/3df7rwuplp.png)
+
+redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot
+
+redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot
+
+hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去
+
+移动hash slot的成本是非常低的
+
+客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现
+
+# 5 节点间的内部通信机制
+
+## 5.1 基础通信原理
+
+用于维护集群的元数据
+
+### 5.1.1 集中式
+
+- 集中式的集群元数据存储和维护
+![](https://ask.qcloudimg.com/http-save/1752328/xejh8tb52v.png)
+**将集群元数据（节点信息，故障等）集中存储在某个节点**
+- 优点
+元数据的更新和读取，时效性好，一旦元数据出现变更，立即更新到集中式的存储中，其他节点读取时立即就可感知
+- 缺点
+所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力
+
+Redis cluster节点间采取的另一种称为gossip的协议
+
+互相之间不断通信，保持整个集群所有节点的数据是完整的
+
+gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后
+
+我们刚才做reshard，去做另外一个操作，会发现说，configuration error，达成一致
+
+（2）10000端口
+
+每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口
+
+每隔节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong
+
+（3）交换的信息
+
+故障信息，节点的增加和移除，hash slot信息，等等
+
+### 5.1.2 gossip协议
+
+- gossip协议维护集群元数据
+![](https://ask.qcloudimg.com/http-save/1752328/1dfycf9xrp.png)
+协议包含多种消息
+
+#### meet
+
+某节点发送meet给新加入的节点，让新节点加入集群，然后新节点就会开始与其他节点通信
+
+```
+redis-trib.rb add-node
+```
+
+其实内部就是发送了一个gossip meet消息给新节点，通知该节点加入集群
+
+#### ping
+
+每个节点都会频繁给其他节点发ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据
+
+ping很频繁，而且要携带一些元数据，可能会加重网络的负担
+
+每个节点每s会执行10次ping，每次会选择5个最久没有通信的其他节点。当然如果发现某个节点通信延时达到了
+
+```
+cluster_node_timeout / 2
+```
+
+那么立即发送ping，避免数据交换延时过长，落后的时间太长了。比如说，两节点之间已经10分钟没有交换数据，那么整个集群处于严重的元数据不一致的情况，就会有问题。所以`cluster_node_timeout`可以调节，如果调节比较大，那么会降低发送频率
+
+每次ping，一个是带上自己节点的信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换。至少包含3个其他节点的信息，最多包含总节点-2个其他节点的信息
+
+#### pong
+
+返回ping和meet，包含自己的状态和其他信息，也可用于信息广播和更新
+
+#### fail
+
+某个节点判断另一个节点fail后，就发送fail给其他节点，通知其他节点，指定的节点宕机啦！
+
+# 6 面向集群的Jedis内部实现原理
+
+开发Jedis，Redis的Java客户端
+
+jedis cluster api与redis cluster集群交互的一些基本原理
+
+## 6.1 基于重定向的客户端
+
+redis-cli -c，自动重定向
+
+### 6.1.1 请求重定向
+
+客户端可能会挑选任意一个Redis实例去发送命令，每个实例接收到命令，都会计算key对应的hash slot
+
+若在本地就在本地处理，否则返回moved给客户端，让客户端重定向
+
+```
+cluster keyslot mykey
+```
+
+可查看一个key对应的hash slot是什么
+
+用redis-cli的时候，可加入`-c`参数，支持自动的请求重定向，redis-cli接收到moved之后，会自动重定向到对应的节点执行命令
+
+### 6.1.2 计算hash slot
+
+计算hash slot的算法，就是根据key计算CRC16值，然后对16384取模，拿到对应的hash slot
+
+用hash tag可以手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，比如set mykey1:{100}和set mykey2:{100}
+
+### 6.1.3 hash slot查找
+
+节点间通过gossip协议数据交换，就知道每个hash slot在哪个节点上
+
+## 6.2 smart jedis
+
+### 6.2.1 什么是smart jedis
+
+基于重定向的客户端，很消耗网络IO，因为大部分情况下，可能都会出现一次请求重定向，才能找到正确的节点
+
+所以大部分的客户端，比如java redis客户端，就是jedis，都是smart的
+
+本地维护一份hashslot -> node的映射表，缓存，大部分情况下，直接走本地缓存就可以找到hashslot -> node，不需要通过节点进行moved重定向
+
+### 6.2.2 JedisCluster的工作原理
+
+在JedisCluster初始化的时候，就会随机选择一个node，初始化hashslot -> node映射表，同时为每个节点创建一个JedisPool连接池
+
+每次基于JedisCluster执行操作，首先JedisCluster都会在本地计算key的hashslot，然后在本地映射表找到对应的节点
+
+如果那个node正好还是持有那个hashslot，那么就ok; 如果说进行了reshard这样的操作，可能hashslot已经不在那个node上了，就会返回moved
+
+如果JedisCluter API发现对应的节点返回moved，那么利用该节点的元数据，更新本地的hashslot -> node映射表缓存
+
+重复上面几个步骤，直到找到对应的节点，如果重试超过5次，那么就报错，JedisClusterMaxRedirectionException
+
+jedis老版本，可能会出现在集群某个节点故障还没完成自动切换恢复时，频繁更新hash slot，频繁ping节点检查活跃，导致大量网络IO开销
+
+jedis最新版本，对于这些过度的hash slot更新和ping，都进行了优化，避免了类似问题
+
+### 6.2.3 hashslot迁移和ask重定向
+
+如果hash slot正在迁移，那么会返回ask重定向给jedis
+
+jedis接收到ask重定向之后，会重新定位到目标节点去执行，但是因为ask发生在hash slot迁移过程中，所以JedisCluster API收到ask是不会更新hashslot本地缓存
+
+已经可以确定说，hashslot已经迁移完了，moved是会更新本地hashslot->node映射表缓存的
+
+# 7 高可用性与主备切换原理
+
+原理，几乎跟哨兵类似
+
+## 7.1 判断节点宕机
+
+若一个节点认为另外一个节点宕机，即`pfail` - 主观宕机
+
+若多个节点都认为另外一个节点宕机，即`fail` - 客观宕机
+
+跟哨兵的原理几乎一样，sdown - odown
+
+在`cluster-node-timeout`内，某个节点一直没有返回`pong`，那么就被认为`pfail`
+
+若一个节点认为某个节点`pfail`，那么会在`gossip ping`消息中，`ping`给其他节点，若**超过半数**的节点都认为`pfail`，那么就会变成`fail`
+
+## 7.2 从节点过滤
+
+对宕机的master node，从其所有的slave node中，选择一个切换成master node
+
+检查每个slave node与master node断开连接的时间，如果超过了
+
+```
+cluster-node-timeout * cluster-slave-validity-factor
+```
+
+那么就没有资格切换成master，这个也跟哨兵是一样的，从节点超时过滤的步骤
+
+## 7.3 从节点选举
+
+> 哨兵：对所有从节点进行排序，slave priority，offset，run id
+
+每个从节点，都根据自己对master复制数据的offset，设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举
+
+所有的master node开始slave选举投票，给要选举的slave投票，如果大部分
+
+```
+master node（N/2 + 1）
+```
+
+都投票给了某从节点，那么选举通过，该从节点可以切换成master
+
+从节点执行主备切换，从节点切换为主节点
+
+## 7.4 与哨兵比较
+
+整个流程跟哨兵相比，非常类似，所以说，redis cluster功能强大，直接集成了replication和sentinal的功能
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(26)-\350\257\264\350\257\264\345\246\202\344\275\225\345\272\224\345\257\271\347\274\223\345\255\230\351\233\252\345\264\251\344\273\245\345\217\212\347\251\277\351\200\217\351\227\256\351\242\230.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(26)-\350\257\264\350\257\264\345\246\202\344\275\225\345\272\224\345\257\271\347\274\223\345\255\230\351\233\252\345\264\251\344\273\245\345\217\212\347\251\277\351\200\217\351\227\256\351\242\230.md"
new file mode 100644
index 0000000000..8ebcda43fa
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(26)-\350\257\264\350\257\264\345\246\202\344\275\225\345\272\224\345\257\271\347\274\223\345\255\230\351\233\252\345\264\251\344\273\245\345\217\212\347\251\277\351\200\217\351\227\256\351\242\230.md"
@@ -0,0 +1,38 @@
+# 1 面试题
+
+了解什么是Redis的雪崩和穿透吗？Redis崩溃之后会怎么样？系统该如何应对这种情况？如何处理Redis的穿透？
+
+# 2 考点分析
+
+缓存必问题，因为缓存雪崩和穿透，是缓存最大的两个问题，要么不出现，一旦出现就是致命的！
+
+# 3 缓存雪崩
+
+## 3.1 发生的现象
+
+![](https://ask.qcloudimg.com/http-save/1752328/b03hr8eln4.png)
+
+## 3.2 缓存雪崩的解决方案
+
+![](https://ask.qcloudimg.com/http-save/1752328/xwm3e0kbx1.png)
+
+- 事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃
+- 事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死
+- 事后：redis持久化，快速恢复缓存数据
+
+# 4 缓存穿透
+
+## 4.1 缓存穿透现象以及解决方案
+
+![](https://ask.qcloudimg.com/http-save/1752328/m9f7vqfaa3.png)
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(27) - \345\246\202\344\275\225\344\277\235\350\257\201\347\274\223\345\255\230\344\270\216\346\225\260\346\215\256\345\272\223\347\232\204\346\225\260\346\215\256\344\270\200\350\207\264\346\200\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(27) - \345\246\202\344\275\225\344\277\235\350\257\201\347\274\223\345\255\230\344\270\216\346\225\260\346\215\256\345\272\223\347\232\204\346\225\260\346\215\256\344\270\200\350\207\264\346\200\247.md"
new file mode 100644
index 0000000000..491a74b9b4
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(27) - \345\246\202\344\275\225\344\277\235\350\257\201\347\274\223\345\255\230\344\270\216\346\225\260\346\215\256\345\272\223\347\232\204\346\225\260\346\215\256\344\270\200\350\207\264\346\200\247.md"	
@@ -0,0 +1,224 @@
+# 1 面试题
+
+如何保证缓存与数据库的双写一致性？
+
+# 2 考点分析
+
+你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？
+
+# 3 详解
+
+一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案
+
+读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况
+
+串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。
+
+## 3.1 Cache Aside Pattern缓存+数据库读写模式的分析
+
+> 最经典的缓存+数据库读写的模式 cache aside pattern
+
+### 3.1.1 Cache Aside Pattern
+
+（1）读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应
+
+（2）更新的时候，先删除缓存，然后再更新数据库
+
+- cache aside pattern
+![](https://ask.qcloudimg.com/http-save/1752328/nlcbi9k7yy.png)3.1.2 为什么是删除缓存，而不是更新缓存呢？很多时候，复杂点的缓存的场景，因为缓存有的时候，不单是数据库中直接取出来的值
+
+商品详情页的系统，修改库存，只是修改了某个表的某些字段，但是要真正把这个影响的最终的库存计算出来，可能还需要从其他表查询一些数据，然后进行一些复杂的运算，才能最终计算出
+
+现在最新的库存是多少，然后才能将库存更新到缓存中去
+
+比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据，并运算，才能计算出缓存最新的值的
+
+> 更新缓存的代价是很高的
+
+是不是说，每次修改数据库的时候，都一定要将其对应的缓存去更新一份？
+
+也许有的场景是这样的，但是对于比较复杂的缓存数据计算的场景，就不是这样了
+
+如果你频繁修改一个缓存涉及的多个表，那么这个缓存会被频繁的更新，频繁的更新缓存
+
+但是问题在于，这个缓存到底会不会被频繁访问到？？？
+
+举个例子，一个缓存涉及的表的字段，在1分钟内就修改了20次，或者是100次，那么缓存更新20次，100次; 但是这个缓存在1分钟内就被读取了1次，有大量的冷数据
+
+> 28法则，黄金法则，20%的数据，占用了80%的访问量
+
+实际上，如果你只是删除缓存的话，那么1分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低
+
+每次数据过来，就只是删除缓存，然后修改数据库，如果这个缓存，在1分钟内只是被访问了1次，那么只有那1次，缓存是要被重新计算的，用缓存才去算缓存
+
+其实删除缓存，而不是更新缓存，就是一个惰性延迟计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算
+
+mybatis，hibernate，懒加载，思想
+
+查询一个部门，部门带了一个员工的list，没有必要说每次查询部门，都里面的1000个员工的数据也同时查出来啊
+
+80%的情况，查这个部门，就只是要访问这个部门的信息就可以了
+
+先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询1000个员工
+
+更多缓存设计模式请阅读
+
+[大行缓存更新之道.md](https://github.com/Wasabi1234/JavaEdge/blob/master/%25E6%2595%25B0%25E6%258D%25AE%25E5%25BA%2593/%25E5%25A4%25A7%25E8%25A1%258C%25E7%25BC%2593%25E5%25AD%2598%25E6%259B%25B4%25E6%2596%25B0%25E4%25B9%258B%25E9%2581%2593.md)
+
+## 3.2 高并发场景下的缓存+数据库双写不一致问题分析与解决方案设计
+
+开发业务系统
+
+从哪一步开始做，从比较简单的那块开始做，实时性要求比较高的那块数据的缓存去做
+
+> 实时性比较高的数据缓存，就是库存的服务
+
+库存可能会修改，每次修改都要去更新这个缓存数据; 每次库存的数据，在缓存中一旦过期，或者是被清理掉了，前端的nginx服务都会发送请求给库存服务，去获取相应的数据
+
+库存这一块，写数据库的时候，直接更新redis缓存
+
+实际上没有这么的简单，这里，其实就涉及到了一个问题
+
+### 数据库与缓存双写，数据不一致的问题
+
+围绕和结合实时性较高的库存服务，把数据库与缓存双写不一致问题以及其解决方案，给大家讲解一下
+
+数据库与缓存双写不一致，很常见的问题，大型的缓存架构中，第一个解决方案
+
+也可能说，有些方案只是适合某些场景，在某些场景下，可能需要你进行方案的优化和调整才能适用于你自己的项目
+
+### 3.2.1 最初级的缓存不一致问题以及解决方案
+
+Q：先修改数据库，再删除缓存，如果缓存删除失败，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致!
+
+- 最初级的数据库+缓存双写不一致问题
+![](https://ask.qcloudimg.com/http-save/1752328/pin0wcbj7t.png)
+
+A:先删除缓存，再修改数据库，如果删除缓存成功了，如果修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致
+
+因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中
+
+### 3.2.2 比较复杂的数据不一致问题分析
+
+数据发生了变更，先删除了缓存，然后要去修改数据库，`此时还没修改`
+
+一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中
+
+数据变更的程序完成了数据库的修改
+
+完了，数据库和缓存中的数据不一样了。。。。
+
+![](https://ask.qcloudimg.com/http-save/1752328/838xpfw8gg.png)
+
+### 3.2.3 为什么上亿流量高并发场景下，缓存会出现这个问题？
+
+只有在对一个数据在并发读写时，才可能会出现这种问题
+
+其实如果说你的并发量很低的话，特别是读很低，每天访问量就1万次，那么很少会出现刚才描述的那种不一致的场景
+
+但问题是，如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况
+
+高并发了以后，问题是很多的
+
+### 3.2.4 数据库 & 缓存更新与读取 异步串行化
+
+更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个JVM内部的队列中
+
+读数据的时候，如果发现数据不在缓存中，那么将重读数据+更新缓存，根据唯一标识路由之后，也发送同一个JVM内部的队列中
+
+`一个队列对应一个工作线程`
+
+每个工作线程串行拿到对应的操作，然后一条一条的执行
+
+这样的话，一个数据变更的操作，先执行删除缓存，然后再更新数据库，但是还没完成更新
+
+此时如果一个读请求过来，读到了空缓存，则可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成
+
+> 这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可
+
+待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中
+
+- 如果请求还在等待时间范围内，轮询发现可以取到值了，那么就直接返回
+- 如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值
+
+### 3.2.5 高并发的场景下，该解决方案要注意的问题
+
+#### （1）读请求长时阻塞
+
+由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回
+
+该解决方案，最大的风险点在于，可能数据更新很频繁，导致队列中积压了大量更新操作，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库
+
+务必通过一些模拟真实的测试，看看更新数据的频繁是怎样的
+
+另外一点，因为一个队列中，可能会积压针对多个数据项的更新操作，因此需要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据的更新操作
+
+如果一个内存队列里居然会挤压100个商品的库存修改操作，每隔库存修改操作要耗费10ms区完成，那么最后一个商品的读请求，可能等待10 \* 100 = 1000ms = 1s后，才能得到数据
+
+这个时候就导致读请求的长时阻塞
+
+一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会hang多少时间，如果读请求在200ms返回，如果你计算过后，哪怕是最繁忙的时候，积压10个更新操作，最多等待200ms，那还可以的
+
+如果一个内存队列可能积压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的数据，那么每个内存队列中积压的更新操作就会越少
+
+其实根据之前的项目经验，一般来说数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的
+
+针对读高并发，读缓存架构的项目，一般写请求相对读来说，是非常非常少的，每秒的QPS能到几百就不错了
+
+一秒，500的写操作，5份，每200ms，就100个写操作
+
+单机器，20个内存队列，每个内存队列，可能就积压5个写操作，每个写操作性能测试后，一般在20ms左右就完成
+
+那么针对每个内存队列中的数据的读请求，也就最多hang一会儿，200ms以内肯定能返回了
+
+写QPS扩大10倍，但是经过刚才的测算，就知道，单机支撑写QPS几百没问题，那么就扩容机器，扩容10倍的机器，10台机器，每个机器20个队列，200个队列
+
+大部分的情况下，应该是这样的，大量的读请求过来，都是直接走缓存取到数据的
+
+少量情况下，可能遇到读跟数据更新冲突的情况，如上所述，那么此时更新操作如果先入队列，之后可能会瞬间来了对这个数据大量的读请求，但是因为做了去重的优化，所以也就一个更新缓存的操作跟在它后面
+
+等数据更新完了，读请求触发的缓存更新操作也完成，然后临时等待的读请求全部可以读到缓存中的数据
+
+#### (2）读请求并发量过高
+
+这里还必须做好压力测试，确保恰巧碰上上述情况的时候，还有一个风险，就是突然间大量读请求会在几十毫秒的延时hang在服务上，看服务能不能抗的住，需要多少机器才能抗住最大的极限情况的峰值
+
+但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大
+
+按1:99的比例计算读和写的请求，每秒5万的读QPS，可能只有500次更新操作
+
+如果一秒有500的写QPS，那么要测算好，可能写操作影响的数据有500条，这500条数据在缓存中失效后，可能导致多少读请求，发送读请求到库存服务来，要求更新缓存
+
+一般来说，1:1，1:2，1:3，每秒钟有1000个读请求，会hang在库存服务上，每个读请求最多hang多少时间，200ms就会返回
+
+在同一时间最多hang住的可能也就是单机200个读请求，同时hang住
+
+单机hang200个读请求，还是ok的
+
+1:20，每秒更新500条数据，这500秒数据对应的读请求，会有20 \* 500 = 1万
+
+1万个读请求全部hang在库存服务上，就死定了
+
+#### （3）多服务实例部署的请求路由
+
+可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过nginx服务器路由到相同的服务实例上
+
+#### （4）热点商品的路由问题，导致请求的倾斜
+
+万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能造成某台机器的压力过大
+
+就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以更新频率不是太高的话，这个问题的影响并不是特别大
+
+但是的确可能某些机器的负载会高一些
+
+> 更多内容请关注JavaEdge公众号
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(28) - \345\246\202\344\275\225\350\247\243\345\206\263Redis\347\232\204\345\271\266\345\217\221\347\253\236\344\272\211\351\227\256\351\242\230.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(28) - \345\246\202\344\275\225\350\247\243\345\206\263Redis\347\232\204\345\271\266\345\217\221\347\253\236\344\272\211\351\227\256\351\242\230.md"
new file mode 100644
index 0000000000..74d18ae35e
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(28) - \345\246\202\344\275\225\350\247\243\345\206\263Redis\347\232\204\345\271\266\345\217\221\347\253\236\344\272\211\351\227\256\351\242\230.md"	
@@ -0,0 +1,24 @@
+
+# 1 面试题
+redis的并发竞争问题是什么？如何解决这个问题？了解Redis事务的CAS方案吗？
+
+# 2 考点分析
+这个也是线上非常常见的一个问题，就是多客户端同时并发写一个key，可能本来应该先到的数据后到了，导致数据版本错了。或者是多客户端同时获取一个key，修改值之后再写回去，只要顺序错了，数据就错了。
+
+而且redis自己就有天然解决这个问题的CAS类的乐观锁方案
+
+#  3 详解
+- redis并发竞争问题以及解决方案
+![](https://img-blog.csdnimg.cn/20190509175418361.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(29) - \347\224\237\344\272\247\347\216\257\345\242\203\347\232\204redis\351\233\206\347\276\244\347\232\204\351\203\250\347\275\262\346\236\266\346\236\204\346\230\257\346\200\216\344\271\210\346\240\267\347\232\204.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(29) - \347\224\237\344\272\247\347\216\257\345\242\203\347\232\204redis\351\233\206\347\276\244\347\232\204\351\203\250\347\275\262\346\236\266\346\236\204\346\230\257\346\200\216\344\271\210\346\240\267\347\232\204.md"
new file mode 100644
index 0000000000..c0103acc49
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(29) - \347\224\237\344\272\247\347\216\257\345\242\203\347\232\204redis\351\233\206\347\276\244\347\232\204\351\203\250\347\275\262\346\236\266\346\236\204\346\230\257\346\200\216\344\271\210\346\240\267\347\232\204.md"	
@@ -0,0 +1,31 @@
+# 1 面试题
+生产环境中的redis是怎么部署的？
+
+# 2 考点分析
+看看你了解不了解你们公司的redis生产集群的部署架构，如果你不了解，那么确实你就很失职了，你的redis是主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？线上redis给几个G的内存？设置了哪些参数？压测后你们redis集群承载多少QPS？
+
+兄弟，这些你必须是门儿清的，否则你确实是没好好思考过
+
+# 3 面试详解
+## 3.1 redis cluster
+10台机器，5台机器部署了redis主节点，另外5台机器部署了redis的从节点
+每个主节点挂了一个从节点，5个节点对外提供读写服务，每个节点的读写高峰QPS可能可以达到每秒5万，5台机器最多是25万个QPS.
+
+## 3.2 机器配置
+32G内存+8核CPU+1T磁盘，但是分配给redis进程的是10g内存，一般线上生产环境，redis的内存尽量不要超过10g，超过10g可能会有问题。
+
+5台机器对外提供读写，一共有50g内存。
+
+因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis从实例会自动变成主实例继续提供读写服务
+
+## 3.3 你往内存里写的是什么数据？每条数据的大小是多少？
+商品数据，每条数据是10kb。100条数据是1mb，10万条数据是1g。常驻内存的是200万条商品数据，占用内存是20g，仅仅不到总内存的50%。
+
+目前高峰期每秒就是3500左右的请求量
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(30) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230\345\233\236\347\255\224\346\212\200\345\267\247\346\200\273\347\273\223.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(30) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230\345\233\236\347\255\224\346\212\200\345\267\247\346\200\273\347\273\223.md"
new file mode 100644
index 0000000000..523badd615
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(30) - \345\210\206\345\270\203\345\274\217\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230\345\233\236\347\255\224\346\212\200\345\267\247\346\200\273\347\273\223.md"	
@@ -0,0 +1,25 @@
+这套东西基本构成了缓存这块你必须知道的基础性的知识，如果你不知道，那么说明你有点懒惰了，平时没好好积累。
+
+因为这些问题确实不难，如果往深了问，可以问的很细，结合项目扣的很细
+比如你们公司线上系统高峰QPS 3000？
+那请求主要访问哪些接口？
+redis抗了多少请求？
+mysql抗了多少请求？
+你到底是怎么实现高并发的？
+咱们聊聊redis的内核吧，看看你对底层了解的多么？
+如果要缓存几百GB的数据会有什么坑该这么弄？
+如果缓存出现热点现象该这么处理？
+某个value特别大把网卡给打死了怎么办？
+等等等等，可以深挖的东西其实有很多。。。。。
+
+但是如果你掌握好了这套东西的回答，那么你在面试的时候，如果面试官没有全都问到，你可以自己主动合盘脱出。
+比如你可以说，我们线上的缓存，做了啥啥机制，防止雪崩、防止穿透、保证双写时的数据一致性、保证并发竞争时的数据一致性，我们线上咋部署的，啥架构，怎么玩儿的。
+这套东西你可以自己说出来，展示一下你对缓存这块的掌握。
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(31)-\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\350\277\236\347\216\257\347\202\256.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(31)-\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\350\277\236\347\216\257\347\202\256.md"
new file mode 100644
index 0000000000..ed8ff851ea
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(31)-\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\350\277\236\347\216\257\347\202\256.md"
@@ -0,0 +1,53 @@
+# 0 导读
+有一些同学，之前呢主要是做传统行业，外包项目，互联网公司，一直是那种小的公司，技术一直都搞的比较简单。共同的一个问题，就是都没怎么搞过分布式系统，现在互联网公司，一般都是做分布式的系统，大家都不是做底层的分布式系统，分布式存储系统，hadoop hdfs，分布式计算系统，hadoop mapreduce，spark，分布式流式计算系统，storm。
+
+分布式业务系统，就是把原来用java开发的一个大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。
+假设原来你做了一个OA系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1台机器部署。
+
+现在如果你把他这个系统给拆开，权限系统，员工系统，请假系统，财务系统，4个系统，4个工程，分别在4台机器上部署
+
+一个请求过来，完成这个请求，这个员工系统，调用权限系统，调用请假系统，调用财务系统，4个系统分别完成了一部分的事情，最后4个系统都干完了以后，才认为是这个请求已经完成了。
+
+我就搞不懂，到底什么是分布式系统？
+- 什么是最简单的分布式系统
+![](https://img-blog.csdnimg.cn/20190515161405760.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+# 1 缘何系统拆分
+（1）为什么要进行系统拆分？如何进行系统拆分？拆分后不用dubbo可以吗？dubbo和thrift有什么区别呢？
+
+# 2 分布式服务框架
+（1）说一下的dubbo的工作原理？注册中心挂了可以继续通信吗？
+
+（2）dubbo支持哪些序列化协议？说一下hessian的数据结构？PB知道吗？为什么PB的效率是最高的？
+
+（3）dubbo负载均衡策略和高可用策略都有哪些？动态代理策略呢？
+
+（4）dubbo的spi思想是什么？
+
+（5）如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试？
+
+（6）分布式服务接口的幂等性如何设计（比如不能重复扣款）？
+
+（7）分布式服务接口请求的顺序性如何保证？
+
+（8）如何自己设计一个类似dubbo的rpc框架？
+
+但是这两年开始兴起和流行了spring cloud，但是我们这里就不讲了，spring cloud刚开始流行，还没有普及，目前普及的是dubbo，出去面试，大部分面试官都是问你dubbo的一些问题
+
+# 3 分布式锁
+（1）使用redis如何设计分布式锁？使用zk来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
+
+# 4 分布式事务
+（1）分布式事务了解吗？你们如何解决分布式事务问题的？TCC如果出现网络连不通怎么办？XA的一致性如何保证？
+# 5 分布式会话
+（1）集群部署时的分布式session如何实现？
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(32)-\344\270\272\344\273\200\344\271\210\350\246\201\346\212\212\347\263\273\347\273\237\346\213\206\345\210\206\346\210\220\345\210\206\345\270\203\345\274\217\347\232\204\357\274\237\344\270\272\345\225\245\350\246\201\347\224\250dubbo.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(32)-\344\270\272\344\273\200\344\271\210\350\246\201\346\212\212\347\263\273\347\273\237\346\213\206\345\210\206\346\210\220\345\210\206\345\270\203\345\274\217\347\232\204\357\274\237\344\270\272\345\225\245\350\246\201\347\224\250dubbo.md"
new file mode 100644
index 0000000000..d388932f3a
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(32)-\344\270\272\344\273\200\344\271\210\350\246\201\346\212\212\347\263\273\347\273\237\346\213\206\345\210\206\346\210\220\345\210\206\345\270\203\345\274\217\347\232\204\357\274\237\344\270\272\345\225\245\350\246\201\347\224\250dubbo.md"
@@ -0,0 +1,84 @@
+
+# 1 面试题
+- 为什么要进行系统拆分？
+- 如何进行系统拆分？
+- 拆分后不用dubbo可以吗？
+
+# 2 考点分析
+从该节开始就进行分布式系统环节了，好多同学说，现在出去分布式成标配了，没有哪个公司不问问你分布式的事儿。你要是不会分布式的东西，简直这简历没法看，没人会让你去面试。
+
+其实为啥会这样呢？这就是因为整个大行业技术发展的原因
+
+早些年，在2010年初的时候，整个IT行业，很少有人谈分布式，更不用说微服务，虽然很多BAT等大型公司，因为系统的复杂性，很早就是分布式架构，大量的服务，只不过微服务大多基于自己搞的一套框架来实现而已。
+
+但是确实，那个年代，大家很重视ssh，很多中小型公司几乎大部分都是玩儿struts2、spring、hibernate，稍晚一些，才进入了spring mvc、spring、mybatis的组合。那个时候整个行业的技术水平就是那样，当年oracle很火，oracle管理员很吃香，oracle性能优化啥的都是IT男的大杀招啊。连大数据都没人提，当年OCP、OCM等认证培训机构，火的不行。
+
+但是确实随着时代的发展，慢慢的，很多公司开始接受分布式系统架构了，这里面尤为对行业有至关重要影响的，是阿里的dubbo，某种程度上而言，阿里在这里推动了行业技术的前进。
+
+正是因为有阿里的dubbo，很多中小型公司才可以基于dubbo，来把系统拆分成很多的服务，每个人负责一个服务，大家的代码都没有冲突，服务可以自治，自己选用什么技术都可以，每次发布如果就改动一个服务那就上线一个服务好了，不用所有人一起联调，每次发布都是几十万行代码，甚至几百万行代码了。
+
+直到今日，很高兴的看到分布式系统都成行业面试标配了，任何一个普通的程序员都该掌握这个东西，其实这是行业的进步，也是所有IT码农的技术进步。所以既然分布式都成标配了，那么面试官当然会问了，因为很多公司现在都是分布式、微服务的架构，那面试官当然得考察考察你了。
+
+> 如果有个同学看到这里说，我天，我不知道啥是分布式系统？我也不知道啥是dubbo？那你赶紧百度啊，搜个dubbo入门，去里面体验一下。
+
+分布式系统，我用一句话给你解释一下，实在没时间多唠了，就是原来20万行代码的系统，现在拆分成20个小系统，每个小系统1万行代码。原本代码之间直接就是基于spring调用，现在拆分开来了，20个小系统部署在不同的机器上，得基于dubbo搞一个rpc调用，接口与接口之间通过网络通信来请求和响应。就这个意思。
+
+# 3 详解
+## 3.1 缘何系统拆分
+网上查查，答案极度零散和复杂，很琐碎，原因一大坨。但是这里给大家直观的感受：
+
+### 3.1.1  不拆分,维护成本高
+要是不拆分，一个大系统几十万行代码，20个人维护一份代码，简直是悲剧啊。代码经常改着改着就冲突了，各种代码冲突和合并要处理，非常耗费时间；经常我改动了我的代码，你调用了我，导致你的代码也得重新测试，麻烦的要死；然后每次发布都是几十万行代码的系统一起发布，大家得一起提心吊胆准备上线，几十万行代码的上线，可能每次上线都要做很多的检查，很多异常问题的处理，简直是又麻烦又痛苦；而且如果我现在打算把技术升级到最新的spring版本，还不行，因为这可能导致你的代码报错，我不敢随意乱改技术。
+
+假设一个系统是20万行代码，其中小A在里面改了1000行代码，但是此时发布的时候是这个20万行代码的大系统一块儿发布。就意味着20万上代码在线上就可能出现各种变化，20个人，每个人都要紧张地等在电脑面前，上线之后，检查日志，看自己负责的那一块儿有没有什么问题。
+
+小A就检查了自己负责的1万行代码对应的功能，确保ok就闪人了；结果不巧的是，小A上线的时候不小心修改了线上机器的某个配置，导致另外小B和小C负责的2万行代码对应的一些功能，出错了
+
+几十个人负责维护一个几十万行代码的单块应用，每次上线，准备几个礼拜，上线 -> 部署 -> 检查自己负责的功能
+
+最近从2013年到现在，5年的时间里，2013年以前，基本上都是BAT的天下；2013年开始，有几个小巨头开始快速的发展，上市，几百亿美金，估值都几百亿美金；2015年，出现了除了BAT以外，又有几个互联网行业的小巨头出现。
+
+BAT工作，在市值几百亿美金的小巨头工作
+
+有某一个小巨头，现在估值几百亿美金的小巨头，5年前刚开始搞的时候，核心的业务，几十个人，维护一个单块的应用
+
+维护单块的应用，在从0到1的环节里，是很合适的，因为那个时候，是系统都没上线，没什么技术挑战，大家有条不紊的开发。ssh + mysql + tomcat，可能会部署几台机器吧。
+
+结果不行了，后来系统上线了，业务快速发展，10万用户 -> 100万用户 -> 1000万用户 -> 上亿用户了。
+
+### 3.1.2 拆分后,世界清净了
+拆分了以后，整个世界清爽了，几十万行代码的系统，拆分成20个服务，平均每个服务就1~2万行代码，每个服务部署到单独的机器上。20个工程，20个git代码仓库里，20个码农，每个人维护自己的那个服务就可以了，是自己独立的代码，跟别人没关系。再也没有代码冲突了，爽。每次就测试我自己的代码就可以了，爽。每次就发布我自己的一个小服务就可以了，爽。技术上想怎么升级就怎么升级，保持接口不变就可以了，爽。
+
+所以简单来说，一句话总结，如果是那种代码量多达几十万行的中大型项目，团队里有几十个人，那么如果不拆分系统，开发效率极其低下，问题很多。但是拆分系统之后，每个人就负责自己的一小部分就好了，可以随便玩儿随便弄。分布式系统拆分之后，可以大幅度提升复杂系统大型团队的开发效率。
+
+但是同时，也要提醒的一点是，系统拆分成分布式系统之后，大量的分布式系统面临的问题也是接踵而来，所以后面的问题都是在围绕分布式系统带来的复杂技术挑战在说。
+
+## 3.2 如何拆分系统
+这个问题说大可以很大，可以扯到领域驱动模型设计上去，说小了也很小，我不太想给大家太过于学术的说法，因为你也不可能背这个答案，过去了直接说吧。还是说的简单一点，大家自己到时候知道怎么回答就行了。
+
+系统拆分分布式系统，拆成多个服务，拆成微服务的架构，拆很多轮的。上来一个架构师第一轮就给拆好了，第一轮；团队继续扩大，拆好的某个服务，刚开始是1个人维护1万行代码，后来业务系统越来越复杂，这个服务是10万行代码，5个人；第二轮，1个服务 -> 5个服务，每个服务2万行代码，每人负责一个服务
+
+如果是多人维护一个服务，<=3个人维护这个服务；最理想的情况下，几十个人，1个人负责1个或2~3个服务；某个服务工作量变大了，代码量越来越多，某个同学，负责一个服务，代码量变成了10万行了，他自己不堪重负，他现在一个人拆开，5个服务，1个人顶着，负责5个人，接着招人，2个人，给那个同学带着，3个人负责5个服务，其中2个人每个人负责2个服务，1个人负责1个服务
+
+我个人建议，一个服务的代码不要太多，1万行左右，两三万撑死了吧
+
+大部分的系统，是要进行多轮拆分的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统，等等吧。
+
+但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了供应商管理系统、采购单管理系统，订单系统又拆分成了购物车系统、价格系统、订单管理系统。
+
+扯深了实在很深，所以这里先给大家举个例子，你自己感受一下，核心意思就是根据情况，先拆分一轮，后面如果系统更复杂了，可以继续分拆。你根据自己负责系统的例子，来考虑一下就好了。
+
+## 3.3 拆分后不用dubbo可以吗？
+
+当然可以了，大不了最次，就是各个系统之间，直接基于spring mvc，就纯http接口互相通信呗，还能咋样。但是这个肯定是有问题的，因为http接口通信维护起来成本很高，你要考虑超时重试、负载均衡等等各种乱七八糟的问题，比如说你的订单系统调用商品系统，商品系统部署了5台机器，你怎么把请求均匀地甩给那5台机器？这不就是负载均衡？你要是都自己搞那是可以的，但是确实很痛苦。
+
+所以dubbo说白了，是一种rpc框架，就是本地就是进行接口调用，但是dubbo会代理这个调用请求，跟远程机器网络通信，给你处理掉负载均衡了、服务实例上下线自动感知了、超时重试了，等等乱七八糟的问题。那你就不用自己做了，用dubbo就可以了。
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(33)-Dubbo\347\232\204\345\267\245\344\275\234\345\216\237\347\220\206.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(33)-Dubbo\347\232\204\345\267\245\344\275\234\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..b606cf8979
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(33)-Dubbo\347\232\204\345\267\245\344\275\234\345\216\237\347\220\206.md"
@@ -0,0 +1,52 @@
+
+# 1 面试题
+- 说一下的dubbo的工作原理？
+- 注册中心挂了可以继续通信吗？
+- 说说一次rpc请求的流程？
+
+# 2 考点分析
+MQ、ES、Redis、Dubbo，上来先问你一些思考的问题，原理（kafka高可用架构原理、es分布式架构原理、redis线程模型原理、Dubbo工作原理），生产环境里可能会碰到的一些问题（每种技术引入之后生产环境都可能会碰到一些问题），系统设计（设计MQ，设计搜索引擎，设计一个缓存，设计rpc框架）
+
+当然比如说，hard面试官，死扣，结合项目死扣细节，百度（深入底层，基础性），阿里（结合项目死扣细节，扣很深的技术底层），小米（数据结构和算法）。
+
+那既然开始聊分布式系统了，自然重点先聊聊dubbo了，毕竟dubbo是目前事实上大部分公司的分布式系统的rpc框架标准，基于dubbo也可以构建一整套的微服务架构。但是需要自己大量开发。
+
+当然去年开始spring cloud非常火，现在大量的公司开始转向spring cloud了，spring cloud人家毕竟是微服务架构的全家桶式的这么一个东西。但是因为很多公司还在用dubbo，所以dubbo肯定会是目前面试的重点，何况人家dubbo现在重启开源社区维护了，未来应该也还是有一定市场和地位的。
+
+既然聊dubbo，那肯定是先从dubbo原理开始聊了，你先说说dubbo支撑rpc分布式调用的架构师啥，然后说说一次rpc请求dubbo是怎么给你完成的，对吧。
+
+# 3 详解
+## 3.1 dubbo工作原理
+第一层：service层，接口层，给服务提供者和消费者来实现的
+第二层：config层，配置层，主要是对dubbo进行各种配置的
+第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton
+第四层：registry层，服务注册层，负责服务的注册与发现
+第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
+第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
+第七层：protocol层，远程调用层，封装rpc调用
+第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
+第九层：transport层，网络传输层，抽象mina和netty为统一接口
+第十层：serialize层，数据序列化层
+
+### 3.1.1 工作流程：
+1）第一步，provider向注册中心去注册
+2）第二步，consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务
+3）第三步，consumer调用provider
+4）第四步，consumer和provider都异步的通知监控中心
+
+## 3.2 注册中心挂了可以继续通信吗？
+可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(34)-dubbo\346\224\257\346\214\201\347\232\204\345\215\217\350\256\256.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(34)-dubbo\346\224\257\346\214\201\347\232\204\345\215\217\350\256\256.md"
new file mode 100644
index 0000000000..904d835cec
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(34)-dubbo\346\224\257\346\214\201\347\232\204\345\215\217\350\256\256.md"
@@ -0,0 +1,66 @@
+# 1 面试题
+
+- dubbo支持哪些通信协议？
+- 支持哪些序列化协议？
+
+# 2 考点分析
+
+在上一篇文章，我们说到dubbo的基本工作原理，那是你必须知道的，至少知道dubbo分成哪些层，然后平时怎么发起rpc请求的，注册、发现、调用，这些是最基本的。
+
+接着就可以针对底层进行深入的讨伐了，比如第一步就可以先问问序列化协议这块，就是平时rpc的时候怎么走的？
+
+# 3 面试题详解
+
+## 3.1 dubbo支持的广阔通信协议
+
+![](https://ask.qcloudimg.com/http-save/1752328/vd6y05p1i2.png)
+
+### 3.1.1 dubbo协议
+
+```
+dubbo://192.168.0.1:20188
+```
+
+`默认`就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议
+
+#### 适用场景
+
+传输数据量很小（每次请求在100kb以内），但是并发量很高
+
+为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就100个连接。然后后面直接基于长连接NIO异步通信，可以支撑高并发请求。
+
+否则如果上亿次请求每次都是短连接的话，服务提供者会扛不住。
+
+而且因为走的是单一长连接，所以传输数据量太大的话，会导致并发能力降低。所以一般建议是传输数据量很小，支撑高并发访问。
+
+### 3.1.2 rmi协议
+
+走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用
+
+### 3.1.3 hessian协议
+
+走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用
+
+### 3.1.4 http协议
+
+走json序列化
+
+### 3.1.5 webservice
+
+走SOAP文本序列化
+
+## 3.2 dubbo支持的序列化协议
+
+所以dubbo实际基于不同的通信协议，支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协议。但是hessian是其默认的序列化协议。
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(35)-Dubbo\350\264\237\350\275\275\345\235\207\350\241\241\345\217\212\345\212\250\346\200\201\344\273\243\347\220\206\347\232\204\347\255\226\347\225\245.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(35)-Dubbo\350\264\237\350\275\275\345\235\207\350\241\241\345\217\212\345\212\250\346\200\201\344\273\243\347\220\206\347\232\204\347\255\226\347\225\245.md"
new file mode 100644
index 0000000000..6bfd670722
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(35)-Dubbo\350\264\237\350\275\275\345\235\207\350\241\241\345\217\212\345\212\250\346\200\201\344\273\243\347\220\206\347\232\204\347\255\226\347\225\245.md"
@@ -0,0 +1,80 @@
+# 1 面试题
+
+Dubbo负载均衡策略和集群容错策略都有哪些？动态代理策略呢？
+
+# 2 考点分析
+
+这些都是关于Dubbo必须知道，基本原理，序列化是什么协议，具体用dubbo的时候，如何负载均衡，如何高可用，如何动态代理等.
+
+就是看你对Dubbo掌握程度
+
+- 工作原理：服务注册，注册中心，消费者，代理通信，负载均衡
+- 网络通信、序列化：dubbo协议，长连接，NIO，hessian序列化协议
+- 负载均衡策略，集群容错策略，动态代理策略：dubbo跑起来的时候一些功能是如何运转的，怎么做负载均衡？怎么做集群容错？怎么生成动态代理？
+- dubbo SPI机制：你了解不了解dubbo的SPI机制？如何基于SPI机制对dubbo进行扩展？
+
+# 3 负载均衡策略
+
+![](https://ask.qcloudimg.com/http-save/1752328/nphpq0four.png)
+
+## 3.1 random loadbalance
+
+dubbo默认采用random load balance,即随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用默认的即可.
+
+## 3.2 roundrobin loadbalance
+
+均匀地将流量打到各个机器上去，但如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
+
+## 3.3  leastactive loadbalance
+
+自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求
+
+## 3.4 consistanthash loadbalance
+
+一致性Hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大
+
+如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。
+
+# 4 集群容错策略
+
+## 4.1 failover cluster模式
+
+默认,失败自动切换，自动重试其他机器,常用于读操作
+
+## 4.2 failfast cluster模式
+
+一次调用失败就立即失败，常用于写操作
+
+## 4.3 failsafe cluster模式
+
+发生异常时忽略掉，常用于不重要的接口调用，如记录日志
+
+## 4.4 failbackc cluster模式
+
+失败了后台自动记录请求，然后定时重发，适于写消息队列
+
+## 4.5 forking cluster
+
+**并行调用**多个provider，只要一个成功就立即返回
+
+## 4.6 broadcacst cluster
+
+逐个调用所有的provider
+
+# 5 动态代理策略
+
+默认使用javassist动态字节码生成，创建代理类
+
+但是可以通过spi扩展机制配置自己的动态代理策略
+
+# 参考
+
+《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(36)-\350\201\212\350\201\212Dubbo\347\232\204SPI\346\234\272\345\210\266.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(36)-\350\201\212\350\201\212Dubbo\347\232\204SPI\346\234\272\345\210\266.md"
new file mode 100644
index 0000000000..95528c198e
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(36)-\350\201\212\350\201\212Dubbo\347\232\204SPI\346\234\272\345\210\266.md"
@@ -0,0 +1,137 @@
+# 1 面试题
+
+Dubbo中的SPI是什么？
+
+# 2 考点分析
+
+前面基础性的东西问完了，确定你应该了解Dubbo，那么自然问个稍微难的问题，就是SPI，先问问你这是个啥,然后问问你怎么实现的!
+
+其实就是看看你对dubbo的掌握如何
+
+# 3 SPI简介
+
+SPI 全称为 Service Provider Interface，是一种服务发现机制.
+
+说白了是啥呢，比如你有个接口，该接口有3个实现类，那么在系统运行时,这个接口到底选择哪个实现类呢？这就需要SPI了，需要**根据指定的配置或者是默认的配置，找到对应的实现类加载进来，然后使用该实现类的实例**.
+
+> 接口A => 实现A1，实现A2，实现A3
+> 配置一下，接口A = 实现A2
+> 在系统实际运行的时候，会加载你的配置，用实现A2实例化一个对象来提供服务
+
+比如说你要通过jar包的方式给某个接口提供实现，然后你就在自己jar包的`META-INF/services/`目录下放一个接口同名文件，指定接口的实现是自己这个jar包里的某个类.
+
+ok了，别人用了一个接口，然后用了你的jar包，就会在运行的时候通过你的jar包的那个文件找到这个接口该用哪个实现类.
+
+这是JDK提供的一个功能.
+
+比如你有个工程A，有个接口A，接口A在工程A是没有实现类的,那么问题来了,系统运行时,怎么给接口A选择一个实现类呢?
+
+你可以自己搞一个jar包，`META-INF/services/`,放上一个文件,文件名即接口名，接口A，接口A的实现类=`com.javaedge.service.实现类A2`
+
+让工程A来依赖你的jar包,然后在系统运行时,工程A跑起来,对于接口A,就会扫描依赖的jar包,看看有没有`META-INF/services`文件夹,如果有,看再看有没有名为接口A的文件,如果有,在里面找一下指定的接口A的实现是你的jar包里的哪个类!
+
+# 4 适用场景
+
+插件扩展的场景,比如你开发了一个开源框架，若你想让别人自己写个插件，安排到你的开源框架里中，扩展功能
+
+## 4.1  Java中的SPI
+
+经典的思想体现，其实大家平时都在用，比如说JDBC
+
+Java定义了一套JDBC的接口，但是并没有提供其实现类
+
+但实际上项目运行时,要使用JDBC接口的哪些实现类呢?
+
+一般来说，我们要根据自己使用的数据库，比如
+
+- MySQL,你就将`mysql-jdbc-connector.jar`
+- oracle，你就将`oracle-jdbc-connector.jar`引入
+
+系统运行时,碰到你使用JDBC的接口,就会在底层使用你引入的那个jar中提供的实现类
+
+## 4.2 Dubbo中的SPI
+
+Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，配置内容如下。
+
+```
+Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
+```
+
+Dubbo要判断一下，在系统运行时，应该选用这个Protocol接口的哪个实现类.
+
+它会去找一个你配置的Protocol，将你配置的Protocol实现类，加载进JVM，将其实例化.
+
+微内核，可插拔，大量的组件，Protocol负责RPC调用的东西，你可以实现自己的RPC调用组件，实现Protocol接口，给自己的一个实现类即可.
+
+这行代码就是Dubbo里大量使用的，就是对很多组件，都是保留一个接口和多个实现，然后在系统运行的时候动态根据配置去找到对应的实现类。如果你没配置，那就走默认的实现好了,问题不大.
+
+### 4.2.1 实例
+
+```
+@SPI("dubbo")  
+public interface Protocol {  
+      
+    int getDefaultPort();  
+  
+    @Adaptive  
+    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;  
+  
+    @Adaptive  
+    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;  
+
+    void destroy();  
+}  
+```
+
+在Dubbo自己的jar里，在`/META_INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol`文件中:
+
+```
+dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol
+http=com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
+hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
+```
+
+这就可以看到Dubbo的SPI机制默认怎么玩的了,其实就是Protocol接口
+
+- @SPI("dubbo")
+通过SPI机制提供实现类，实现类是通过将`dubbo`作为默认key去配置文件里找到的，配置文件名称为接口全限定名，通过`dubbo`作为key可以找到默认的实现类`com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol`
+
+> Dubbo的默认网络通信协议，就是dubbo协议，用的DubboProtocol
+
+若想要动态替换默认的实现类，需使用`@Adaptive`接口，Protocol接口中，有两个方法添加了`@Adaptive`注解，就是说那俩接口会被代理实现.
+
+具体啥玩意儿呢?
+
+比如这个Protocol接口搞了俩`@Adaptive`注解了方法，在运行时会针对Protocol生成代理类，该代理类的那俩方法中会有代理代码，代理代码会在运行时动态根据url中的protocol来获取key(默认是dubbo)，也可以自己指定，如果指定了别的key，那么就会获取别的实现类的实例.
+
+通过这个url中的参数不同，就可以控制动态使用不同的组件实现类
+
+# 5 扩展Dubbo组件
+
+自己写个工程，可以打成jar包的那种哦
+
+- 里面的`src/main/resources`目录下<dubbo:protocol name=”my” port=”20000” />这个时候provider启动的时候，就会加载到我们jar包里的`my=com.javaedge.MyProtocol`这行配置，接着会根据你的配置使用你定义好的MyProtocol了，这个就是简单说明一下，你通过上述方式，可以替换掉大量的dubbo内部的组件，就是扔个你自己的jar包，然后配置一下即可~
+- 搞一个`META-INF/services`
+- 里面放个文件叫：`com.alibaba.dubbo.rpc.Protocol`
+- 文件里搞一个`my=com.javaedge.MyProtocol`
+- 自己把jar弄到nexus私服
+- 然后自己搞一个dubbo provider工程，在这个工程里面依赖你自己搞的那个jar
+- 然后在spring配置文件里给个配置：
+- Dubbo的SPI原理图
+![](https://ask.qcloudimg.com/http-save/1752328/b7iaarse08.png)
+
+Dubbo中提供了大量的类似上面的扩展点.
+
+你要扩展一个东西，只需自己写个jar，让你的consumer或者是provider工程，依赖它，在你的jar里指定目录下配置好接口名称对应的文件，里面通过`key=实现类`然后对对应的组件，用类似`<dubbo:protocol>`用你的哪个key对应的实现类来实现某个接口，你可以自己去扩展dubbo的各种功能，提供你自己的实现!
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+- [Dubbo官方文档](https://dubbo.apache.org/zh-cn/docs/source_code_guide/)
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(37)-\345\237\272\344\272\216Dubbo\347\232\204\346\234\215\345\212\241\346\262\273\347\220\206\343\200\201\346\234\215\345\212\241\351\231\215\347\272\247\344\273\245\345\217\212\351\207\215\350\257\225.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(37)-\345\237\272\344\272\216Dubbo\347\232\204\346\234\215\345\212\241\346\262\273\347\220\206\343\200\201\346\234\215\345\212\241\351\231\215\347\272\247\344\273\245\345\217\212\351\207\215\350\257\225.md"
new file mode 100644
index 0000000000..73c825b626
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(37)-\345\237\272\344\272\216Dubbo\347\232\204\346\234\215\345\212\241\346\262\273\347\220\206\343\200\201\346\234\215\345\212\241\351\231\215\347\272\247\344\273\245\345\217\212\351\207\215\350\257\225.md"
@@ -0,0 +1,154 @@
+# 1 面试题
+
+如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试？
+
+# 2 考点分析
+
+- 服务治理
+其实就是看看你有没有服务治理的思想，因为这是做过复杂微服务的人肯定会遇到的问题!
+- 服务降级
+涉及到复杂分布式系统中必备的一个话题，因为分布式系统互相来回调用，任何一个系统故障了，你不降级，直接就整个瘫痪了!
+- 失败重试
+分布式系统中网络请求如此频繁，要是因为网络问题不小心失败了一次，是不是要重试呢
+- 超时重试
+同上，如果不小心网络慢一点，超时了，又该如何重试呢
+
+# 3 服务治理
+
+## 3.1 调用链路自动生成
+
+一个大型的分布式系统，或者拿现在流行的微服务架构来说吧，分布式系统由大量服务组成.
+
+那么这些服务之间互相是如何调用的？调用链路是什么?
+
+讲真的，几乎到后面没人搞的清楚，因为服务实在太多了，可能几百个甚至几千个!
+
+那就需要基于Dubbo做的分布式系统中，对各个服务之间的调用自动记录下来，然后自动将各个服务之间的依赖关系和调用链路生成出来，做成一张图，显示出来，大家才可以看到.
+
+```
+服务A   => 服务B   => 服务E
+                  => 服务F
+       => 服务C
+                  => 服务G
+       => 服务D
+```
+
+![](https://ask.qcloudimg.com/http-save/1752328/3z44jb9ogc.png)
+
+## 3.2 服务访问压力以及时长统计
+
+需要自动统计**各个接口和服务之间的调用次数以及访问延时**，而且要分成两个级别:
+
+- 接口粒度
+每个服务的每个接口每天被调用多少次，TP50/TP90/TP99，三个档次的请求延时分别是多少
+- 从入口开始
+一个完整的请求链路经过几十个服务之后，完成一次请求，每天全链路走多少次,全链路请求延时的TP50/TP90/TP99，分别是多少
+
+这些东西都搞定了之后，后面才可以来看当前系统的压力主要在哪里，来确定如何扩容和优化
+
+## 3.3 其他
+
+- 服务分层（避免循环依赖）
+- 调用链路失败监控和报警
+- 服务鉴权
+- 每个服务的可用性的监控(接口调用成功率？几个9？99.99%，99.9%，99%)
+
+# 4 服务降级
+
+比如说服务A调用服务B，结果服务B挂了，服务A重试几次调用服务B，还是不行，直接降级，走一个备用的逻辑，给用户返回响应
+
+```
+public interface HelloService {
+
+   void sayHello();
+
+}
+```
+
+```
+public class HelloServiceImpl implements HelloService {
+
+    public void sayHello() {
+        System.out.println("hello world......");
+    }
+	
+}
+```
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
+
+    <dubbo:application name="dubbo-provider" />
+    <dubbo:registry address="zookeeper://127.0.0.1:2181" />
+    <dubbo:protocol name="dubbo" port="20880" />
+    <dubbo:service interface="com.javaedge.service.HelloService" ref="helloServiceImpl" timeout="10000" />
+    <bean id="helloServiceImpl" class="com.zhss.service.HelloServiceImpl" />
+
+</beans>
+```
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
+    xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
+
+    <dubbo:application name="dubbo-consumer"  />
+
+    <dubbo:registry address="zookeeper://127.0.0.1:2181" />
+
+    <dubbo:reference id="fooService" interface="com.test.service.FooService"  timeout="10000" check="false" mock="return null">
+    </dubbo:reference>
+
+</beans>
+```
+
+现在就是mock，如果调用失败统一返回null
+
+但是可以将mock修改为true，然后在跟接口同一个路径下实现一个Mock类，命名规则:
+
+```
+接口名称 + Mock
+```
+
+然后在Mock类里实现自己的降级逻辑:
+
+```
+public class HelloServiceMock implements HelloService {
+	public void sayHello() {
+	// 降级逻辑
+	}
+}
+```
+
+# 5 失败重试和超时重试
+
+- 失败重试
+consumer调用provider要是失败了(比如抛异常),此时应该是可以重试的，或者调用超时了也可以重试。<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>
+
+某个服务的接口，要耗费5s，你这边不能干等着，你这边配置了timeout之后，我等待2s，还没返回，我直接就撤了，不能一直在你这耗着
+
+如果是超时了，timeout就会设置超时时间；如果是调用失败了自动就会重试指定的次数
+
+结合你们公司的具体的场景来说说你是怎么设置这些参数的
+
+- timeout
+一般设置为200ms，我们认为不能超过200ms还没返回
+- retries
+3次，设置retries，一般发生在读请求时
+比如你要查询某个数据，你可以设置retries，如果第一次没读到，报错，重试指定的次数，尝试再读取2次
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(38)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\345\271\202\347\255\211\346\200\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(38)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\345\271\202\347\255\211\346\200\247.md"
new file mode 100644
index 0000000000..fa5c6ec94c
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(38)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\345\271\202\347\255\211\346\200\247.md"
@@ -0,0 +1,67 @@
+# 1 面试题
+
+分布式服务接口的幂等性如何设计（比如不能重复扣款）？
+
+# 2 考点分析
+
+从这开始，面试官就已经进入了实际的生产问题的面试了
+
+一个分布式系统中的某个接口，要保证幂等性，如何保证？
+
+这个事,其实是你做分布式系统的时候必须要考虑的一个生产环境的技术问题.为什么呢？
+
+假如你有个服务提供一个接口，这服务部署在5台机器上，有个付款接口.
+
+然后用户在前端操作时，不知为啥，一个订单不小心发起了两次支付请求，然后这俩请求分散在了这个服务部署的不同的机器上,这下好了,结果一个订单扣款扣两次,尴尬了!
+
+或者是订单系统调用支付系统进行支付，结果不小心**网络超时**，然后订单系统走了前面我们看到的那个重试机制，给你重试了一把，好，支付系统收到一个支付请求两次，而且因为负载均衡算法落在了不同的机器上，尴尬了!
+
+- 分布式系统接口的幂等性问题
+![](https://ask.qcloudimg.com/http-save/1752328/b495fb7ej5.png)
+
+所以你肯定得知道这事儿，否则你做出来的分布式系统恐怕容易埋坑!
+
+网络问题很常见，100次请求，都ok
+
+1万次，可能1次是超时会重试
+
+10万，10次；100万，100次；如果有100个请求重复了，你没处理，导致订单扣款2次，100个订单都扣错了；每天被100个用户投诉；一个月被3000个用户投诉
+
+这个不是技术问题，没有通用的一个方法，得结合业务来看应该如何保证幂等性.
+
+# 3 幂等性
+
+所谓幂等性，简而言之,就是一个接口，多次发起同一个请求，接口得保证结果是准确的，比如不能多扣款，不能多插入一条数据，不能将统计值多加了1.
+
+保证幂等性主要有如下几点
+
+- 对于每个请求必须有一个唯一的标识
+举个例子:订单支付请求，肯定得包含订单id，一个订单id最多支付一次
+- 每次处理完请求后，须有一个记录标识该请求已被处理
+比如说常见的方案是在MySQL中记录个状态字段
+比如支付之前记录一条这个订单的支付流水
+- 每次接收请求需要进行判断之前是否处理过
+比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId已存在，唯一键约束生效，报错插入不进去的。然后你就不用再扣款了.
+
+上面只是举个例子，实际运作过程中，要结合自己的业务来，比如说用redis,用orderId作为唯一键。只有成功插入这个支付流水，才可以执行实际的支付扣款。
+
+要求是支付一个订单,必须插入一条支付流水,order\_id建立一个唯一键`unique key`
+
+你在支付一个订单前,先插入一条支付流水,`order_id`就已经传过去了
+
+你就可以写一个标识到Redis中,`set order_id payed`,当重复请求过来时,先查Redis的`order_id`对应的`value`,若为`payed`说明已支付,就别重复支付了!
+
+然后呢，你再重复支付这个订单的时候，你写尝试插入一条支付流水，数据库给你报错了，说unique key冲突了，整个事务回滚就可以了
+
+来保存一个是否处理过的标识也可以，服务的不同实例可以一起操作Redis.
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》[Github](https://github.com/Wasabi1234)
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(39)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\350\257\267\346\261\202\347\232\204\351\241\272\345\272\217\346\200\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(39)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\350\257\267\346\261\202\347\232\204\351\241\272\345\272\217\346\200\247.md"
new file mode 100644
index 0000000000..08382e6061
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(39)-\345\210\206\345\270\203\345\274\217\346\234\215\345\212\241\346\216\245\345\217\243\350\257\267\346\261\202\347\232\204\351\241\272\345\272\217\346\200\247.md"
@@ -0,0 +1,43 @@
+# 1 面试题
+
+分布式服务接口请求的顺序性如何保证？
+
+# 2 考点分析
+
+分布式系统接口的调用顺序,一般来说是不用保证的.
+
+但是有时候可能确实需要**严格的顺序保证**.
+
+举个例子:
+
+服务 A 调用服务 B，先插入再删除。好，结果俩请求过去了，落在不同机器上，可能插入请求因为某些原因执行慢了一些，导致删除请求先执行了，此时因为没数据所以啥效果也没有；结果这个时候插入请求过来了，好，数据插入进去了，尴尬咯~
+
+本该 “先插入 => 再删除”，这条数据应该没了，结果现在 “先删除 => 再插入”，数据还存在!
+
+所以这都是分布式系统一些很常见的问题。
+
+# 3 解决方案
+
+一般来说,建议从业务逻辑上设计的系统最好是不需要这种顺序性的保证，因为一旦引入顺序性保障，比如使用**分布式锁**，会导致**系统复杂度上升**，而且会带来**效率低下**，**热点数据压力过大**等问题。
+
+简单来说，首先你得用 Dubbo 的一致性 hash 负载均衡策略,将比如某一个订单 id 对应的请求都给分发到某个机器上去，接着就是在那个机器上因为可能还是多线程并发执行的，你可能得立即将某个订单 id 对应的请求扔一个**内存队列**里去，强制排队，来确保他们的顺序性
+
+- 分布式系统接口调用顺序性图示
+![](https://ask.qcloudimg.com/http-save/1752328/m3u86wst0u.png)
+
+但是这样引发的后续问题就很多!
+
+比如说要是某个订单对应的请求特别多，造成某台机器成**热点**怎么办？解决这些问题又要开启后续一连串的复杂技术方案......曾经这类问题弄的我们头疼不已，所以，还是建议什么呢？
+
+最好是比如说刚才那种，一个订单的插入和删除操作，能不能合并成一个操作，就是一个删除，或者是什么，避免这种问题的产生。
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(40)-\345\246\202\344\275\225\350\256\276\350\256\241\344\270\200\344\270\252\347\261\273\344\274\274Dubbo\347\232\204RPC\346\241\206\346\236\266.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(40)-\345\246\202\344\275\225\350\256\276\350\256\241\344\270\200\344\270\252\347\261\273\344\274\274Dubbo\347\232\204RPC\346\241\206\346\236\266.md"
new file mode 100644
index 0000000000..459acdd179
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(40)-\345\246\202\344\275\225\350\256\276\350\256\241\344\270\200\344\270\252\347\261\273\344\274\274Dubbo\347\232\204RPC\346\241\206\346\236\266.md"
@@ -0,0 +1,41 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+如何设计一个类似Dubbo的RPC框架
+
+# 2 考点分析
+就跟问你如何设计一个MQ一样的道理，就考两个:
+- 你有没有对某个RPC框架原理有非常深入的理解
+- 你能不能从整体上来思考一下，如何设计一个rpc框架，考考你的系统设计能力
+
+# 3 解决方案
+其实一般问到你这问题，你起码不能认怂，因为这既然是面试突击教程，那不可能给你深入讲解什么kafka源码剖析，dubbo源码剖析，何况就算讲了，你要真的消化理解和吸收，起码个把月以后了!
+
+所以我给大家一个建议，遇到这类问题，起码从你了解的类似框架的原理入手，自己说说参照Dubbo的原理，你来设计一下，举个例子，Dubbo不是有那么多分层么？而且每个分层是干啥的，你大概是不是知道？那就按照这个思路大致说一下吧，起码你不能懵逼，要比那些上来就懵，啥也说不出来的人要好一些
+
+给大家说个最简单的回答思路
+- 首先服务就得去注册中心注册吧，你是不是得有个注册中心，保留各个服务的信息，可以用zookeeper来做吧
+- 然后你的消费者需要去注册中心拿对应的服务信息吧,而且每个服务可能会存在于多台机器上
+- 接着你就该发起一次请求了，怎么发起请求？懵逼了吧,当然是基于动态代理了!
+你面向接口获取到一个动态代理，这个动态代理就是接口在本地的一个代理，然后这个代理会找到服务对应的机器地址
+- 然后找哪个机器发送请求？那肯定得有个负载均衡算法了，比如最简单的可以随机轮询是不是
+- 找到一台机器后，就可以跟它发送请求了
+	- 咋发送呢？
+	你可以说用netty了，nio方式
+	- 发送什么格式的数据？
+	你可以说用hessian序列化协议了，或者是别的，对吧。然后请求过去了
+- 服务器那边一样的，需要针对你自己的服务生成一个动态代理，监听某个网络端口，然后代理你本地的服务代码。接收到请求的时候，就调用对应的服务代码.
+
+这就是一个最最基本的RPC框架的思路，先不说你有多牛逼的技术功底，哪怕这个最简单的思路你先给出来行不行？好，突击教程，那就到这儿结束了，这教程定位是帮你快速梳理一遍，扫清盲点，不是打通你任督二脉，给你九阳神功的!
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(41)-ZooKeeper\347\232\204\351\200\202\347\224\250\345\234\272\346\231\257.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(41)-ZooKeeper\347\232\204\351\200\202\347\224\250\345\234\272\346\231\257.md"
new file mode 100644
index 0000000000..088cf119fb
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(41)-ZooKeeper\347\232\204\351\200\202\347\224\250\345\234\272\346\231\257.md"
@@ -0,0 +1,67 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+ZooKeeper的适用场景?
+
+# 2 考点分析
+
+现在聊的面试主题，是分布式系统，其实跟你聊完Dubbo以及相关的一些问题，确认你现在分布式服务框架，RPC框架，基本都有一些认知.
+
+下面,可能开始要跟你聊分布式相关的其他问题了.
+
+分布式锁这个东西，还是很常用的，做Java开发，分布式系统，可能会有一些场景会用到.
+
+最常用的分布式锁就是ZooKeeper来实现.
+
+这个问题，一般就是看看你是否了解ZK，因为ZK是分布式系统中的一个基础系统.
+
+问的话常问的就是说ZK的使用场景是什么？看你知道不知道一些基本的使用场景.
+
+但是其实ZK挖深了自然也是可以很深很深!
+
+# 3 ZooKeeper的适用场景
+
+## 3.1 分布式协调
+
+这是ZK很经典的一个用法
+
+- ZooKeeper的分布式协调场景图![](https://ask.qcloudimg.com/http-save/1752328/38j6wsemzh.png)
+
+如上图所示,系统A发送一个请求到MQ，然后系统B消费消息之后处理了。那系统A如何知道系统B的处理结果?
+
+用ZK就可实现分布式系统之间的协调工作!
+
+系统A发送请求之后可以在ZK上对某个节点的值注册监听器，一旦系统B处理完了就修改ZK那个节点的值，A立马就可以收到通知，完美解决~
+
+## 3.2 分布式锁
+
+- ZooKeeper的分布式锁场景图
+![](https://ask.qcloudimg.com/http-save/1752328/txasblc01j.png)
+对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但只能一台机器先执行另外一个后执行.
+那么此时就可以使用ZK分布式锁:
+- 一个机器接收到了请求之后先获取ZK上的锁，即可以去创建一个znode，接着执行操作
+- 然后另外一个机器也尝试去创建那个znode，结果发现自己创建不了，因为被别人创建了,那只能等着，等第一个机器执行完了自己再执行
+
+## 3.3 元数据/配置信息管理
+
+- ZooKeeper的元数据/配置管理场景
+![](https://ask.qcloudimg.com/http-save/1752328/2okg4rsg2r.png)
+ZK可以用作很多系统的配置信息的管理，比如Kafka、Storm等等很多分布式系统都会用ZK来做一些元数据、配置信息的管理，包括Dubbo注册中心
+
+## 3.4 HA高可用性
+
+- ZooKeeper的HA高可用性场景
+![](https://ask.qcloudimg.com/http-save/1752328/eeuv23gxte.png)
+这个应该是很常见的，比如hadoop、hdfs、yarn等很多大数据系统，都选择基于ZK来开发HA高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过ZK感知到切换到备用进程
+
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(42) - Redis & ZooKeeper\344\270\244\347\247\215\345\210\206\345\270\203\345\274\217\351\224\201\345\256\236\347\216\260\347\232\204\344\274\230\345\212\243.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(42) - Redis & ZooKeeper\344\270\244\347\247\215\345\210\206\345\270\203\345\274\217\351\224\201\345\256\236\347\216\260\347\232\204\344\274\230\345\212\243.md"
new file mode 100644
index 0000000000..210d3d6587
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(42) - Redis & ZooKeeper\344\270\244\347\247\215\345\210\206\345\270\203\345\274\217\351\224\201\345\256\236\347\216\260\347\232\204\344\274\230\345\212\243.md"	
@@ -0,0 +1,398 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+一般实现分布式锁都有哪些方式？使用redis如何设计分布式锁？使用zk来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
+
+# 2 考点分析
+
+一般先问问你zk，然后过渡到zk关联的一些问题，比如分布式锁.
+
+因为在分布式系统开发中，分布式锁的使用场景还是很常见的~
+
+# 3 Redis分布式锁
+
+官方叫做RedLock算法，是Redis官方支持的分布式锁算法.
+
+这个分布式锁有3个重要的考量点
+
+- 互斥（只能有一个客户端获取锁）
+- 不能死锁
+- 容错（大部分Redis节点或者这个锁就可以加可以释放）
+
+## 3.1 最普通的实现方式
+
+创建一个key
+
+```
+SET my:lock 随机值 NX PX 30000
+```
+
+- NX : 只有key不存在的时候才会设置成功
+- PX 30000 : 30秒后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了.
+
+释放锁就是删除key，但是一般可以用lua脚本删除，判断value一样才删除:
+
+> 关于redis如何执行lua脚本，自行百度
+
+```
+if redis.call("get",KEYS[1]) == ARGV[1] then
+return redis.call("del",KEYS[1])
+else
+    return 0
+end
+```
+
+为啥用随机值呢？
+
+因为如果某客户端获取锁，但阻塞了很长时间才执行完，此时可能已经超时释放锁了，可能别的客户端已经获取到了锁，要是此时你直接删除key会有问题，所以得用随机值加上面的lua脚本来释放锁.
+
+但是这样是肯定不行的
+
+- 如果是普通的Redis单实例，那就是单点故障
+- 是Redis普通主从，那Redis主从异步复制，如果主节点挂了，key还没同步到从节点，此时从节点切换为主节点，别人就会拿到锁.
+- Redis最普通的分布式锁的实现原理
+![](https://ask.qcloudimg.com/http-save/1752328/zxjzriw4ny.png)
+
+## 3.2 RedLock算法
+
+假设有一个redis cluster，有5个redis master实例.
+
+执行如下步骤获取锁：
+
+1. 获取当前时间戳(ms)
+2. 尝试轮流在每个master节点创建锁，过期时间较短(几十ms)
+3. 尝试在大多数节点建立一个锁，比如5个节点就要求是3个节点（n / 2 +1）
+4. 客户端计算建立锁的时间，如果建立锁的时间小于超时时间，即建立成功
+5. 如果锁建立失败，那么就依次删除这个锁
+6. 只要别人建立了一把分布式锁，就得不断轮询去尝试获取锁
+- RedLock算法![](https://ask.qcloudimg.com/http-save/1752328/2jcxo2yx5u.png)
+
+# 4 ZooKeeper分布式锁
+
+## 4.1 方案一
+
+可以做的比较简单，就是某个节点尝试创建znode，创建成功了就获取了这个锁
+
+这个时候别的客户端创建锁会失败，只能注册监听器监听这个锁
+
+释放锁就是删除这个znode，一旦释放掉就会通知客户端，然后有一个等待着的客户端就可以重新加锁。
+
+```
+/**
+ * ZooKeeperSession
+ * 
+ * @author JavaEdge
+ *
+ */
+public class ZooKeeperSession {
+	
+	private static CountDownLatch connectedSemaphore = new CountDownLatch(1);
+	
+	private ZooKeeper zookeeper;
+	private CountDownLatch latch;
+
+	public ZooKeeperSession() {
+		try {
+			this.zookeeper = new ZooKeeper(
+					"192.168.31.187:2181,
+					192.168.31.19:2181,
+					192.168.31.227:2181", 
+					50000, 
+					new ZooKeeperWatcher());			
+			try {
+				connectedSemaphore.await();
+			} catch(InterruptedException e) {
+				e.printStackTrace();
+			}
+			System.out.println("ZooKeeper session established......");
+		} catch (Exception e) {
+			e.printStackTrace();
+		}
+	}
+```
+
+```
+	/**
+	 * 获取分布式锁
+	 * @param productId
+	 */
+	public Boolean acquireDistributedLock(Long productId) {
+		String path = "/product-lock-" + productId;
+	
+		try {
+			zookeeper.create(path, "".getBytes(), 
+						  	 Ids.OPEN_ACL_UNSAFE, 
+						  	 CreateMode.EPHEMERAL);
+		 	return true;
+		} catch (Exception e) {
+			while(true) {
+				try {
+					// 相当于是给node注册一个监听器，去看看这个监听器是否存在
+					Stat stat = zk.exists(path, true); 
+					
+					if(stat != null) {
+						this.latch = new CountDownLatch(1);
+						this.latch.await(waitTime, TimeUnit.MILLISECONDS);
+						this.latch = null;
+					}
+					zookeeper.create(path, "".getBytes(), 
+									 Ids.OPEN_ACL_UNSAFE, 
+									 CreateMode.EPHEMERAL);
+					return true;
+					} catch(Exception e) {
+							continue;
+					}
+				}
+
+				// 很不优雅，我呢就是给大家来演示这么一个思路
+				// 比较通用的，我们公司里我们自己封装的基于zookeeper的分布式锁，我们基于zookeeper的临时顺序节点去实现的，比较优雅的
+			}
+			return true;
+	}
+```
+
+```
+	/**
+	 * 释放掉一个分布式锁
+	 * 
+	 * @param productId
+	 */
+	public void releaseDistributedLock(Long productId) {
+		String path = "/product-lock-" + productId;
+		try {
+			zookeeper.delete(path, -1); 
+			System.out.println("release the lock for product[id=" + productId + "]......");  
+		} catch (Exception e) {
+			e.printStackTrace();
+		}
+	}
+```
+
+```
+	/**
+	 * 建立zk session的watcher
+	 * 
+	 * @author JavaEdge
+	 *
+	 */
+	private class ZooKeeperWatcher implements Watcher {
+
+		public void process(WatchedEvent event) {
+			System.out.println("Receive watched event: " + event.getState());
+
+			if(KeeperState.SyncConnected == event.getState()) {
+				connectedSemaphore.countDown();
+			} 
+
+			if(this.latch != null) {  
+				this.latch.countDown();  
+			}
+		}
+	}
+```
+
+```
+	/**
+	 * 封装单例的静态内部类
+	 * 
+	 * @author JavaEdge
+	 *
+	 */
+	private static class Singleton {
+		
+		private static ZooKeeperSession instance;
+		
+		static {
+			instance = new ZooKeeperSession();
+		}
+		
+		public static ZooKeeperSession getInstance() {
+			return instance;
+		}
+		
+	}
+
+	/**
+	 * 获取单例
+	 * @return
+	 */
+	public static ZooKeeperSession getInstance() {
+		return Singleton.getInstance();
+	}
+	
+	/**
+	 * 初始化单例的便捷方法
+	 */
+	public static void init() {
+		getInstance();
+	}
+	
+}
+```
+
+## 4.2 方案二
+
+也可以采用另一种方式，创建临时顺序节点
+
+如果有一把锁，被多个人给竞争，此时多个人会排队，第一个拿到锁的人会执行，然后释放锁
+
+后面的每个人都会去监听排在自己前面的那个人创建的 node 上，一旦某个人释放了锁，排在自己后面的人就会被 zookeeper 给通知，一旦被通知了之后，就 ok 了，自己就获取到了锁，就可以执行代码了
+
+```
+public class ZooKeeperDistributedLock implements Watcher {
+
+    private ZooKeeper zk;
+    private String locksRoot = "/locks";
+    private String productId;
+    private String waitNode;
+    private String lockNode;
+    private CountDownLatch latch;
+    private CountDownLatch connectedLatch = new CountDownLatch(1);
+    private int sessionTimeout = 30000;
+
+    public ZooKeeperDistributedLock(String productId) {
+        this.productId = productId;
+        try {
+            String address = "192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181";
+            zk = new ZooKeeper(address, sessionTimeout, this);
+            connectedLatch.await();
+        } catch (IOException e) {
+            throw new LockException(e);
+        } catch (KeeperException e) {
+            throw new LockException(e);
+        } catch (InterruptedException e) {
+            throw new LockException(e);
+        }
+    }
+
+    public void process(WatchedEvent event) {
+        if (event.getState() == KeeperState.SyncConnected) {
+            connectedLatch.countDown();
+            return;
+        }
+
+        if (this.latch != null) {
+            this.latch.countDown();
+        }
+    }
+
+    public void acquireDistributedLock() {
+        try {
+            if (this.tryLock()) {
+                return;
+            } else {
+                waitForLock(waitNode, sessionTimeout);
+            }
+        } catch (KeeperException e) {
+            throw new LockException(e);
+        } catch (InterruptedException e) {
+            throw new LockException(e);
+        }
+    }
+
+    public boolean tryLock() {
+        try {
+ 		    // 传入进去的locksRoot + “/” + productId
+		    // 假设productId代表了一个商品id，比如说1
+		    // locksRoot = locks
+		    // /locks/10000000000，/locks/10000000001，/locks/10000000002
+            lockNode = zk.create(locksRoot + "/" + productId, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
+   
+            // 看看刚创建的节点是不是最小的节点
+	 	    // locks：10000000000，10000000001，10000000002
+            List<String> locks = zk.getChildren(locksRoot, false);
+            Collections.sort(locks);
+	
+            if(lockNode.equals(locksRoot+"/"+ locks.get(0))){
+                //如果是最小的节点,则表示取得锁
+                return true;
+            }
+	
+            //如果不是最小的节点，找到比自己小1的节点
+	  int previousLockIndex = -1;
+            for(int i = 0; i < locks.size(); i++) {
+		if(lockNode.equals(locksRoot + “/” + locks.get(i))) {
+	         	    previousLockIndex = i - 1;
+		    break;
+		}
+	   }
+	   
+	   this.waitNode = locks.get(previousLockIndex);
+        } catch (KeeperException e) {
+            throw new LockException(e);
+        } catch (InterruptedException e) {
+            throw new LockException(e);
+        }
+        return false;
+    }
+
+    private boolean waitForLock(String waitNode, long waitTime) throws InterruptedException, KeeperException {
+        Stat stat = zk.exists(locksRoot + "/" + waitNode, true);
+        if (stat != null) {
+            this.latch = new CountDownLatch(1);
+            this.latch.await(waitTime, TimeUnit.MILLISECONDS);
+            this.latch = null;
+        }
+        return true;
+    }
+
+    public void unlock() {
+        try {
+            // 删除/locks/10000000000节点
+            // 删除/locks/10000000001节点
+            System.out.println("unlock " + lockNode);
+            zk.delete(lockNode, -1);
+            lockNode = null;
+            zk.close();
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        } catch (KeeperException e) {
+            e.printStackTrace();
+        }
+    }
+
+    public class LockException extends RuntimeException {
+        private static final long serialVersionUID = 1L;
+
+        public LockException(String e) {
+            super(e);
+        }
+
+        public LockException(Exception e) {
+            super(e);
+        }
+    }
+}
+```
+
+- ZooKeeper的分布式锁原理
+
+![](https://ask.qcloudimg.com/http-save/1752328/00kqnkibdb.png)
+
+# 5 Redis & ZooKeeper分布式锁实现的对比
+- Redis分布式锁，需要自己不断去尝试获取锁，比较消耗性能
+- ZooKeeper分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小
+
+另外一点就是
+
+- 如果Redis获取锁的那个客户端挂了，那么只能等待超时时间之后才能释放锁
+- 而对于ZooKeeper，因为创建的是临时znode，只要客户端挂了，znode就没了，此时就自动释放锁
+
+Redis分布式锁大家没发现好麻烦吗？
+
+遍历上锁，计算时间等等
+
+ZooKeeper的分布式锁语义清晰实现简单
+
+所以先不分析太多的东西，就说这两点，个人实践认为ZooKeeper的分布式锁比Redis的分布式锁牢靠、而且模型简单易用
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(43)-\345\210\206\345\270\203\345\274\217Session\346\226\271\346\241\210\347\232\204\345\256\236\347\216\260.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(43)-\345\210\206\345\270\203\345\274\217Session\346\226\271\346\241\210\347\232\204\345\256\236\347\216\260.md"
new file mode 100644
index 0000000000..0b35b796f6
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(43)-\345\210\206\345\270\203\345\274\217Session\346\226\271\346\241\210\347\232\204\345\256\236\347\216\260.md"
@@ -0,0 +1,154 @@
+
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+集群部署时的分布式session如何实现？
+
+# 2 Session简介
+
+浏览器有个cookie，在一段时间内这个cookie都存在，然后每次发请求过来都带上一个特殊的jsessionid cookie，就根据这个东西，在服务端可以维护一个对应的session域，里面可以放点儿数据。
+
+一般只要你没关掉浏览器，cookie还在，那么对应的那个session就在，但是cookie没了，session就没了。常见于什么购物车之类的东西，还有登录状态保存之类的。
+
+你单块系统的时候这么玩儿session没问题啊，但是你要是分布式系统了呢，那么多的服务，session状态在哪儿维护啊？
+
+其实方法很多，但是常见常用的是两种：
+
+# 3 实现方案
+
+## 3.1  Tomcat + Redis
+
+这个其实还挺方便的，就是使用session的代码跟以前一样，还是基于Tomcat原生的session支持即可，然后就是用一个叫做Tomcat RedisSessionManager的东西，让所有我们部署的Tomcat都将session数据存储到redis即可。
+
+- Tomcat配置文件
+
+```
+<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
+
+<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
+         host="{redis.host}"
+         port="{redis.port}"
+         database="{redis.dbnum}"
+         maxInactiveInterval="60"/>
+```
+
+搞一个类似上面的配置即可，你看是不是就是用了RedisSessionManager，然后指定了redis的host和 port就ok了
+
+```
+<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
+<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
+	 sentinelMaster="mymaster"
+	 sentinels="<sentinel1-ip>:26379,<sentinel2-ip>:26379,<sentinel3-ip>:26379"
+	 maxInactiveInterval="60"/>
+```
+
+还可以用上面这种方式基于redis哨兵支持的redis高可用集群来保存session数据，都是ok的
+
+## 3.2 Spring Session + Redis
+
+分布式会话的这个东西重耦合在tomcat中，如果我要将web容器迁移成jetty，难道你重新把jetty都配置一遍吗？
+
+因为上面那种tomcat + redis的方式好用，但是会**严重依赖web容器**，不好将代码移植到其他web容器上去，尤其是你要是换了技术栈咋整？比如换成了spring cloud或者是spring boot.
+
+所以现在比较好的还是基于java一站式解决方案，spring!
+
+人家spring基本上包掉了大部分的我们需要使用的框架了，spirng cloud做微服务了，spring boot做脚手架了，所以用sping session是一个很好的选择
+
+- pom.xml
+
+```
+<dependency>
+  <groupId>org.springframework.session</groupId>
+  <artifactId>spring-session-data-redis</artifactId>
+  <version>1.2.1.RELEASE</version>
+</dependency>
+<dependency>
+  <groupId>redis.clients</groupId>
+  <artifactId>jedis</artifactId>
+  <version>2.8.1</version>
+</dependency>
+```
+
+- spring配置文件中
+
+```
+<bean id="redisHttpSessionConfiguration"
+     class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
+    <property name="maxInactiveIntervalInSeconds" value="600"/>
+</bean>
+
+<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
+    <property name="maxTotal" value="100" />
+    <property name="maxIdle" value="10" />
+</bean>
+
+<bean id="jedisConnectionFactory"
+      class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" destroy-method="destroy">
+    <property name="hostName" value="${redis_hostname}"/>
+    <property name="port" value="${redis_port}"/>
+    <property name="password" value="${redis_pwd}" />
+    <property name="timeout" value="3000"/>
+    <property name="usePool" value="true"/>
+    <property name="poolConfig" ref="jedisPoolConfig"/>
+</bean>
+```
+
+- web.xml
+
+```
+<filter>
+    <filter-name>springSessionRepositoryFilter</filter-name>
+    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
+</filter>
+<filter-mapping>
+    <filter-name>springSessionRepositoryFilter</filter-name>
+    <url-pattern>/*</url-pattern>
+</filter-mapping>
+```
+
+- 示例代码
+
+```
+@Controller
+@RequestMapping("/test")
+public class TestController {
+
+@RequestMapping("/putIntoSession")
+@ResponseBody
+    public String putIntoSession(HttpServletRequest request, String username){
+        request.getSession().setAttribute("name",  “leo”);
+
+        return "ok";
+    }
+
+@RequestMapping("/getFromSession")
+@ResponseBody
+    public String getFromSession(HttpServletRequest request, Model model){
+        String name = request.getSession().getAttribute("name");
+        return name;
+    }
+}
+```
+
+上面的代码就是ok的，给sping session配置基于redis来存储session数据，然后配置了一个spring session的过滤器，这样的话，session相关操作都会交给spring session来管了.
+
+接着在代码中，就用原生的session操作，就是直接基于spring sesion从redis中获取数据了。
+
+## 3.3 小结
+
+- 分布式会话是什么
+![](https://ask.qcloudimg.com/http-save/1752328/1buzfxvwvr.png)
+实现分布式的会话，有很多种很多种方式，这里说的不过是比较常见的两种方式
+tomcat + redis早期比较常用,但是会重耦合到 tomcat 中
+近些年，通过spring session来实现。
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(44)-\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241\350\247\243\345\206\263\346\226\271\346\241\210.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(44)-\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241\350\247\243\345\206\263\346\226\271\346\241\210.md"
new file mode 100644
index 0000000000..dd40c0d426
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(44)-\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241\350\247\243\345\206\263\346\226\271\346\241\210.md"
@@ -0,0 +1,198 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+分布式事务了解吗？你们如何解决分布式事务问题的？
+
+# 2 考点分析
+
+只要聊到做了分布式系统，必问分布式事务，若你对分布式事务一无所知的话，确实很坑，起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。
+
+现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配.
+
+你做系统肯定要用事务，那你用事务的话，分布式系统之后肯定要用分布式事务.
+
+先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如TCC方案的网络问题、XA方案的一致性问题
+
+- 单块系统里的事务
+![](https://ask.qcloudimg.com/http-save/1752328/r4xqf8kyj6.png)
+- 分布式系统里的事务
+![](https://ask.qcloudimg.com/http-save/1752328/aab7lgnhdq.png)
+
+# 3 XA方案也叫做两阶段提交事务方案.
+
+举个例子，比如公司经常团建，然后一般会有个主席（就是负责组织团建的那个人）。
+
+> tb，team building，团建
+
+- 第一个阶段，一般tb主席会提前问团队里的每个人，说，大家伙，下周六我们去滑雪+烧烤，去吗？
+		- 这个时候tb主席开始等待每个人的回答，如果所有人都说ok，那么就可以决定一起去这次tb
+		- 如果这个阶段里，任何一个人回答说，我有事不去了，那么tb主席就会取消这次活动
+- 第二个阶段，那下周六大家就一起去滑雪+烧烤了
+
+这就是所谓的XA事务，两阶段提交
+
+有一个事务管理器，负责协调多个数据库（资源管理器）的事务，事务管理器先问各个数据库你准备好了吗？
+
+- 如果每个数据库都回复ok，那么就正式提交事务，在各个数据库上执行操作
+- 任何一个数据库回答不ok，那么就回滚事务。
+
+这种分布式事务方案，比较适合单块应用中，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对**不适合高并发**场景
+
+如果要玩，那么基于Spring + JTA就可以搞定，自己随便搜个demo看看~
+
+这个方案，很少用，一般**某个系统内部如果出现跨多个库**的操作，是不合规的!
+
+现在的微服务，一个大的系统分成几十甚至上百个服务。一般来说，我们的规约，是要求每个服务只能操作自己对应的一个数据库!
+
+如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范
+
+你随便交叉访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，会经常数据被别人改错，自己的库被别人写挂!
+
+如果你要操作别人的服务的库，你必须通过**调用别的服务的接口**实现，绝对不允许你交叉访问别人的数据库！
+
+- 两阶段提交方案示意图
+![](https://ask.qcloudimg.com/http-save/1752328/zrjb53e0wh.png)
+
+# 4 TCC方案
+
+全称:Try、Confirm、Cancel
+
+## 4.1 三个阶段
+
+### 4.1.1 Try
+
+对各个服务的资源做检测,对资源进行锁定或者预留
+
+### 4.1.2 Confirm
+
+在各个服务中执行实际的操作
+
+### 4.1.3 Cancel
+
+如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，即执行已操作成功的业务逻辑的回滚操作
+
+## 4.2 跨银行转账案例
+
+涉及到两个银行的分布式事务，如果用TCC方案来实现，思路是这样的：
+
+- Try阶段
+先把两个银行账户中的资金给它冻结住,不让操作了
+- Confirm阶段
+执行实际的转账操作，A银行账户的资金扣减，B银行账户的资金增加
+- Cancel阶段
+如果任何一个银行的操作执行失败，那么就需要回滚进行补偿
+比如A银行账户如果已经扣减了，但是B银行账户资金增加失败了，那么就得把A银行账户资金给加回去
+
+该方案说实话几乎很少使用，但也有使用场景.
+
+因为这个事务的回滚实际上严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常恶心!
+
+比如说我们，一般来说和钱相关的支付、交易等相关的场景，我们会用TCC，严格严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性!
+
+## 4.3 适用场景
+
+除非你是真的一致性要求太高，是系统中核心之核心的场景!
+
+常见的就是资金类的场景，那可以用TCC方案，自己编写大量的业务逻辑，自己判断一个事务中的各个环节是否ok，不ok就执行补偿/回滚代码
+
+而且最好是你的各个业务执行的时间都比较短
+
+但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，业务代码也很难维护
+
+- TCC方案
+![](https://ask.qcloudimg.com/http-save/1752328/zxtt97e47h.png)
+
+# 5 本地消息表
+
+ebay搞出来的这么一套思想
+
+## 5.1 简介
+
+- A系统在本地一个事务里操作的同时，插入一条数据到消息表
+- 接着A系统将这个消息发送到MQ
+- B系统接收到消息后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息
+- B系统执行成功后，就会更新自己本地消息表的状态以及A系统消息表的状态
+- 如果B系统处理失败，那么就不会更新消息表状态，那么此时A系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到MQ中去，让B再处理
+
+## 5.2 优点
+
+这个方案保证了**最终一致性**
+
+哪怕B事务失败了，但是A会不断重发消息，直到B那边成功为止
+
+## 5.3 缺陷
+
+最大的问题就在于严重依赖于数据库的消息表来管理事务,这个会导致高并发场景无力,难以扩展呢,一般确实很少用
+
+- 本地消息表方案
+![](https://ask.qcloudimg.com/http-save/1752328/amebkemm0g.png)
+
+# 6 可靠消息最终一致性方案
+
+干脆不用本地的消息表了，直接基于MQ来实现事务。比如阿里的RocketMQ就支持消息事务!
+
+## 6.1 简介
+
+- A系统先发送一个prepared消息到MQ，如果这个prepared消息发送失败,那么就直接取消操作,不执行了
+- 如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉MQ发送确认消息，如果失败就告诉MQ回滚消息
+- 如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地的事务
+- MQ会自动定时轮询所有prepared消息回调你的接口，问你这个消息是不是本地事务处理失败了，所有没发送确认的消息,是继续重试还是回滚？
+这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，别确认消息发送失败了。
+- 如果系统B的事务失败了咋办？
+重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如B系统本地回滚后，想办法通知系统A也回滚；或者是发送报警由人工来手工回滚和补偿
+
+这个还是比较合适的，目前国内互联网公司大都是这么玩的，要不你举用RocketMQ支持的，要不你就自己基于类似ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的
+
+- 可靠消息最终一致性方案
+
+![](https://ask.qcloudimg.com/http-save/1752328/x2uch96yd4.png)
+
+# 7 最大努力通知方案
+
+## 7.1 简介
+
+- 系统A本地事务执行完后，发送一个消息到MQ
+- 有一专门消费MQ的最大努力通知服务，会消费MQ,然后写入数据库中记录下来，亦可是放入内存队列，接着调用系统B的接口
+- 若系统B执行成功就ok；若系统B执行失败，那么最大努力通知服务就定时尝试重新调用系统B，反复N次，最后还是不行才放弃
+- 最大努力通知方案示意图![](https://ask.qcloudimg.com/http-save/1752328/hx700mt14x.png)
+
+# 8 总结
+
+你们公司是如何处理分布式事务的呢?欢迎评论交流!
+
+讲真的，该突破面试教程没法带着大家实战，因为定位不是这个.
+
+如果你真的被问到，你可以这么说，我们某某特别严格的场景，用的是TCC来保证强一致性；然后其他的一些场景基于了阿里的RocketMQ来实现了分布式事务~
+
+你找一个严格资金要求绝对不能错的场景，你可以说你是用的TCC方案
+
+如果是一般的分布式事务场景，订单插入之后要调用库存服务更新库存，库存数据没有资金那么的敏感，可以用可靠消息最终一致性方案
+
+> Rocketmq 3.2.6之前的版本，是可以按照上面的思路来的，但是之后接口做了一些改变，不再赘述,欢迎关注后续笔者的RocketMQ实战系列
+
+当然如果你愿意，你可以参考可靠消息最终一致性方案来自己实现一套分布式事务，比如基于RabbitMQ来玩儿。
+
+你其实用任何一个分布式事务的这么一个方案，都会导致你那块儿代码会复杂10倍。很多情况下，系统A调用系统B、系统C、系统D，我们可能根本就不做分布式事务。如果调用报错会打印异常日志。
+
+每个月也就那么几个bug，很多bug是功能性的，体验性的，真的是涉及到数据层面的一些bug，一个月就几个，两三个？如果你为了确保系统自动保证数据100%不能错，上了几十个分布式事务，代码太复杂；性能太差，系统吞吐量、性能大幅度下跌。
+
+99%的分布式接口调用，不要做分布式事务，直接就是监控（发邮件、发短信）、记录日志（一旦出错，完整的日志）、事后快速的定位、排查和出解决方案、修复数据。
+
+每个月，每隔几个月，都会对少量的因为代码bug，导致出错的数据，进行人工的修复数据，自己临时动手写个程序，可能要补一些数据，可能要删除一些数据，可能要修改一些字段的值。
+
+比你做50个分布式事务，成本要来的低上百倍，低几十倍
+
+trade off，权衡，要用分布式事务的时候，一定是有成本，代码会很复杂，开发很长时间，性能和吞吐量下跌，系统更加复杂更加脆弱反而更加容易出bug；好处，如果做好了，TCC、可靠消息最终一致性方案，一定可以100%保证你那快数据不会出错。
+
+1%，0.1%，0.01%的业务，资金、交易、订单，我们会用分布式事务方案来保证，会员积分、优惠券、商品信息，其实不要这么搞了
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(45)-\351\253\230\345\271\266\345\217\221\347\263\273\347\273\237\347\232\204\346\236\266\346\236\204\350\256\276\350\256\241.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(45)-\351\253\230\345\271\266\345\217\221\347\263\273\347\273\237\347\232\204\346\236\266\346\236\204\350\256\276\350\256\241.md"
new file mode 100644
index 0000000000..fc2f17994e
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(45)-\351\253\230\345\271\266\345\217\221\347\263\273\347\273\237\347\232\204\346\236\266\346\236\204\350\256\276\350\256\241.md"
@@ -0,0 +1,110 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+如何设计一个高并发系统？
+
+# 2 考点分析
+
+问你这个题目,就必须要使出全身吃奶劲了。为啥？
+
+因为你没看到现在很多公司招聘的jd里都是说啥，**有高并发经验者优先**!
+
+所以如果你确实有真才实学，在互联网公司里干过高并发系统，那你确实拿offer基本如探囊取物，没啥问题。
+
+但是如果你要是真是干过高并发系统，面试官绝对绝对不会问这个问题，否则他就是蠢。
+
+假设你在某知名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期并发量上万，甚至是十万。那么人家一定会仔细盘问你的系统架构？怎么部署的？部署了多少台机器？缓存咋用的？MQ咋用的？数据库咋用的？就是深挖你到底是如何抗下高并发的。
+
+因为真正干过高并发的人一定知道，脱离了业务的系统架构都是在纸上谈兵，真正在复杂业务场景而且还高并发的时候，那系统架构一定不是那么简单的，用个redis，用mq就能搞定？
+
+当然不是，真实的系统架构搭配上业务之后，会比这种简单的所谓“高并发架构”要复杂很多倍。
+
+如果有面试官问你个问题说，如何设计一个高并发系统？
+
+那么不好意思，一定是因为你实际上没干过高并发系统。面试官看你简历就没啥出彩的，感觉就不咋地，所以就会问问你，如何设计一个高并发系统？其实说白了本质就是看看你有没有自己研究过，有没有一定的知识积累。
+
+最好的当然是招聘个真正干过高并发的哥儿们咯，但是这种人数稀缺，不好招。所以可能次一点的就是招一个自己研究过的哥儿们，总比招一个傻也不会的哥儿们好吧！
+
+所以这个时候你必须得做一把个人秀了，秀出你所有关于高并发的知识！
+
+# 3 高并发的意义
+
+其实所谓的高并发，如果你要理解这个问题呢，其实就得从高并发的根源出发，为啥会有高并发？为啥高并发就很牛逼？
+
+浅显一点，很简单，就是因为刚开始系统都是连接数据库的，但是要知道数据库支撑到每秒并发两三千的时候，基本就快完了。所以才有说，很多公司，刚开始干的时候，技术比较low，结果业务发展太快，有的时候系统扛不住压力就挂了。
+
+当然会挂了，凭什么不挂？你数据库如果瞬间承载每秒5000,8000，甚至上万的并发，一定会宕机，因为比如mysql就压根儿扛不住这么高的并发量。
+
+所以为啥高并发牛逼？就是因为现在用互联网的人越来越多，很多app、网站、系统承载的都是高并发请求，可能高峰期每秒并发量几千，很正常的。如果是什么双十一了之类的，每秒并发几万几十万都有可能。
+
+那么如此之高的并发量，加上原本就如此之复杂的业务，咋玩儿？真正厉害的，一定是在复杂业务系统里玩儿过高并发架构的人
+
+但是你没有，那么给你说一下该怎么回答这个问题
+
+- 高并发系统的架构组成
+![](https://ask.qcloudimg.com/http-save/1752328/m1sf9xv2ri.png)
+
+# 4 系统拆分
+
+将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以抗高并发么。
+
+# 5 缓存
+
+大部分高并发场景，都是**读多写少**，完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存.
+
+毕竟Redis轻轻松松单机几万的并发,所以你可以考虑考虑你的项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发
+
+# 6 消息队列
+
+可能你还是会出现高并发写的场景，比如一个业务操作里要频繁搞数据库几十次，增删改增删改疯了。那高并发绝对搞挂你的系统，你要是用Redis来承载写那肯定不行，人家是缓存，数据随时就被LRU了，数据格式还无比简单，没有事务支持
+
+所以该用MySQL还得用MySQL。那你咋办？
+
+用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在MySQL承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的
+
+# 7 分库分表
+
+可能到了最后数据库层面还是免不了抗高并发的要求
+
+那么就将一个数据库拆分为多个库，多个库来抗更高的并发
+
+然后将一个表拆分为多个表，每个表的数据量保持少一点，提高SQL跑的性能。
+
+# 8 读写分离
+
+大部分时候数据库可能也是读多写少，就没必要所有请求都集中在一个库，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库
+
+# 9 Elasticsearch
+
+ES是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来抗更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用ES承载，还有一些全文搜索类的操作，也可以考虑用ES
+
+# 10 总结
+
+上面及点，基本就是高并发系统肯定要干的一些事儿，大家可以仔细结合之前讲过的知识考虑一下，到时候你可以系统的把这块阐述一下，然后每个部分要注意哪些问题，之前都讲过了，你都可以阐述阐述，表明你对这块是有点积累的。
+
+说句实话，毕竟真正你厉害的一点，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样？
+
+其实实际上在真正的复杂的业务系统里，做高并发要远远比我这个图复杂几十倍到上百倍。
+
+你需要考虑，哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何join，哪些数据要放到缓存里去啊，放哪些数据再可以抗掉高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是务必复杂的，一旦做过一次，一旦做好了，你在这个市场上就会非常的吃香。
+
+其实大部分公司，真正看重的，不是说你掌握高并发相关的一些基本的架构知识，架构中的一些技术，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块，次一等的人才。
+
+对一个有几十万行代码的复杂的分布式系统，一步一步架构、设计以及实践过高并发架构的人，这个经验是难能可贵的!
+
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
+
+
+
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(46)-\345\210\206\345\272\223\345\210\206\350\241\250.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(46)-\345\210\206\345\272\223\345\210\206\350\241\250.md"
new file mode 100644
index 0000000000..2b17a2b937
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(46)-\345\210\206\345\272\223\345\210\206\350\241\250.md"
@@ -0,0 +1,171 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？
+
+# 2 分析
+
+其实这块肯定是扯到高并发了，因为分库分表一定是为了支撑高并发、数据量大两个问题的。而且现在说实话，尤其是互联网类的公司面试，基本上都会来这么一下，分库分表如此普遍的技术问题，不问实在是不行，而如果你不知道那也实在是说不过去！
+
+# 3 业务分析
+
+说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。我先给大家抛出来一个场景。
+
+业务发展迅猛，注册用户数达到了2000万！每天活跃用户数100万！每天单表数据量10万条！高峰期每秒最大请求达到1000！感觉压力已经有点大了，为啥呢？因为每天多10万条数据，一个月就多300万条数据，现在咱们单表已经几百万数据了，马上就破千万了。但是勉强还能撑着。高峰期请求现在是1000，咱们线上部署了几台机器，负载均衡搞了一下，数据库撑1000 QPS也还凑合。但是大家现在开始感觉有点担心了，接下来咋整呢。。。。。。
+
+此时每天活跃用户数上千万，每天单表新增数据多达50万，目前一个表总数据量都已经达到了两三千万了！扛不住啊！数据库磁盘容量不断消耗掉！高峰期并发达到惊人的5000~8000！别开玩笑了，哥。我跟你保证，你的系统支撑不到现在，已经挂掉了！
+
+看到你这里你差不多就理解分库分表是怎么回事儿了，实际上这是跟着公司业务发展走的，你公司业务发展越好，用户就越多，数据量越大，请求量越大，那你单个数据库一定扛不住。
+
+比如你单表都几千万数据了，你确定你能抗住么？
+
+绝对不行，单表数据量太大，会极大影响你的sql执行的性能，到了后面你的sql可能就跑的很慢了。一般来说，以经验来看，单表到几百万的时候，性能就会相对差一些了，你就得分表了。
+
+# 4 分表
+
+把一个表的数据放到多个表中，然后查询的时候你就查一个表
+
+比如按照用户id来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在200万以内。
+
+# 5 分库
+
+一个库一般我们经验而言，最多支撑到并发2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒1000左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
+
+这就是所谓的分库分表，为啥要分库分表？你明白了吧
+
+- 分库分表的由来
+![](https://ask.qcloudimg.com/http-save/1752328/3ahrs1ykbb.png)
+
+# 6 分库分表中间件
+
+不同的分库分表中间件都有什么优点和缺点？
+
+比较常见的包括：cobar、TDDL、atlas、sharding-jdbc、mycat
+
+## 6.1 cobar
+
+阿里b2b团队开发和开源的，属于proxy层方案
+
+早些年还可以用，但是最近几年都没更新了
+
+- [Github地址](https://github.com/alibaba/cobar/)
+![](https://ask.qcloudimg.com/http-save/1752328/j4b15539gb.png)
+
+基本没啥人用了，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库join和分页等操作。
+
+## 6.2 TDDL
+
+淘宝团队开发的，属于client层方案
+
+- [Github地址](https://github.com/alibaba/tb_tddl)
+![](https://ask.qcloudimg.com/http-save/1752328/eeff579hve.png)
+
+不支持join、多表查询等语法，就是基本的crud语法是ok，但是支持读写分离。
+
+目前使用的也不多，因为还依赖淘宝的diamond配置管理系统,而且已被商用,不再开源
+
+## 6.3 atlas
+
+- [Github地址](https://github.com/Qihoo360/Atlas)
+
+![](https://ask.qcloudimg.com/http-save/1752328/j6lef79flu.png)
+
+360开源的，属于proxy层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在6年前了。所以，现在用的公司基本也很少了。
+
+## 6.4 sharding-jdbc
+
+- [Github地址](https://github.com/apache/incubator-shardingsphere)
+![](https://ask.qcloudimg.com/http-save/1752328/amelo94p01.png)
+
+当初由当当开源的，属于client层方案。确实之前用的还比较多一些，因为SQL语法支持也比较多，没有太多限制，而且目前推出到了2.0版本，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从2017年一直到现在，是不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，算是一个现在也可以选择的方案。现在已经升级为Apache组织的项目
+
+sharding-jdbc这种client层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖；
+
+## 6.5 mycat
+
+- [Github地址](https://github.com/MyCATApache/Mycat-Server)
+![](https://ask.qcloudimg.com/http-save/1752328/afi2b4q0kj.png)
+
+基于cobar改造的，属于proxy层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于sharding jdbc来说，年轻一些，经历的锤炼少一些。
+
+mycat这种proxy层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。
+
+## 6.6  小结
+
+所以综上所述，现在其实建议考量的，就是sharding-jdbc和mycat，这两个都可以去考虑使用。
+
+通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；
+
+但是中大型公司最好还是选用mycat这类proxy层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护mycat，然后大量项目直接透明使用即可。
+
+# 7 数据库的垂直拆分或水平拆分
+
+- 数据库如何拆分
+![](https://ask.qcloudimg.com/http-save/1752328/5z5jzmc30t.png)
+
+## 7.1 水平拆分
+
+把一个表的数据给弄到多个库的多个表里，但每个库的表结构都一样，只不过每个库中表放的数据是不同的，所有库表的数据加起来就是全部数据
+
+### 水平拆分的意义
+
+将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。
+
+## 7.2 垂直拆分
+
+把一个有很多字段的表给拆分成多个表，或者是多个库
+
+每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去
+
+因为数据库是有缓存的，访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。
+
+这个其实挺常见的，很多同学可能自己都做过，把一个大表拆开，订单表、订单支付表、订单商品表。
+
+还有表层面的拆分，就是分表，将一个表变成N个表，就是让每个表的数据量控制在一定范围内，保证SQL的性能
+
+否则单表数据量越大，SQL性能就越差。一般是200万行左右，不要太多，但是也得看具体你怎么操作，也可能是500万，或者是100万。你的SQL越复杂，就最好让单表行数越少
+
+无论是分库还是分表，上面说的那些数据库中间件都是可以支持的。就是基本上那些中间件可以做到你分库分表之后，中间件可以根据你指定的某个字段值，比如说userid，自动路由到对应的库上去，然后再自动路由到对应的表里去。
+
+你就得考虑一下，你的项目里该如何分库分表？一般来说
+
+- 垂直拆分，你可以在表层面来做，对一些字段特别多的表做一下拆分
+- 水平拆分，你可以说是并发承载不了，或者是数据量太大，容量承载不了，你给拆了，按什么字段来拆，你自己想好
+- 分表，你考虑一下，你如果哪怕是拆到每个库里去，并发和容量都ok了，但是每个库的表还是太大了，那么你就分表，将这个表分开，保证每个表的数据量并不是很大
+
+# 8  **分库分表**的方式
+
+## 8.1 按照range分
+
+就是每个库一段连续的数据，一般按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了
+
+### 好处
+
+后面扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了
+
+### 缺点
+
+但是大部分的请求，都是访问最新的数据。实际生产用range，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据
+
+## 8.2 按照某个字段hash
+
+一下均匀分散，较为常用。
+
+### 好处
+
+可以平均分配没给库的数据量和请求压力
+
+### 坏处
+
+扩容起来比较麻烦，会有一个数据迁移的过程
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(47)-\345\210\206\345\272\223\345\210\206\350\241\250\347\232\204\345\256\236\350\267\265.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(47)-\345\210\206\345\272\223\345\210\206\350\241\250\347\232\204\345\256\236\350\267\265.md"
new file mode 100644
index 0000000000..29b1a29d8b
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(47)-\345\210\206\345\272\223\345\210\206\350\241\250\347\232\204\345\256\236\350\267\265.md"
@@ -0,0 +1,71 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？
+
+# 2 考点分析
+
+你现在已经明白为啥要分库分表了，你也知道常用的分库分表中间件了，你也设计好你们如何分库分表的方案了（水平拆分、垂直拆分、分表），那问题来了，你接下来该怎么把你那个单库单表的系统给迁移到分库分表上去？
+
+所以这都是一环扣一环的，就是看你有没有全流程经历过这个过程
+
+> 假设，你现有一个单库单表系统在线上跑
+> 单表有600万数据,3个库,每个库里分了4个表,每个表要放50万的数据量
+> 假设你已经选择了一个分库分表的数据库中间件，sharding-jdbc/mycat，都可以
+
+你怎么把线上系统平滑地迁移到分库分表上面去
+
+sharding-jdbc：自己上官网，找一个官网最基本的例子，自己写一下，试一下，跑跑看，是非常简单的
+
+mycat：自己上官网，找一个官网最基本的例子，自己写一下，试一下看看1个小时以内就可以搞定了
+
+# 3 解决方案
+
+这个其实从low到高大上有好几种方案，我们都玩儿过，我都给你说一下
+
+## 3.1 停机迁移方案
+
+最low的方案，就是很简单，大家伙儿凌晨12点开始运维，网站或者app挂个公告，说0点到早上6点进行运维，无法访问~
+
+接着到0点，停机，系统停掉，没有流量写入了，此时老的单库单表数据库静止了
+
+然后你之前得写好一个导数据的一次性工具，此时直接跑起来，然后将单库单表的数据哗读出来，写到分库分表里
+
+导数完后，就ok了，修改系统的数据库连接配置啥的，包括可能代码和SQL也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。
+
+验证一下，ok了，完美，大家伸个懒腰，看看看凌晨4点钟的北京夜景，打个滴滴回家吧
+
+- 长时间停机分库分表
+![](https://ask.qcloudimg.com/http-save/1752328/6d2kairty4.png)
+
+但是这个方案比较low，谁都能干，我们来看看高大上一点的方案
+
+## 3.2 双写迁移方案
+
+常用的一种迁移方案，比较靠谱，不用停机，不用看凌晨4点的风景
+
+就是在线上系统，之前所有写库的地方，增删改操作，**除了对旧库增删改，都加上对新库的增删改**，这就是所谓**双写** --- 同时写俩库(旧库和新库)
+
+然后系统部署后，新库数据差太远，用之前说的导数工具，跑起来读旧库数据写新库，写的时候要根据`gmt_modified`这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库没有，或者是比新库的数据新才会写,即不允许用旧数据覆盖新数据!
+
+接着导完一轮后，有可能数据还是不一致，那么就程序自动做一轮校验
+
+对比新旧库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从旧库读数据再次写。
+
+反复循环，直到两个库每个表的数据都完全一致为止。
+
+接着当数据完全一致了，就ok了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么，还没有几个小时的停机时间，很稳。所以现在基本玩数据迁移之类的，都是这么干了。
+
+- 不停机双写方案
+![](https://ask.qcloudimg.com/http-save/1752328/8lt8bqddaz.png)
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(48)-\350\256\276\350\256\241\345\217\257\345\212\250\346\200\201\346\211\251\345\256\271\347\274\251\347\232\204\345\210\206\345\272\223\345\210\206\350\241\250.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(48)-\350\256\276\350\256\241\345\217\257\345\212\250\346\200\201\346\211\251\345\256\271\347\274\251\347\232\204\345\210\206\345\272\223\345\210\206\350\241\250.md"
new file mode 100644
index 0000000000..b3fc19c191
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(48)-\350\256\276\350\256\241\345\217\257\345\212\250\346\200\201\346\211\251\345\256\271\347\274\251\347\232\204\345\210\206\345\272\223\345\210\206\350\241\250.md"
@@ -0,0 +1,108 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+设计可动态扩容的分库分表
+
+# 2 考点分析
+
+- 选一个数据库中间件,然后深入之
+- 设计分库分表的方案，要分成多少个库，每个库分成多少个表
+- 基于已选的数据库中间件，以及在测试环境建立好的分库分表，👀能否正常执行分库分表的读写
+- 完成单库单表到分库分表的迁移(使用上一文提到的双写方案)
+- 线上系统,开始基于分库分表对外服务
+
+突然! 扩容了，扩容成6个库，每个库需要12个表，你怎么来增加更多库和表呢？
+
+这个你必须面对的事，就是当你已经弄好分库分表方案，测试也通过了，数据能均匀分布到各个库和表里去，而且接着你还通过双写方案上了系统，已经直接基于分库分表方案在搞了。
+
+需求来了~现在这些库和表又支撑不住了，要继续扩容,咋办？
+
+这个可能就是每个库的容量又快满了，或者表数据量又太大了，也可能每个库的写并发太高了，得继续扩容!
+
+# 3 停机扩容(不推荐)
+
+这就跟停机迁移一样，步骤几乎一致，唯一不同是导数的工具，是把现有库表的数据抽出来慢慢导入到新的库和表里去。但是最好别这样，有点不太靠谱，既然分库分表,就说明数据量实在太大了,你这么玩，可能会出问题!
+
+从单库单表迁移到分库分表时，数据量并不是很大，单表最大也就两三千万
+
+写个工具，多弄几台机器并行跑，1小时数据就导完了
+
+但如果是:3个库+12个表
+
+跑了一段时间了，数据量都1亿~2亿了
+
+光是导2亿数据，都要导个几个小时，6点，刚刚导完数据，还要搞后续的修改配置，重启系统，测试验证，10点才可以搞完!
+
+# 4 优化方案
+
+一开始上来就是32个库，每个库32个表，1024张表
+
+这个分法
+
+- 基本上国内的互联网肯定都够用
+- 无论并发支撑还是数据量支撑都没问题
+
+每个库正常承载的写入并发量是1000，那么32个库就可以承载`32 * 1000 = 32000`的写并发
+
+如果每个库承载1500的写并发，`32 * 1500 = 48000`的写并发，接近5万/s的写入并发
+
+前面再加个MQ，削峰，每秒写入MQ 8万条数据，每秒消费5万条数据
+
+1024张表，假设每个表放500万数据，在MySQL里可以放50亿条数据
+
+每秒的5万写并发，总共50亿条数据，对于国内大部分互联网公司来说都够了
+
+谈分库分表的扩容，**第一次分库分表，就一次性给他分个够**
+
+32个库，1024张表，对大部分的中小型互联网公司来说，已经可以支撑好几年
+
+一个实践是利用`32 * 32`来分库分表，即分为32个库，每个库里一个表分为32张表,一共就是1024张表
+
+根据某个id先根据32取模路由到库，再根据32取模路由到库里的表。
+
+刚开始的时候，这个库可能就是逻辑库，建在一个数据库上的
+
+也就是一个MySQL服务器可能建了n个库,后面如果要拆分，就不断在库和MySQL服务器之间做迁移就可以了。然后系统配合改一下配置即可。
+
+比如说最多可以扩展到32个数据库服务器，每个数据库服务器是一个库。如果还是不够？
+
+最多可以扩展到1024个数据库服务器，每个数据库服务器上面一个库一个表。因为最多是1024个表
+
+这么搞，是不用自己写代码做数据迁移的，都交给DBA来搞好了，但是DBA确实需要做一些库表迁移的工作，总比你自己写代码，抽数据导数据来的效率高得多
+
+哪怕是要减少库的数量，也很简单，按倍数缩容就可以了，然后修改一下路由规则。
+
+![](https://ask.qcloudimg.com/http-save/1752328/rprqxeb7cn.png)
+
+# 5 总结
+
+## 5.1 确定方案
+
+几台数据库服务器,每台服务器上几个库，每个库多少个表，推荐是`32库 * 32表`，对于大部分公司来说，可能几年都够了
+
+## 5.2 路由规则
+
+orderId 模 32 = 库，orderId / 32 模 32 = 表
+
+## 5.3 扩容
+
+当扩容时,申请增加更多的数据库服务器，装好MySQL，倍数扩容，4台服务器，扩到8台服务器，16台服务器
+
+## 5.4 迁移
+
+由DBA负责将原先数据库服务器的库，迁移到新的数据库服务器上去，很多工具，库迁移，比较便捷
+
+## 5.5 配置
+
+我们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址
+
+## 5.6 发布
+
+重新发布系统，上线，原先的路由规则变都不用变，直接可以基于2倍的数据库服务器的资源，继续进行线上系统的提供服务
+
+- 分库分表扩容方案![](https://ask.qcloudimg.com/http-save/1752328/88hu11t4xh.png)
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(49)-\345\210\206\345\272\223\345\210\206\350\241\250\344\271\213\345\220\216\345\205\250\345\261\200id\347\232\204\347\224\237\346\210\220.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(49)-\345\210\206\345\272\223\345\210\206\350\241\250\344\271\213\345\220\216\345\205\250\345\261\200id\347\232\204\347\224\237\346\210\220.md"
new file mode 100644
index 0000000000..fb9c302d12
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(49)-\345\210\206\345\272\223\345\210\206\350\241\250\344\271\213\345\220\216\345\205\250\345\261\200id\347\232\204\347\224\237\346\210\220.md"
@@ -0,0 +1,278 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+分库分表之后，id主键如何处理？
+
+# 2 考点分析
+
+其实这是分库分表之后你必然要面对的一个问题，就是id咋生成？
+
+要是分成多个表之后，每个表都是从1开始累加，那肯定不对啊，需要一个全局唯一的id来支持!
+
+下面来看看有哪些可行方案~
+
+# 3 数据库自增id
+
+- 分库分表的id主键问题![](https://ask.qcloudimg.com/http-save/1752328/h45iw1bto5.png)
+
+系统每次得到一个id，都是
+
+- 往一个库的一个表里插入一条没什么业务含义的数据
+- 然后获取一个数据库自增id
+- 拿到该id后,再写入对应的分库分表中
+
+## 3.1 优点
+
+就是方便简单，谁都会用
+
+## 3.2 缺点
+
+就是单库生成自增id，要是高并发的话，就会有瓶颈
+
+如果你硬是要改进，那就专门开一个服务
+
+- 该服务每次就拿到当前id最大值
+- 然后自己递增几个id，一次性返回一批id
+- 然后再把当前最大id值修改成递增几个id之后的一个值
+
+但是无论怎么说都是基于单个数据库的!
+
+## 3.3 适用场景
+
+分库分表就俩原因
+
+- 要不就是单库并发太高
+- 要不就是单库数据量太大
+
+除非是你并发不高，但是数据量太大导致的分库分表扩容，你可以用这个方案，因为可能每秒最高并发最多就几百，那么就走单独的一个库和表生成自增主键即可。
+
+并发很低，几百/s，但是数据量大，几十亿的数据，所以需要靠分库分表来存放海量的数据
+
+# 4 UUID
+
+## 4.1 优点
+
+就是本地生成，不要基于数据库
+
+## 4.2 缺点
+
+- UUID太长了，作为主键性能太差，不适合用于主键
+- UUID 不具有有序性，会导致 B+ 树索引在写的时候有过多的随机写操作（连续的 ID 可以产生部分顺序写）
+- 写的时候不能产生有顺序的 append 操作，而需要进行 insert 操作，将会读取整个 B+ 树节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显
+
+## 4.3 适用场景
+
+如果你是要随机生成个什么文件名，编号之类的，你可以用UUID，但是作为主键是不能用UUID
+
+```
+UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf
+```
+
+# 5 获取系统当前时间
+
+获取当前时间即可，但问题是，并发很高的时候，比如一s并发几千，**会有重复**的情况，这个是肯定不合适的。基本就不用考虑了。
+
+## 5.1 适用场景
+
+一般如果用这个方案，是将当前时间跟很多其他的业务字段拼接起来，作为一个id
+
+如果业务上你觉得可以接受，那么也是可以的
+
+你可以将别的业务字段值跟当前时间拼接起来，组成一个全局唯一的编号
+
+比如订单编号
+
+`时间戳 + 用户id + 业务含义编码`
+
+# 6  snowflake算法
+
+![](https://ask.qcloudimg.com/http-save/1752328/22zqeagtrv.png)
+
+twitter开源的分布式id生成算法，把一个64位的long型的id，1个bit是不用的，用其中的41 bit作为毫秒数，用10 bit作为工作机器id，12 bit作为序列号
+
+- 1 bit：不用
+因为二进制里第一个bit为如果是1，那么都是负数，但是我们生成的id都是正数，所以第一个bit统一都是0
+- 41 bit：表示的是时间戳，单位是ms
+41 bit可以表示的数字多达2^41 - 1，也就是可以标识2 ^ 41 - 1个毫秒值，换算成年就是表示69年的时间
+- 10 bit：记录工作机器id
+代表的是这个服务最多可以部署在2^10台机器上哪，也就是1024台机器
+但是10 bit里5个bit代表机房id，5个bit代表机器id。意思就是最多代表2 ^ 5个机房（32个机房），每个机房里可以代表2 ^ 5个机器（32台机器）。
+- 12 bit：记录同一个毫秒内产生的不同id
+12 bit可以代表的最大正整数是2 ^ 12 - 1 = 4096
+也就是说可以用这个12bit代表的数字来区分同一个毫秒内的4096个不同的id
+
+64位的long型的id，64位的long -> 二进制
+
+```
+0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000
+```
+
+2018-01-01 10:00:00 -> 做了一些计算，再换算成一个二进制，41bit来放 -> 
+
+```
+0001100 10100010 10111110 10001001 01011100 00
+```
+
+机房id，17 -> 换算成一个二进制 ->
+
+```
+10001
+```
+
+机器id，25 -> 换算成一个二进制 -> 
+
+```
+11001
+```
+
+snowflake算法服务，会判断一下，当前这个请求是否是，机房17的机器25，在2175/11/7 12:12:14时间点发送过来的第一个请求，如果是第一个请求
+
+假设，在2175/11/7 12:12:14时间里，机房17的机器25，发送了第二条消息，snowflake算法服务，会发现说机房17的机器25，在2175/11/7 12:12:14时间里，在这一毫秒，之前已经生成过一个id了，此时如果你同一个机房，同一个机器，在同一个毫秒内，再次要求生成一个id，此时我只能把加1
+
+```
+0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000001
+```
+
+比如我们来观察上面的那个，就是一个典型的二进制的64位的id，换算成10进制就是910499571847892992。
+
+```
+public class IdWorker {
+
+    private long workerId;
+    private long datacenterId;
+    private long sequence;
+
+    public IdWorker(long workerId, long datacenterId, long sequence) {
+        // sanity check for workerId
+        // 这儿不就检查了一下，要求就是你传递进来的机房id和机器id不能超过32，不能小于0
+        if (workerId > maxWorkerId || workerId < 0) {
+            throw new IllegalArgumentException(
+                    String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
+        }
+        if (datacenterId > maxDatacenterId || datacenterId < 0) {
+            throw new IllegalArgumentException(
+                    String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
+        }
+        System.out.printf(
+                "worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
+                timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);
+
+        this.workerId = workerId;
+        this.datacenterId = datacenterId;
+        this.sequence = sequence;
+    }
+
+    private long twepoch = 1288834974657L;
+
+    private long workerIdBits = 5L;
+    private long datacenterIdBits = 5L;
+
+    // 这个是二进制运算，就是 5 bit最多只能有31个数字，也就是说机器id最多只能是32以内
+    private long maxWorkerId = -1L ^ (-1L << workerIdBits);
+
+    // 这个是一个意思，就是 5 bit最多只能有31个数字，机房id最多只能是32以内
+    private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
+    private long sequenceBits = 12L;
+
+    private long workerIdShift = sequenceBits;
+    private long datacenterIdShift = sequenceBits + workerIdBits;
+    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
+    private long sequenceMask = -1L ^ (-1L << sequenceBits);
+
+    private long lastTimestamp = -1L;
+
+    public long getWorkerId() {
+        return workerId;
+    }
+
+    public long getDatacenterId() {
+        return datacenterId;
+    }
+
+    public long getTimestamp() {
+        return System.currentTimeMillis();
+    }
+
+    public synchronized long nextId() {
+        // 这儿就是获取当前时间戳，单位是毫秒
+        long timestamp = timeGen();
+
+        if (timestamp < lastTimestamp) {
+            System.err.printf("clock is moving backwards.  Rejecting requests until %d.", lastTimestamp);
+            throw new RuntimeException(String.format(
+                    "Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
+        }
+
+        if (lastTimestamp == timestamp) {
+            // 这个意思是说一个毫秒内最多只能有4096个数字
+            // 无论你传递多少进来，这个位运算保证始终就是在4096这个范围内，避免你自己传递个sequence超过了4096这个范围
+            sequence = (sequence + 1) & sequenceMask;
+            if (sequence == 0) {
+                timestamp = tilNextMillis(lastTimestamp);
+            }
+        } else {
+            sequence = 0;
+        }
+
+        // 这儿记录一下最近一次生成id的时间戳，单位是毫秒
+        lastTimestamp = timestamp;
+
+        // 这儿就是将时间戳左移，放到 41 bit那儿；
+        // 将机房 id左移放到 5 bit那儿；
+        // 将机器id左移放到5 bit那儿；将序号放最后12 bit；
+        // 最后拼接起来成一个 64 bit的二进制数字，转换成 10 进制就是个 long 型
+        return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift)
+                | (workerId << workerIdShift) | sequence;
+    }
+
+    private long tilNextMillis(long lastTimestamp) {
+        long timestamp = timeGen();
+        while (timestamp <= lastTimestamp) {
+            timestamp = timeGen();
+        }
+        return timestamp;
+    }
+
+    private long timeGen() {
+        return System.currentTimeMillis();
+    }
+
+    // ---------------测试---------------
+    public static void main(String[] args) {
+        IdWorker worker = new IdWorker(1, 1, 1);
+        for (int i = 0; i < 30; i++) {
+            System.out.println(worker.nextId());
+        }
+    }
+
+}
+```
+
+- 41 bit，就是当前毫秒单位的一个时间戳
+- 然后5 bit是你传递进来的一个机房id（但是最大只能是32以内）
+- 5 bit是你传递进来的机器id（但是最大只能是32以内）
+- 剩下的那个10 bit序列号，就是如果跟你上次生成id的时间还在一个毫秒内，那么会把顺序给你累加，最多在4096个序号以内
+
+所以你自己利用这个工具类，自己搞一个服务，然后对每个机房的每个机器都初始化这么一个东西，刚开始这个机房的这个机器的序号就是0
+
+然后每次接收到一个请求，说这个机房的这个机器要生成一个id，你就找到对应的Worker，生成。
+
+这个算法生成的时候，会把当前毫秒放到41 bit中，然后5 bit是机房id，5 bit是机器id，接着就是判断上一次生成id的时间如果跟这次不一样，序号就自动从0开始；要是上次的时间跟现在还是在一个毫秒内，他就把seq累加1，就是自动生成一个毫秒的不同的序号。
+
+该算法可以确保每个机房每个机器每一毫秒，最多生成4096个不重复的id
+
+利用这个snowflake算法，你可以开发自己公司的服务，甚至对于机房id和机器id，反正给你预留了5 bit + 5 bit，你换成别的有业务含义的东西也可以的。
+
+这个snowflake算法相对来说还是比较靠谱的，所以你要真是搞分布式id生成，如果是高并发啥的，那么用这个应该性能比较好，一般每秒几万并发的场景，也足够你用了。
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(50)-MySQL\350\257\273\345\206\231\345\210\206\347\246\273\345\217\212\344\270\273\344\273\216\345\220\214\346\255\245\345\273\266\346\227\266\350\247\243\345\206\263\346\226\271\346\241\210.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(50)-MySQL\350\257\273\345\206\231\345\210\206\347\246\273\345\217\212\344\270\273\344\273\216\345\220\214\346\255\245\345\273\266\346\227\266\350\247\243\345\206\263\346\226\271\346\241\210.md"
new file mode 100644
index 0000000000..691ca00d8a
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(50)-MySQL\350\257\273\345\206\231\345\210\206\347\246\273\345\217\212\344\270\273\344\273\216\345\220\214\346\255\245\345\273\266\346\227\266\350\247\243\345\206\263\346\226\271\346\241\210.md"
@@ -0,0 +1,104 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+- 有没有做过MySQL读写分离
+- 如何实现MySQL的读写分离
+- 主从复制原理
+- 如何解决MySQL主从同步的延时问题
+
+准备好面对这炮轰式面试了吗?
+
+# 2 考点分析
+
+高并发阶段,肯定需要做读写分离.
+
+实际上大部分互联网公司/网站/APP,都是读多写少
+
+针对现状,写一个主库,挂着多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗？
+
+# 3 MySQL读写分离的实现
+
+基于主从复制架构
+
+搞一个主库,挂多个从库,然后就单单只是写主库,接着主库会自动将数据同步到从库
+
+# 4 MySQL主从复制的原理
+
+- 为什么MySQL要读写分离？
+![](https://ask.qcloudimg.com/http-save/1752328/zwf1tjdbw9.png)
+
+主库将变更写binlog日志，然后从库连接到主库后，从库有一个I/O线程，将主库的binlog日志拷贝到本地，写入一个中继日志
+
+接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容
+
+即在本地再次执行一遍SQL，确保跟主库的数据相同
+
+- MySQL主从复制原理
+![](https://ask.qcloudimg.com/http-save/1752328/k4urjnspih.png)
+
+从库同步主库数据的过程是**串行化**的，即主库上并行的操作，在从库上会串行执行.
+
+由于从库从主库拷贝日志以及串行执行SQL的特点，在高并发场景下是有延时的，从库数据一定会比主库慢一些，所以经常出现，刚写入主库的数据可能是读不到的，要过几十甚至几百ms才能读到
+
+而且这里还有另外一个问题，若主库突然宕机，恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，可能就这么丢失了
+
+所以MySQL实际上在这有两个机制
+
+## 半同步复制(semi-sync)
+
+解决主库数据丢失问题
+
+主库写入binlog日志后，就会强制此时立即将数据同步到从库
+
+从库将日志写入自己本地的relay log后，会返回一个ack给主库
+
+主库接收到至少一个从库的ack之后才会认为写操作完成
+
+## 并行复制
+
+解决主从同步延时问题
+
+从库开启多个线程，并行读取relay log中不同库的日志，然后**并行重放不同库的日志**，这是**库级别的并行**
+
+# 5 MySQL主从同步延时问题(核心)
+
+- MySQL主从延迟导致的生产环境的问题
+![](https://ask.qcloudimg.com/http-save/1752328/ear6wponaq.png)
+
+```
+show status，Seconds_Behind_Master
+```
+
+你可以看到从库复制主库的数据落后了多少ms
+
+其实这块东西经常会碰到，就比如说用了MySQL主从架构后，可能会发现，刚写入库的数据结果没查到，结果就完蛋了
+
+所以实际上你要考虑好应该在什么场景下来用这个MySQL主从同步
+
+建议一般在读远远多于写，且读的时候一般对数据时效性要求没那么高的时候采用
+
+所以我们可以考虑的就是，你可以用MySQL的并行复制，但问题是那是库级别的并行，所以有时候作用不是很大
+
+此时,通常来说，我们会对于那种写后立马就要保证可以查到的场景，采用强制读主库的方式
+
+确保你肯定可以读到数据。其实用一些数据库中间件也是没问题的。
+
+一般若主从延迟较为严重
+
+1. 分库 : 将一个主库拆分为4个主库，每个主库的写并发就500/s，此时主从延迟可忽略不计
+2. 打开MySQL支持的并行复制，多个库并行复制，若某个库的写入并发特别高，写并发达到了2000/s，并行复制还是没意义。二八法则，很多时候比如说，就是少数的几个订单表，写入了2000/s，其他几十个表10/s
+3. 重写代码 : 写代码的同学，要慎重，重写一下代码，插入数据之后，直接就更新，不要查询
+4. 若确实存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置**直连主库**(不推荐，这么搞导致读写分离的意义就丧失了)
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(8)-MQ\347\232\204\346\225\260\346\215\256\345\216\273\345\223\252\344\272\206.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(8)-MQ\347\232\204\346\225\260\346\215\256\345\216\273\345\223\252\344\272\206.md"
new file mode 100644
index 0000000000..0d641c4ec6
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(8)-MQ\347\232\204\346\225\260\346\215\256\345\216\273\345\223\252\344\272\206.md"
@@ -0,0 +1,95 @@
+# 1 面试题
+如何保证消息的可靠性传输（如何处理消息丢失的问题）？
+
+# 2 考点分析
+这个是肯定的，用mq有个基本原则，就是数据不能多一条，也不能少一条，不能多，就是刚才说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。
+
+如果说你这个是用mq来传递非常核心的消息，比如说计费，扣费的一些消息，因为我以前设计和研发过一个公司非常核心的广告平台，计费系统，计费系统是很重的一个业务，操作是很耗时的。所以说广告系统整体的架构里面，实际上是将计费做成异步化的，然后中间就是加了一个MQ。
+
+我们当时为了确保说这个MQ传递过程中绝对不会把计费消息给弄丢，花了很多的精力。广告主投放了一个广告，明明说好了，用户点击一次扣费1块钱。结果要是用户动不动点击了一次，扣费的时候搞的消息丢了，我们公司就会不断的少几块钱，几块钱，积少成多，这个就对公司是一个很大的损失。
+
+#  3 详解
+这个丢数据，mq一般分为两种，要么是mq自己弄丢了，要么是我们消费的时候弄丢了
+
+咱们从rabbitmq和kafka分别来分析一下吧
+
+rabbitmq这种mq，一般来说都是承载公司的核心业务的，数据是绝对不能弄丢的
+
+## 3.1 rabbitmq
+
+![](https://img-blog.csdnimg.cn/20190513100107538.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+### 3.1.1 生产者丢数据
+生产者将数据发送到rabbitmq的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。
+
+此时可以选择用rabbitmq提供的事务功能，就是生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息
+- 如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；
+- 如果收到了消息，那么可以提交事务（channel.txCommit）
+
+但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能。
+
+所以一般来说，如果你要确保说写rabbitmq的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
+
+> 事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。
+
+所以一般在生产者这块避免数据丢失，都是用confirm机制的。
+
+### 3.1.2 rabbitmq丢数据
+就是rabbitmq自己弄丢了数据，这个你必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，rabbitmq还没持久化，自己就挂了，可能导致少量数据会丢失的，但是这个概率较小。
+
+设置持久化有两个步骤，第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
+
+而且持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。
+
+哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个消息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点数据会丢失。
+
+### 3.1.3 消费端弄丢了数据
+rabbitmq如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这数据就丢了。
+
+这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。
+
+这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。
+
+## 3.2 Kafka
+
+![](https://img-blog.csdnimg.cn/20190513100126297.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+### 3.2.1 消费端丢数据
+唯一可能导致消费者弄丢数据的情况，你那个消费到了这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
+
+这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
+
+生产环境碰到的一个问题，就是说我们的kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下，结果有的时候，你刚把消息写入内存queue，然后消费者会自动提交offset。
+
+然后此时我们重启了系统，就会导致内存queue里还没来得及处理的数据就丢失了
+
+### 3.2.2 kafka弄丢了数据
+
+这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些数据？这就丢了一些数据啊。
+
+生产环境也遇到过，我们也是，之前kafka的leader机器宕机了，将follower切换为leader之后，就会发现说这个数据就丢了
+
+所以此时一般是要求起码设置如下4个参数：
+
+给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
+
+在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧
+
+在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
+
+在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了
+
+我们生产环境就是按照上述要求配置的，这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，数据不会丢失
+
+### 3.2.3 生产者会不会弄丢数据
+
+如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(9)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\241\272\345\272\217\346\200\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(9)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\241\272\345\272\217\346\200\247.md"
new file mode 100644
index 0000000000..b7a3116256
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225(9)-\345\246\202\344\275\225\344\277\235\350\257\201\346\266\210\346\201\257\351\230\237\345\210\227\347\232\204\351\241\272\345\272\217\346\200\247.md"
@@ -0,0 +1,55 @@
+
+# 0 [Github](https://github.com/Wasabi1234)
+
+# 1 面试题
+
+如何保证消息的顺序性？
+
+# 2 考点分析
+MQ必问话题
+- 考察你是否了解顺序性
+- 考察你是否有办法保证消息的顺序性,因为这是生产系统中常见的一个问题.
+
+# 3 详解
+## 3.0 案例
+一个MySQL binlog同步系统,日同步数据达到上亿.
+
+- 在MySQL里`增删改`一条数据
+- 即对应出增删改3条binlog
+- 接着这三条binlog发送到MQ里面
+- 消费出来依次执行
+
+应该得保证消息按照顺序执行的吧!
+不然本来是：增加->修改->删除
+你楞是换了顺序给执行成:删除->修改->增加
+全错!!!
+
+该数据同步过来，最后本该被删除,结果你搞错顺序,最后它却被保留下来了，数据同步出错!
+
+## 3.1 顺序错乱的场景
+### 3.1.1 rabbitmq
+一个queue，多个consumer，这不明显乱了
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561478162632_2019062514582939.png)
+### 3.1.2  kafka
+一个topic，一个partition，一个consumer，内部多线程，这也明显乱了
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561478162743_20190625154839683.png)
+
+## 3.2 保证消息的顺序性
+### 3.2.1 rabbitmq
+拆分多个queue，每个queue一个consumer
+就是多一些queue而已，确实麻烦点
+或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561478162589_20190625154145295.png)
+
+### 3.2.2 kafka
+一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可
+![](https://uploadfiles.nowcoder.com/files/20190625/5088755_1561478162731_20190625155015191.png)
+
+# 参考
+《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\357\274\21053\357\274\211- \345\210\206\345\270\203\345\274\217\346\236\266\346\236\204\347\232\204\346\274\224\350\277\233\350\277\207\347\250\213.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\357\274\21053\357\274\211- \345\210\206\345\270\203\345\274\217\346\236\266\346\236\204\347\232\204\346\274\224\350\277\233\350\277\207\347\250\213.md"
new file mode 100644
index 0000000000..69d803cf71
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\347\263\273\345\210\227/\347\252\201\347\240\264Java\351\235\242\350\257\225\357\274\21053\357\274\211- \345\210\206\345\270\203\345\274\217\346\236\266\346\236\204\347\232\204\346\274\224\350\277\233\350\277\207\347\250\213.md"	
@@ -0,0 +1,188 @@
+目标
+1. 了解分布式架构中的相关概念 
+2. 初始分布式架构及意义
+3. 分布式架构的发展过程和历史
+4. 分布式架构的演进过程
+5. 构建分布式架构最重要的因素
+
+# 1 分布式架构的发展历史
+1946 年情人节(2.14) , 世界上第一台电子数字计算机诞生在美 国宾夕法尼亚大学大学，它的名字是:ENIAC; 这台计算机占地 170 平米、重达 30 吨，每秒可进行 5000 次加法运算。 第一台电子计算机诞生以后，意味着一个日新月异的 IT 时代 的到来。一方面单台计算机的性能每年都在提升:从最早的 8 位 CPU 到现在的 64 位 CPU;从早期的 MB 级内存到现在的 GB 级别内存;从慢速的机械存储到现在的固态 SSD 硬盘存储。
+
+- tips:冯诺依曼模型
+![](https://img-blog.csdnimg.cn/20190521163328173.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+ENIAC 之后，电子计算机便进入了 IBM 主导的大型机时代，IBM 大 型机之父吉恩.阿姆达尔被认为是有史以来最伟大的计算机设计师 之一。1964 年 4 月 7 日，在阿姆达尔的带领下，历时三年，耗费 50 亿美元，第一台 IBM 大型机 SYSTEM/360 诞生。这使得 IBM 在 20 实际 50~60 年代统治整个大型计算机工业，奠定了 IBM 计算机 帝国的江山。
+ - IBM 大型机曾支撑美国航天登月计划
+ - IBM 主机一直服务于金融等核心行业的关键领域
+  
+
+由于高可靠性和超强的计算能力，即便在 X86 和云计算飞速发展的情况下,IBM 的大型机依然牢牢占据着一定的高端市场份额 20 世纪 80 年代，在大型机霸主的时代，计算机架构同时向两 个方向发展
+
+- 以 CISC (微处理器执行的计算机语言指令集) CPU 为架构 的价格便宜的面向个人的 PC
+- 以 RISC (精简指令集计算机) CPU 为架构的价格昂贵的面 向企业的小型 UNIX 服务器
+
+# 2 分布式架构发展的里程碑
+大型主机的出现。凭借着大型机超强的计算和 I/O 处理能力、 稳定性、安全性等，在很长一段时间内，大型机引领了计算机 行业及商业计算领域的发展。而集中式的计算机系统架构也成 为了主流。随着计算机的发展，这种架构越来越难以适应人们 的需求，比如说
+1. 由于大型主机的复杂性，导致培养一个能够熟练运维大型 主机的人的成本很高
+2. 大型主机很贵，一般只有土豪(政府、金融、电信)才能用得 起
+3. 单点问题，一台大型主机出现故障，那么整个系统将处于不 可用状态。而对于大型机的使用群体来说，这种不可用导致的 损失是非常大的
+
+
+ 4. 科技在进步，技术在进步。PC 机性能不断提升，很多企业 放弃大型机改用小型机及普通 PC 来搭建系统架构
+ 
+# 3 阿里巴巴在 2009 年发起了一项"去 IOE"运动
+IOE 指的是 IBM 小型机、Oracle 数据库、EMC 的高端存储 2009 年“去 IOE”战略透露，到 2013 年 5 月 17 日最后一台 IBM 小型机在支付宝下线。
+
+## 3.1 为什么要去 IOE?
+阿里巴巴过去一直采用的是 Oracle 数据库，并利用小型机和 高端存储设备提供高性能的数据处理和存储服务。随着业务的 不断发展，数据量和业务量呈爆发性增长，传统的集中式 Oracle 数据库架构在扩展性方面遭遇瓶颈。 传统的商业数据库软件(Oracle,DB2)，多以集中式架构为主， 这些传统数据库软件的最大特点就是将所有的数据都集中在 一个数据库中，依靠大型高端设备来提供高处理能力和扩展性。 集中式数据库的扩展性主要采用向上扩展(Scale up)的方式， 通过增加 CPU，内存，磁盘等方式提高处理能力。这种集中式 数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越不适应海量数据对计算能力的巨大需求
+
+# 4 分布式系统的意义
+1. 升级单机处理能力的性价比越来越低 
+单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。
+2. 单机处理能力存在瓶颈 
+单机处理能力存在瓶颈，CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的。
+3. 稳定性和可用性这两个指标很难达到 
+单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的
+
+# 5 分布式架构的常见概念
+## 5.1 集群
+小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人 多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能 炒一样的菜，这两个厨师的关系是集群
+
+![](https://img-blog.csdnimg.cn/20190521170050676.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+## 5.2 分布式
+为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切 菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师 也忙不过来了，又请了个配菜师，两个配菜师关系是集群
+
+![](https://img-blog.csdnimg.cn/2019052117012027.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+## 5.3 节点
+节点是指一个可以独立按照分布式协议完成一组逻辑的程序 个体。在具体的项目中，一个节点表示的是一个操作系统上的 进程。
+ 
+
+## 5.4 副本机制
+副本(replica/copy)指在分布式系统中为数据或服务提供的冗 余。 数据副本指在不同的节点上持久化同一份数据，当出现某一个 节点的数据丢失时，可以从副本上读取到数据。数据副本是分 布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现 服务的高可用方案
+
+## 5.5 中间件
+中间件位于操作系统提供的服务之外，又不属于应用，他是位 于应用和系统层之间为开发者方便的处理通信、输入输出的一 类软件，能够让用户关心自己应用的部分。
+
+# 6 架构的发展过程
+一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性，而 是随着用户量的增加、业务功能的扩展逐步完善演变过来的。 在这个过程中，开发模式、技术架构等都会发生非常大的变化。 而针对不同业务特征的系统，会有各自的侧重点，比如像淘宝这类的网站，要解决的是海量商品搜索、下单、支付等问题;
+
+ 像腾讯，要解决的是数亿级别用户的实时消息传输;百度所要 解决的是海量数据的搜索。每一个种类的业务都有自己不同的 系统架构。我们简单模拟一个架构演变过程。
+ 
+我们以 javaweb 为例，来搭建一个简单的电商系统，从这个系 统中来看系统的演变历史;要注意的是，接下来的演示模型， 关注的是数据量、访问量提升，网站结构发生的变化， 而不是 具体关注业务功能点。
+其次，这个过程是为了让大家更好的了 解网站演进过程中的一些问题和应对策略。 
+假如我们系统具备以下功能:
+用户模块:用户注册和管理
+商品模块:商品展示和管理
+交易模块:创建交易及支付结算
+
+## 6.1 阶段一 - 单应用架构
+ ![](https://img-blog.csdnimg.cn/2019052123471052.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+网站的初期也可以认为是互联网发展的早起，我们经常会在单 机上跑我们所有的程序和软件。 把所有软件和应用都部署在一台机器上，这样就完成一个简单 系统的搭建，这个时候的讲究的是效率
+
+## 6.2 阶段二 - 应用服务器和数据库服务器分离
+![](https://img-blog.csdnimg.cn/20190521234832114.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+随着网站的上线，访问量逐步上升，服务器的负载慢慢提高， 在服务器还没有超载的时候，我们应该做好规划，提升网站的 负载能力。假如代码层面的优化已经没办法继续提高，在不提 高单台机器的性能，增加机器是一个比较好的方式，投入产出比非常高。这个阶段增加机器的主要目的是讲 web 服务器和 数据库服务器拆分，这样不仅提高了单机的负载能力，也提高 了容灾能力
+ 
+## 6.3 阶段三 - 应用服务器集群(应用服务器负载告警，如何让应用服 务器走向集群)
+![](https://img-blog.csdnimg.cn/20190521235755368.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+随着访问量的继续增加，单台应用服务器已经无法满足需求。 在假设数据库服务器还没有遇到性能问题的时候，我们可以增 加应用服务器，通过应用服务器集群将用户请求分流到各个服务器中，从而继续提升负载能力。此时多台应用服务器之间没 有直接的交互，他们都是依赖数据库各自对外提供服务架构发展到这个阶段，各种问题也会慢慢呈现
+1. 用户请求由谁来转发到具体的应用服务器
+2. 用户如果每次访问到的服务器不一样，那么如何维护
+session
+
+![](https://img-blog.csdnimg.cn/20190522001151412.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+## 6.4  阶段四 - 数据库压力变大，数据库读写分离
+![](https://img-blog.csdnimg.cn/2019052200132319.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+架构演变到这里，并不是终点。上面我们把应用层的性能拉上来了， 但是数据库的负载也在慢慢增大，那么怎么去提高数据库层面的负载呢?
+有了前面的思路以后，自然会想到增加服务器。但是假如我们单纯的把数据库一分为二，然后对于后续数据库的请求，分别负 载到两台数据库服务器上，那么一定会造成数据库不统一的问题。 所以我们一般先考虑读写分离的方式
+
+这个架构的变化会带来几个问题
+1. 主从数据库之间的数据同步 ; 可以使用 mysql 自带的master-slave 方式实现主从复制
+2. 对应数据源的选择 ; 采用第三方数据库中间件，例如 mycat
+
+
+## 6.5 阶段五 - 使用搜索引擎缓解读库的压力
+![](https://img-blog.csdnimg.cn/20190522001339694.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+数据库做读库的话，尝尝对模糊查找效率不是特别好，像电商类的网站，搜索是非常核心的功能，即便是做了读写分离，这个问题也 不能有效解决。那么这个时候就需要引入搜索引擎了 使用搜索引擎能够大大提高我们的查询速度，但是同时也会带来一 些附加的问题，比如维护索引的构建。
+
+## 6.6 阶段六 - 引入缓存机制缓解数据库的压力
+![](https://img-blog.csdnimg.cn/20190522001432387.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+随着访问量的持续增加，逐渐出现许多用户访问统一部分内容的情况，对于这些热点数据，没必要每次都从数据库去读取，我们可以 使用缓存技术，比如 memcache、redis 来作为我们应用层的缓存; 另外在某些场景下，比如我们对用户的某些 IP 的访问频率做限制， 那这个放内存中又不合适，放数据库又太麻烦，这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库
+
+## 6.7 阶段七 - 数据库的水平/垂直拆分
+ ![在这里插入图片描述](https://img-blog.csdnimg.cn/20190522001447457.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+我们的网站演进的变化过程，交易、商品、用户的数据都还在同一 个数据库中，尽管采取了增加缓存，读写分离的方式，但是随着数 据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我 们可以考虑对数据的垂直拆分和水平拆分 垂直拆分:把数据库中不同业务数据拆分到不同的数据库
+
+水平拆分:把同一个表中的数据拆分到两个甚至跟多的数据库中，水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈，这时可以采取讲表拆分到多个数据库中
+
+![](https://img-blog.csdnimg.cn/20190522001548252.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+ 
+## 6.8 阶段八 - 应用的拆分
+![](https://img-blog.csdnimg.cn/20190522001640747.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+随着业务的发展，业务越来越多，应用的压力越来越大。工程规模 也越来越庞大。这个时候就可以考虑讲应用拆分，按照领域模型讲 我们的用户、商品、交易拆分成多个子系统
+
+
+ 这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品 和交易都需要查询，所以会导致每个系统都会有用户查询访问相关 操作。这些相同的操作一定是要抽象出来，否则就会是一个坑。所 以通过走服务化路线的方式来解决
+
+![](https://img-blog.csdnimg.cn/20190522001725475.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+
+那么服务拆分以后，各个服务之间如何进行远程通信呢?
+通过 RPC 技术，比较典型的有:webservice、hessian、http、RMI 等等 前期通过这些技术能够很好的解决各个服务之间通信问题，but， 互联网的发展是持续的，所以架构的演变和优化还在持续。
+
+![](https://img-blog.csdnimg.cn/20190522001749159.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+![](https://img-blog.csdnimg.cn/20190522001924169.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+
+
+# 7  分布式领域中冯诺依曼的变化
+前面我们讲过经典理论-冯.诺依曼体系，计算机硬件由运算器、 控制器、存储器、输入设备、输出设备五大部分组成。不管架 构怎么变化，计算机仍没有跳出该体系的范畴;
+输入设备的变化
+在分布式系统架构中，输入设备可以分两类，第一类是互相连接的 多个节点，在接收其他节点传来的信息作为该节点的输入;另一种
+
+
+就是传统意义上的人机交互的输入设备了
+
+输出设备的变化
+输出和输入类似，也有两种，一种是系统中的节点向其他节点传输 信息时，该节点可以看作是输出设备;另一种就是传统意义上的人 际交互的输出设备，比如用户的终端
+
+控制器的变化
+在单机中，控制器指的是 CPU 中的控制器，在分布式系统中，控 制器主要的作用是协调或控制节点之间的动作和行为;比如硬件负 载均衡器;LVS 软负载;规则服务器等
+
+运算器
+在分布式系统中，运算器是由多个节点来组成的。运用多个节点的 计算能力来协同完成整体的计算任务
+
+存储器
+在分布式系统中，我们需要把承担存储功能的多个节点组织在一起， 组成一个整体的存储器;比如数据库、redis(key-value 存储)
+
+
+## 7.1 分布式系统的难点
+毫无疑问，分布式系统对于集中式系统而言，在实现上会更加复杂。分布式系统将会是更难理解、设计、构建 和管理的，同 时意味着应用程序的根源问题更难发现。
+
+### 三态
+在集中式架构中，我们调用一个接口返回的结果只有两种， 成 功或者失败，但是在分布式领域中，会出现“超时”这个状态。
+
+### 分布式事务
+这是一个老生常谈的问题，我们都知道事务就是一些列操作的 原子性保证，在单机的情况下，我们能够依靠本机的数据库连 接和组件轻易做到事务的控制，但是分布式情况下，业务原子 性操作很可能是跨服务的，这样就导致了分布式事务，例如 A 和 B 操作分别是不同服务下的同一个事务操作内的操作，A 调 用 B，A 如果可以清楚的知道 B 是否成功提交从而控制自身的 提交还是回滚操作，但是在分布式系统中调用会出现一个新状 态就是超时，就是 A 无法知道 B 是成功还是失败，这个时候 A 是提交本地事务还是回滚呢?其实这是一个很难的问题，如果 强行保证事务一致性，可以采取分布式锁，但是那样会增加系 统复杂度而且会增大系统的开销，而且事务跨越的服务越多， 消耗的资源越大，性能越低，所以最好的解决方案就是避免分 布式事务。 还有一种解决方案就是重试机制，但是重试如果不是查询接口，
+
+
+ 必然涉及到数据库的变更，如果第一次调用成功但是没返回成 功结果，那调用方第二次调用对调用方来说依然是重试，但是 对于被调用方来说是重复调用，例如 A 向 B 转账，A-100,B + 100，这样会导致 A 扣了 100，而 B 增加 200。这样的结果不 是我们期望的，因此需在要写入的接口做幂等设计。多次调用 和单次调用是一样的效果。通常可以设置一个唯一键，在写入 的时候查询是否已经存在，避免重复写入。但是幂等设计的一 个前提就是服务是高可用，否则无论怎么重试都不能调用返回 一个明确的结果调用方会一直等待，虽然可以限制重试的次数， 但是这已经进入了异常状态了，甚至到了极端情况还是需要人 肉补偿处理。其实根据 CAP 和 BASE 理论，不可能在高可用分 布式情况下做到一致性，一般都是最终一致性保证。
+
+### 负载均衡
+每个服务单独部署，为了达到高可用，每个服务至少是两台机 器，因为互联网公司一般使用可靠性不是特别高的普通机器， 长期运行宕机概率很高，所以两台机器能够大大降低服务不可 用的可能性，这正大型项目会采用十几台甚至上百台来部署一 个服务，这不仅是保证服务的高可用，更是提升服务的 QPS， 但是这样又带来一个问题，一个请求过来到底路由到哪台机器? 路由算法很多，有 DNS 路由，如果 session 在本机，还会根据 用户 id 或则 cookie 等信息路由到固定的机器，当然现在应用
+
+服务器为了扩展的方便都会设计为无状态的，session 会保存 到专有的 session 服务器，所以不会涉及到拿不到 session 问 题。那路由规则是随机获取么?这是一个方法，但是据我所知， 实际情况肯定比这个复杂，在一定范围内随机，但是在大的范 围也会分为很多个域，例如如果为了保证异地多活的多机房， 夸机房调用的开销太大，肯定会优先选择同机房的服务，这个 要参考具体的机器分布来考虑。
+
+### 一致性
+数据被分散或者复制到不同的机器上，如何保证各台主机之间 的数据的一致性将成为一个难点。
+故障的独立性
+分布式系统由多个节点组成，整个分布式系统完全出问题的概 率是存在的，但是在时间中出现更多的是某个节点出问题，其 他节点都没问题。这种情况下我们实现分布式系统时需要考虑 得更加全面些
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/1.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/1.md"
new file mode 100644
index 0000000000..7fccda9ed2
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/1.md"
@@ -0,0 +1,138 @@
+# 0  [Github](https://github.com/Wasabi1234)
+
+当开始执行command，调用了它的`execute()`之后，Hystrix内部的执行流程和步骤以及原理是怎样的呢?
+
+- Hystrix执行时的8大流程及原理图
+![](https://ask.qcloudimg.com/http-save/1752328/xjewau6djw.png)
+
+# 1 创建HystrixCommand/HystrixObservableCommand
+
+一个`HystrixCommand`或`HystrixObservableCommand`对象，代表对某个依赖服务发起的一次请求或者调用
+构造的时候，可在构造函数中传入任何需要的参数
+- HystrixCommand仅仅会返回一个结果的调用
+- HystrixObservableCommand可能会返回多条结果的调用
+
+![](https://ask.qcloudimg.com/http-save/1752328/z2tthcg6g2.png)
+
+# 2 调用command的执行方法
+
+执行Command就可以发起一次对依赖服务的调用
+
+要执行Command，需要在4个方法中选择其中的一个
+
+- execute()
+同步调用,调用后直接block住,直到依赖服务返回单条结果，或抛异常
+- queue()
+异步调用,返回一个Future,后面可以通过Future获取单条结果
+- observe()
+订阅一个Observable对象，Observable代表的是依赖服务返回的结果，获取到一个那个代表结果的Observable对象的拷贝对象
+- toObservable()
+返回一个Observable对象,如果我们订阅这个对象,就会执行command并且获取返回结果
+
+其中execute()和queue()仅对HystrixCommand适用
+
+```
+K             value   = command.execute();
+Future<K>     fValue  = command.queue();
+Observable<K> ohValue = command.observe();         
+Observable<K> ocValue = command.toObservable();    
+```
+
+- execute()实际上会调用queue().get()
+![](https://ask.qcloudimg.com/http-save/1752328/tsr619j124.png)
+- 在 queue() 方法中,会调用toObservable().toBlocking().toFuture()
+![](https://ask.qcloudimg.com/http-save/1752328/8lptkw6hu7.png)
+
+即,无论是哪种执行command的方式，最终都是依赖`toObservable()`
+
+# 3 检查是否开启缓存
+
+从这开始底层的运行原理啦，了解Hysrix的一些高级的功能和特性
+
+如果这个command开启了请求缓存(request cache)，而且这个调用的结果在缓存中存在，那么直接从缓存中返回结果
+
+否则,继续往后
+
+# 4 检查是否开启短路器
+
+检查这个command对应的依赖服务是否开启短路器
+
+如果断路器被打开了，那么hystrix就不会执行这个command，而是直接执行fallback降级
+
+# 5 检查线程池/队列/semaphore是否已满
+
+如果command对应的线程池/队列/semaphore已满，那么也不会执行command，而是直接去调用fallback降级机制,同时发送 reject 信息给断路器统计
+
+# 6 执行command
+
+调用`HystrixObservableCommand.construct(`)或`HystrixCommand.run()`来实际执行这个command
+
+- HystrixCommand.run()
+返回一个单条结果，或者抛出一个异常
+- HystrixObservableCommand.construct()
+返回一个Observable对象，可以获取多条结果
+
+如果HystrixCommand.run()或HystrixObservableCommand.construct()的执行，超过了timeout时长的话，那么command所在的线程就会抛出一个TimeoutException
+
+如果timeout了，也会去执行fallback降级机制，而且就不会管run()或construct()返回的值
+
+> 我们是不可能终止掉一个调用严重延迟的依赖服务的线程的，只能说给你抛出来一个TimeoutException，但是还是可能会因为严重延迟的调用线程占满整个线程池的
+> 即使这个时候新来的流量都被限流了。。。
+
+如果没有timeout的话，那么就会拿到一些调用依赖服务获取到的结果，然后hystrix会做一些logging记录和metric统计
+
+# 7 短路健康检查
+
+Hystrix会将每一个依赖服务的调用成功，失败，拒绝，超时，等事件，都会发送给circuit breaker断路器
+
+短路器就会对调用成功/失败/拒绝/超时等事件的次数进行统计
+
+短路器会根据这些统计次数来决定，是否要进行短路，如果打开了短路器，那么在一段时间内就会直接短路，然后如果在之后第一次检查发现调用成功了，就关闭断路器
+
+# 8 调用fallback降级机制
+
+在以下几种情况中，hystrix会调用fallback降级机制
+
+- run()或construct()抛出一个异常
+- 短路器打开
+- 线程池/队列/semaphore满了
+- command执行超时了
+
+一般在降级机制中，都建议给出一些默认的返回值，比如静态的一些代码逻辑，或者从内存中的缓存中提取一些数据，尽量在这里不要再进行网络请求了
+
+即使在降级中，一定要进行网络调用，也应该将那个调用放在一个HystrixCommand中，进行隔离
+
+- 在HystrixCommand中，实现getFallback()方法，可以提供降级机制
+- 在HystirxObservableCommand中，实现一个resumeWithFallback()方法，返回一个Observable对象，可以提供降级结果
+
+如果fallback返回了结果，那么hystrix就会返回这个结果
+
+- 对于HystrixCommand，会返回一个Observable对象，其中会发返回对应的结果
+- 对于HystrixObservableCommand，会返回一个原始的Observable对象
+
+如果没有实现fallback，或者是fallback抛出了异常，Hystrix会返回一个Observable，但是不会返回任何数据
+
+不同的command执行方式，其fallback为空或者异常时的返回结果不同
+
+- 对于execute()，直接抛出异常
+- 对于queue()，返回一个Future，调用get()时抛出异常
+- 对于observe()，返回一个Observable对象，但是调用subscribe()方法订阅它时，理解抛出调用者的onError方法
+- 对于toObservable()，返回一个Observable对象，但是调用subscribe()方法订阅它时，理解抛出调用者的onError方法
+
+# 9 不同的执行方式
+
+- execute()，获取一个Future.get()，然后拿到单个结果
+- queue()，返回一个Future
+- observer()，立即订阅Observable，然后启动8大执行步骤，返回一个拷贝的Observable，订阅时理解回调给你结果
+- toObservable()，返回一个原始的Observable，必须手动订阅才会去执行8大步骤
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/13_\345\274\200\345\217\221\345\223\201\347\211\214\345\220\215\347\247\260\350\216\267\345\217\226\346\216\245\345\217\243\347\232\204\345\237\272\344\272\216\346\234\254\345\234\260\347\274\223\345\255\230\347\232\204fallback\351\231\215\347\272\247\346\234\272\345\210\266.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/13_\345\274\200\345\217\221\345\223\201\347\211\214\345\220\215\347\247\260\350\216\267\345\217\226\346\216\245\345\217\243\347\232\204\345\237\272\344\272\216\346\234\254\345\234\260\347\274\223\345\255\230\347\232\204fallback\351\231\215\347\272\247\346\234\272\345\210\266.md"
new file mode 100644
index 0000000000..1351dc7f71
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/13_\345\274\200\345\217\221\345\223\201\347\211\214\345\220\215\347\247\260\350\216\267\345\217\226\346\216\245\345\217\243\347\232\204\345\237\272\344\272\216\346\234\254\345\234\260\347\274\223\345\255\230\347\232\204fallback\351\231\215\347\272\247\346\234\272\345\210\266.md"
@@ -0,0 +1,80 @@
+
+回顾执行流程
+1. 创建command
+2. 执行command
+3. request cache
+4. 短路器，如果打开了，fallback降级机制
+
+# 1 fallback降级机制
+- Hystrix调用各种接口，或者访问外部依赖，MySQL，Redis，ZooKeeper，Kafka等,出现任何异常的情况,比如访问报错
+- 对每个外部依赖，无论是服务接口，中间件，资源隔离，对外部依赖只能用一定量的资源去访问，线程池/信号量等资源池已满
+- reject访问外部依赖的时候，访问时间过长，可能就会导致超时，报一个TimeoutException异常，timeout
+- 对外部依赖的东西访问的时候出现了异常，发送异常事件到短路器中去进行统计
+如果短路器发现异常事件的占比达到了一定比例，直接开启短路(circuit breaker)
+
+上述四种情况，都会去调用fallback降级机制
+fallback,你之前都是必须去调用外部的依赖接口，或者从MySQL中去查询数据的，但是为了避免说可能外部依赖会有故障
+
+# 2  实现方案
+## 2.1 纯内存数据
+可以在内存中维护一个ECache，作为基于LRU自动清理的纯内存缓存，数据也可放入缓存
+如果说外部依赖有异常，fallback这里，直接尝试从ECache中获取数据
+## 2.2 默认值
+本来你是从mysql，redis，或者其他任何地方去获取数据的，获取调用其他服务的接口的，结果人家故障了，人家挂了，fallback，可以返回一个默认值
+
+
+run()抛出异常，超时，线程池或信号量满了，或短路了，都会调用fallback机制
+## 案例
+现在有个商品数据，brandId，品牌，假设拿到了一个商品数据以后，用brandId再调用一次请求，到其他的服务去获取品牌的最新名称
+
+假如那个品牌服务挂掉了，那么我们可以尝试本地内存中，会保留一份时间比较过期的一份品牌数据，有些品牌没有，有些品牌的名称过期了,调用品牌服务失败了，fallback降级就从本地内存中获取一份过期的数据，先凑合着用着
+```
+public class CommandHelloFailure extends HystrixCommand<String> {
+
+    private final String name;
+
+    public CommandHelloFailure(String name) {
+        super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
+        this.name = name;
+    }
+
+    @Override
+    protected String run() {
+        throw new RuntimeException("this command always fails");
+    }
+
+    @Override
+    protected String getFallback() {
+        return "Hello Failure " + name + "!";
+    }
+
+}
+
+@Test
+public void testSynchronous() {
+    assertEquals("Hello Failure World!", new CommandHelloFailure("World").execute());
+}
+```
+HystrixObservableCommand，是实现resumeWithFallback方法
+
+2、fallback.isolation.semaphore.maxConcurrentRequests
+
+这个参数设置了HystrixCommand.getFallback()最大允许的并发请求数量，默认值是10，也是通过semaphore信号量的机制去限流 
+
+如果超出了这个最大值，那么直接被reject
+```
+HystrixCommandProperties.Setter()
+   .withFallbackIsolationSemaphoreMaxConcurrentRequests(int value)
+
+```
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\347\252\201\347\240\264Java\351\235\242\350\257\225-hystrix\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\345\217\212\350\256\276\350\256\241\345\216\237\345\210\231.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\347\252\201\347\240\264Java\351\235\242\350\257\225-hystrix\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\345\217\212\350\256\276\350\256\241\345\216\237\345\210\231.md"
new file mode 100644
index 0000000000..14b2c3399c
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\347\252\201\347\240\264Java\351\235\242\350\257\225-hystrix\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\345\217\212\350\256\276\350\256\241\345\216\237\345\210\231.md"
@@ -0,0 +1,95 @@
+# 1 Hystrix是什么？
+在分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。
+
+Hystrix可以让我们在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。
+
+Hystrix通过将依赖服务进行资源隔离，进而组织某个依赖服务出现故障的时候，这种故障在整个系统所有的依赖服务调用中进行蔓延，同时Hystrix还提供故障时的fallback降级机制
+
+总而言之，Hystrix通过这些方法帮助我们提升分布式系统的可用性和稳定性
+
+# 2 Hystrix的历史
+
+hystrix，就是一种高可用保障的一个框架，类似于spring（ioc，mvc），mybatis，activiti，lucene，框架，预先封装好的为了解决某个特定领域的特定问题的一套代码库
+
+框架，用了框架之后，来解决这个领域的特定的问题，就可以大大减少我们的工作量，提升我们的工作质量和工作效率，框架
+
+hystrix，高可用性保障的一个框架
+
+Netflix（可以认为是国外的优酷或者爱奇艺之类的视频网站），API团队从2011年开始做一些提升系统可用性和稳定性的工作，Hystrix就是从那时候开始发展出来的。
+
+在2012年的时候，Hystrix就变得比较成熟和稳定了，Netflix中，除了API团队以外，很多其他的团队都开始使用Hystrix。
+
+时至今日，Netflix中每天都有数十亿次的服务间调用，通过Hystrix框架在进行，而Hystrix也帮助Netflix网站提升了整体的可用性和稳定性
+
+# 3 初步看一看Hystrix的设计原则是什么？
+hystrix为了实现高可用性的架构，设计hystrix的时候，一些设计原则是什么？？？
+
+（1）对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
+（2）在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了，服务A故障了，整套分布式系统全部故障，整体宕机
+（3）提供fail-fast（快速失败）和快速恢复的支持
+（4）提供fallback优雅降级的支持
+（5）支持近实时的监控、报警以及运维操作
+
+调用延迟+失败，提供容错
+阻止故障蔓延
+快速失败+快速恢复
+降级
+监控+报警+运维
+
+完全描述了hystrix的功能，提供整个分布式系统的高可用的架构
+
+# 4 Hystrix要解决的问题是什么？
+
+在复杂的分布式系统架构中，每个服务都有很多的依赖服务，而每个依赖服务都可能会故障
+
+如果服务没有和自己的依赖服务进行隔离，那么可能某一个依赖服务的故障就会拖垮当前这个服务
+
+举例来说，某个服务有30个依赖服务，每个依赖服务的可用性非常高，已经达到了99.99%的高可用性
+
+那么该服务的可用性就是99.99%的30次方，也就是99.7%的可用性
+
+99.7%的可用性就意味着3%的请求可能会失败，因为3%的时间内系统可能出现了故障不可用了
+
+对于1亿次访问来说，3%的请求失败，也就意味着300万次请求会失败，也意味着每个月有2个小时的时间系统是不可用的
+
+在真实生产环境中，可能更加糟糕
+
+上面也就是说，即使你每个依赖服务都是99.99%高可用性，但是一旦你有几十个依赖服务，还是会导致你每个月都有几个小时是不可用的
+
+画图分析说，当某一个依赖服务出现了调用延迟或者调用失败时，为什么会拖垮当前这个服务？以及在分布式系统中，故障是如何快速蔓延的？
+
+# 5 再看Hystrix的更加细节的设计原则是什么？
+
+（1）阻止任何一个依赖服务耗尽所有的资源，比如tomcat中的所有线程资源
+（2）避免请求排队和积压，采用限流和fail fast来控制故障
+（3）提供fallback降级机制来应对故障
+（4）使用资源隔离技术，比如bulkhead（舱壁隔离技术），swimlane（泳道技术），circuit breaker（短路技术），来限制任何一个依赖服务的故障的影响
+（5）通过近实时的统计/监控/报警功能，来提高故障发现的速度
+（6）通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度
+（7）保护依赖服务调用的所有故障情况，而不仅仅只是网络故障情况
+
+调用这个依赖服务的时候，client调用包有bug，阻塞，等等，依赖服务的各种各样的调用的故障，都可以处理
+
+# 6 Hystrix是如何实现它的目标的？
+
+（1）通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离
+（2）对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间，但是一般我们可以自己设置一下
+（3）为每一个依赖服务维护一个独立的线程池，或者是semaphore，当线程池已满时，直接拒绝对这个服务的调用
+（4）对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计
+（5）如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复
+（6）当一个服务调用出现失败，被拒绝，超时，短路等异常情况时，自动调用fallback降级机制
+（7）对属性和配置的修改提供近实时的支持
+
+画图分析，对依赖进行资源隔离后，如何避免依赖服务调用延迟或失败导致当前服务的故障
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(10)-Hystrix\347\232\204\347\272\277\347\250\213\346\261\240+\346\234\215\345\212\241+\346\216\245\345\217\243\345\210\222\345\210\206\344\273\245\345\217\212\350\265\204\346\272\220\346\261\240\347\232\204\345\256\271\351\207\217\345\244\247\345\260\217\346\216\247\345\210\266.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(10)-Hystrix\347\232\204\347\272\277\347\250\213\346\261\240+\346\234\215\345\212\241+\346\216\245\345\217\243\345\210\222\345\210\206\344\273\245\345\217\212\350\265\204\346\272\220\346\261\240\347\232\204\345\256\271\351\207\217\345\244\247\345\260\217\346\216\247\345\210\266.md"
new file mode 100644
index 0000000000..a509c9bc8b
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(10)-Hystrix\347\232\204\347\272\277\347\250\213\346\261\240+\346\234\215\345\212\241+\346\216\245\345\217\243\345\210\222\345\210\206\344\273\245\345\217\212\350\265\204\346\272\220\346\261\240\347\232\204\345\256\271\351\207\217\345\244\247\345\260\217\346\216\247\345\210\266.md"
@@ -0,0 +1,182 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+资源隔离两种策略
+
+- 线程池隔离
+- 信号量隔离
+
+对于资源隔离，做更加深入一些的讲解，除了可以选择隔离策略，对选择的隔离策略，可以做一定的细粒度的控制
+
+# 1 execution.isolation.strategy
+
+![](https://ask.qcloudimg.com/http-save/1752328/6bnzqungsa.png)
+
+指定HystrixCommand.run()的资源隔离策略
+
+- THREAD
+基于线程池
+
+```
+// to use thread isolation
+HystrixCommandProperties.Setter()
+   .withExecutionIsolationStrategy(ExecutionIsolationStrategy.THREAD)
+```
+
+- SEMAPHORE
+基于信号量// to use semaphore isolation
+HystrixCommandProperties.Setter()
+   .withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)线程池机制，每个command运行在一个线程中，限流是通过线程池的大小来控制的
+信号量机制，command是运行在调用线程中，但是通过信号量的容量来进行限流
+
+如何在线程池和信号量之间做选择呢？
+
+**默认的策略**为线程池
+
+线程池其实最大的好处就是对于网络访问请求，若超时，可以避免调用线程阻塞住
+
+而使用信号量的场景，通常是针对超大并发量的场景下，每个服务实例每秒都几百的QPS
+
+此时用线程池，线程一般不会太多，可能撑不住那么高的并发
+
+要撑住，可能要耗费大量的线程资源，那么就是用信号量，来限流保护
+
+一般用信号量常见于那种基于纯内存的一些业务逻辑服务，而不涉及到任何网络访问请求
+
+netflix有100+的command运行在40+的线程池中，只有少数command是不运行在线程池中的，就是从纯内存中获取一些元数据，或者是对多个command包装起来的facacde command，是用信号量限流的
+
+# 2 command名称 & command组
+
+线程池隔离，依赖服务->接口->线程池，如何来划分
+
+每个command，都可以设置一个自己的名称，同时可以设置一个自己的组
+
+```
+private static final Setter cachedSetter = 
+    Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
+        .andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"));    
+
+public CommandHelloWorld(String name) {
+    super(cachedSetter);
+    this.name = name;
+}
+```
+
+- command group
+一个非常重要的概念，默认情况下，因为就是通过command group来定义一个线程池的，而且还会通过command group来聚合一些监控和报警信息
+
+同一个command group中的请求，都会进入同一个线程池中
+
+# 3 command线程池
+
+ThreadPoolKey代表了一个HystrixThreadPool，用来进行统一监控，统计，缓存
+
+![](https://ask.qcloudimg.com/http-save/1752328/98i26bqkvh.png)
+
+默认的threadpool key就是command group名称
+
+![](https://ask.qcloudimg.com/http-save/1752328/32kt2y2upy.png)
+
+每个command都会跟它的ThreadPoolKey对应的ThreadPool绑定
+
+如果不想直接用command group，也可以手动设置thread pool name
+
+```
+public CommandHelloWorld(String name) {
+    super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
+            .andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"))
+            .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("HelloWorldPool")));
+    this.name = name;
+}
+```
+
+> command threadpool => command group => command key
+
+- command key
+![](https://ask.qcloudimg.com/http-save/1752328/wrpg9xa1x6.png)代表了一类command，代表底层的依赖服务的一个接口
+- command group
+![](https://ask.qcloudimg.com/http-save/1752328/qfys52yzt1.png)代表了某一个底层的依赖服务，合理，一个依赖服务可能会暴露出来多个接口，每个接口就是一个command key
+
+command group
+
+在逻辑上去组织起来一堆command key的调用，统计信息，成功次数，timeout超时次数，失败次数，可以看到某一个服务整体的一些访问情况
+
+推荐是根据一个服务去划分出一个线程池，command key默认都是属于同一个线程池的
+
+比如说你以一个服务为粒度，估算出来这个服务每秒的所有接口加起来的整体QPS在100左右
+
+你调用那个服务的当前服务，部署了10个服务实例，每个服务实例上，其实用这个command group对应这个服务，给一个线程池，量大概在10个左右，就可以了，你对整个服务的整体的访问QPS大概在每秒100左右
+
+一般来说，command group是用来在逻辑上组合一堆command的
+
+举个例子，对于一个服务中的某个功能模块来说，希望将这个功能模块内的所有command放在一个group中，那么在监控和报警的时候可以放一起看
+
+command group，对应了一个服务，但是这个服务暴露出来的几个接口，访问量很不一样，差异非常之大
+
+你可能就希望在这个服务command group内部，包含的对应多个接口的command key，做一些细粒度的资源隔离
+
+对同一个服务的不同接口，都使用不同的线程池
+
+```
+command key -> command group
+
+command key -> 自己的threadpool key
+```
+
+逻辑上来说，多个command key属于一个command group，在做统计的时候，会放在一起统计
+
+每个command key有自己的线程池，每个接口有自己的线程池，去做资源隔离和限流
+
+但对于thread pool资源隔离来说，可能是希望能够拆分的更加一致一些，比如在一个功能模块内，对不同的请求可以使用不同的thread pool
+
+command group一般来说，可以是对应一个服务，多个command key对应这个服务的多个接口，多个接口的调用共享同一个线程池
+
+如果说你的command key，要用自己的线程池，可以定义自己的threadpool key，就ok了
+
+# 4 coreSize
+
+设置线程池的大小，默认是10
+
+```
+HystrixThreadPoolProperties.Setter()
+ 						   .withCoreSize(int value)
+```
+
+一般来说，用这个默认的10个线程大小就够了
+
+# 5 queueSizeRejectionThreshold
+
+控制queue满后reject的threshold，因为maxQueueSize不允许热修改，因此提供这个参数可以热修改，控制队列的最大值
+
+HystrixCommand在提交到线程池之前，其实会先进入一个队列中，这个队列满了之后，才会reject
+
+默认值是5
+
+```
+HystrixThreadPoolProperties.Setter()
+   .withQueueSizeRejectionThreshold(int value)
+```
+
+- 线程池+queue的工作原理![](https://ask.qcloudimg.com/http-save/1752328/lsc1i86k0k.png)
+
+# 6 isolation.semaphore.maxConcurrentRequests
+
+设置使用SEMAPHORE隔离策略的时候，允许访问的最大并发量，超过这个最大并发量，请求直接被reject
+
+这个并发量的设置，跟线程池大小的设置，应该是类似的
+
+但是基于信号量的话，性能会好很多，而且hystrix框架本身的开销会小很多
+
+默认值是10，设置的小一些，否则因为信号量是基于调用线程去执行command的，而且不能从timeout中抽离，因此一旦设置的太大，而且有延时发生，可能瞬间导致tomcat本身的线程资源本占满
+
+![](https://ask.qcloudimg.com/http-save/1752328/8fu9z58eu7.png)
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(12) - \345\237\272\344\272\216request cache\350\257\267\346\261\202\347\274\223\345\255\230\346\212\200\346\234\257\344\274\230\345\214\226\346\211\271\351\207\217\345\225\206\345\223\201\346\225\260\346\215\256\346\237\245\350\257\242\346\216\245\345\217\243.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(12) - \345\237\272\344\272\216request cache\350\257\267\346\261\202\347\274\223\345\255\230\346\212\200\346\234\257\344\274\230\345\214\226\346\211\271\351\207\217\345\225\206\345\223\201\346\225\260\346\215\256\346\237\245\350\257\242\346\216\245\345\217\243.md"
new file mode 100644
index 0000000000..b717f4ae0c
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(12) - \345\237\272\344\272\216request cache\350\257\267\346\261\202\347\274\223\345\255\230\346\212\200\346\234\257\344\274\230\345\214\226\346\211\271\351\207\217\345\225\206\345\223\201\346\225\260\346\215\256\346\237\245\350\257\242\346\216\245\345\217\243.md"	
@@ -0,0 +1,386 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+回顾执行流程
+
+1、创建command，2种command类型
+
+2、执行command，4种执行方式
+
+3、查找是否开启了request cache，是否有请求缓存，如果有缓存，直接取用缓存，返回结果
+
+首先，reqeust context(请求上下文)
+
+一般在一个web应用中，Hystrix会在一个filter里面，对每个请求都添加一个请求上下文
+
+即Tomcat容器内，每一次请求，就是一次请求上下文
+
+然后在这次请求上下文中，我们会去执行N多代码，调用N多依赖服务，有的依赖服务可能还会调用好几次
+
+在一次请求上下文中，如果有多个command,参数及调用的接口也是一样的，其实结果也可以认为是一样的
+
+那么就可以让第一次command执行返回的结果缓存在内存，然后这个请求上下文中，后续的其他对这个依赖的调用全部从内存中取用缓存结果即可
+
+这样**避免在一次请求上下文中多次执行一样的command，避免重复执行网络请求,从而提升整个请求的性能**
+
+- request cache的原理图
+![](https://ask.qcloudimg.com/http-save/1752328/8tl7gz2pet.png)
+
+对于请求缓存（request caching），请求合并（request collapsing），请求日志（request log），等等技术，都必须自己管理HystrixReuqestContext的声明周期
+
+在一个请求执行之前，都必须先初始化一个request context
+
+```
+HystrixRequestContext context = HystrixRequestContext.initializeContext();
+```
+
+然后在请求结束之后，需要关闭request context
+
+```
+context.shutdown();
+```
+
+一般来说，在java web的应用中，都是通过filter过滤器来实现的
+
+```
+public class HystrixRequestContextServletFilter implements Filter {
+
+    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
+     throws IOException, ServletException {
+        HystrixRequestContext context = HystrixRequestContext.initializeContext();
+        try {
+            chain.doFilter(request, response);
+        } finally {
+            context.shutdown();
+        }
+    }
+}
+
+@Bean
+public FilterRegistrationBean indexFilterRegistration() {
+    FilterRegistrationBean registration = new FilterRegistrationBean(new IndexFilter());
+    registration.addUrlPatterns("/");
+    return registration;
+}
+```
+
+结合业务背景，我们做了一个批量查询商品数据的接口，在这个里面，我们其实通过HystrixObservableCommand一次性批量查询多个商品id的数据
+
+但是这里有个问题，如果说nginx在本地缓存失效了，重新获取一批缓存，传递过来的productId都没有进行去重，1,1,2,2,5,6,7
+
+那么可能说，商品id出现了重复，如果按照我们之前的业务逻辑，可能就会重复对productId=1的商品查询两次，productId=2的商品查询两次
+
+我们对批量查询商品数据的接口，可以用request cache做一个优化，就是说一次请求，就是一次request context，对相同的商品查询只能执行一次，其余的都走request cache
+
+```
+public class CommandUsingRequestCache extends HystrixCommand<Boolean> {
+
+    private final int value;
+
+    protected CommandUsingRequestCache(int value) {
+        super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
+        this.value = value;
+    }
+
+    @Override
+    protected Boolean run() {
+        return value == 0 || value % 2 == 0;
+    }
+
+    @Override
+    protected String getCacheKey() {
+        return String.valueOf(value);
+    }
+
+}
+
+@Test
+public void testWithCacheHits() {
+    HystrixRequestContext context = HystrixRequestContext.initializeContext();
+    try {
+        CommandUsingRequestCache command2a = new CommandUsingRequestCache(2);
+        CommandUsingRequestCache command2b = new CommandUsingRequestCache(2);
+
+        assertTrue(command2a.execute());
+        // this is the first time we've executed this command with
+        // the value of "2" so it should not be from cache
+        assertFalse(command2a.isResponseFromCache());
+
+        assertTrue(command2b.execute());
+        // this is the second time we've executed this command with
+        // the same value so it should return from cache
+        assertTrue(command2b.isResponseFromCache());
+    } finally {
+        context.shutdown();
+    }
+
+    // start a new request context
+    context = HystrixRequestContext.initializeContext();
+    try {
+        CommandUsingRequestCache command3b = new CommandUsingRequestCache(2);
+        assertTrue(command3b.execute());
+        // this is a new request context so this 
+        // should not come from cache
+        assertFalse(command3b.isResponseFromCache());
+    } finally {
+        context.shutdown();
+    }
+}
+```
+
+缓存的手动清理
+
+```
+public static class GetterCommand extends HystrixCommand<String> {
+
+    private static final HystrixCommandKey GETTER_KEY = HystrixCommandKey.Factory.asKey("GetterCommand");
+    private final int id;
+
+    public GetterCommand(int id) {
+        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("GetSetGet"))
+                .andCommandKey(GETTER_KEY));
+        this.id = id;
+    }
+
+    @Override
+    protected String run() {
+        return prefixStoredOnRemoteDataStore + id;
+    }
+
+    @Override
+    protected String getCacheKey() {
+        return String.valueOf(id);
+    }
+
+    /**
+     * Allow the cache to be flushed for this object.
+     * 
+     * @param id
+     *            argument that would normally be passed to the command
+     */
+    public static void flushCache(int id) {
+        HystrixRequestCache.getInstance(GETTER_KEY,
+                HystrixConcurrencyStrategyDefault.getInstance()).clear(String.valueOf(id));
+    }
+
+}
+
+public static class SetterCommand extends HystrixCommand<Void> {
+
+    private final int id;
+    private final String prefix;
+
+    public SetterCommand(int id, String prefix) {
+        super(HystrixCommandGroupKey.Factory.asKey("GetSetGet"));
+        this.id = id;
+        this.prefix = prefix;
+    }
+
+    @Override
+    protected Void run() {
+        // persist the value against the datastore
+        prefixStoredOnRemoteDataStore = prefix;
+        // flush the cache
+        GetterCommand.flushCache(id);
+        // no return value
+        return null;
+    }
+}
+```
+
+回顾执行流程
+
+1、创建command，2种command类型
+
+2、执行command，4种执行方式
+
+3、查找是否开启了request cache，是否有请求缓存，如果有缓存，直接取用缓存，返回结果
+
+首先，reqeust context(请求上下文)
+
+一般在一个web应用中，Hystrix会在一个filter里面，对每个请求都添加一个请求上下文
+
+即Tomcat容器内，每一次请求，就是一次请求上下文
+
+然后在这次请求上下文中，我们会去执行N多代码，调用N多依赖服务，有的依赖服务可能还会调用好几次
+
+在一次请求上下文中，如果有多个command,参数及调用的接口也是一样的，其实结果也可以认为是一样的
+
+那么就可以让第一次command执行返回的结果缓存在内存，然后这个请求上下文中，后续的其他对这个依赖的调用全部从内存中取用缓存结果即可
+
+这样**避免在一次请求上下文中多次执行一样的command，避免重复执行网络请求,从而提升整个请求的性能**
+
+- request cache的原理图
+![](https://ask.qcloudimg.com/http-save/1752328/8tl7gz2pet.png)
+
+对于请求缓存（request caching），请求合并（request collapsing），请求日志（request log），等等技术，都必须自己管理HystrixReuqestContext的声明周期
+
+在一个请求执行之前，都必须先初始化一个request context
+
+```
+HystrixRequestContext context = HystrixRequestContext.initializeContext();
+```
+
+然后在请求结束之后，需要关闭request context
+
+```
+context.shutdown();
+```
+
+一般来说，在java web的应用中，都是通过filter过滤器来实现的
+
+```
+public class HystrixRequestContextServletFilter implements Filter {
+
+    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
+     throws IOException, ServletException {
+        HystrixRequestContext context = HystrixRequestContext.initializeContext();
+        try {
+            chain.doFilter(request, response);
+        } finally {
+            context.shutdown();
+        }
+    }
+}
+
+@Bean
+public FilterRegistrationBean indexFilterRegistration() {
+    FilterRegistrationBean registration = new FilterRegistrationBean(new IndexFilter());
+    registration.addUrlPatterns("/");
+    return registration;
+}
+```
+
+结合业务背景，我们做了一个批量查询商品数据的接口，在这个里面，我们其实通过HystrixObservableCommand一次性批量查询多个商品id的数据
+
+但是这里有个问题，如果说nginx在本地缓存失效了，重新获取一批缓存，传递过来的productId都没有进行去重，1,1,2,2,5,6,7
+
+那么可能说，商品id出现了重复，如果按照我们之前的业务逻辑，可能就会重复对productId=1的商品查询两次，productId=2的商品查询两次
+
+我们对批量查询商品数据的接口，可以用request cache做一个优化，就是说一次请求，就是一次request context，对相同的商品查询只能执行一次，其余的都走request cache
+
+```
+public class CommandUsingRequestCache extends HystrixCommand<Boolean> {
+
+    private final int value;
+
+    protected CommandUsingRequestCache(int value) {
+        super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
+        this.value = value;
+    }
+
+    @Override
+    protected Boolean run() {
+        return value == 0 || value % 2 == 0;
+    }
+
+    @Override
+    protected String getCacheKey() {
+        return String.valueOf(value);
+    }
+
+}
+
+@Test
+public void testWithCacheHits() {
+    HystrixRequestContext context = HystrixRequestContext.initializeContext();
+    try {
+        CommandUsingRequestCache command2a = new CommandUsingRequestCache(2);
+        CommandUsingRequestCache command2b = new CommandUsingRequestCache(2);
+
+        assertTrue(command2a.execute());
+        // this is the first time we've executed this command with
+        // the value of "2" so it should not be from cache
+        assertFalse(command2a.isResponseFromCache());
+
+        assertTrue(command2b.execute());
+        // this is the second time we've executed this command with
+        // the same value so it should return from cache
+        assertTrue(command2b.isResponseFromCache());
+    } finally {
+        context.shutdown();
+    }
+
+    // start a new request context
+    context = HystrixRequestContext.initializeContext();
+    try {
+        CommandUsingRequestCache command3b = new CommandUsingRequestCache(2);
+        assertTrue(command3b.execute());
+        // this is a new request context so this 
+        // should not come from cache
+        assertFalse(command3b.isResponseFromCache());
+    } finally {
+        context.shutdown();
+    }
+}
+```
+
+缓存的手动清理
+
+```
+public static class GetterCommand extends HystrixCommand<String> {
+
+    private static final HystrixCommandKey GETTER_KEY = HystrixCommandKey.Factory.asKey("GetterCommand");
+    private final int id;
+
+    public GetterCommand(int id) {
+        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("GetSetGet"))
+                .andCommandKey(GETTER_KEY));
+        this.id = id;
+    }
+
+    @Override
+    protected String run() {
+        return prefixStoredOnRemoteDataStore + id;
+    }
+
+    @Override
+    protected String getCacheKey() {
+        return String.valueOf(id);
+    }
+
+    /**
+     * Allow the cache to be flushed for this object.
+     * 
+     * @param id
+     *            argument that would normally be passed to the command
+     */
+    public static void flushCache(int id) {
+        HystrixRequestCache.getInstance(GETTER_KEY,
+                HystrixConcurrencyStrategyDefault.getInstance()).clear(String.valueOf(id));
+    }
+
+}
+
+public static class SetterCommand extends HystrixCommand<Void> {
+
+    private final int id;
+    private final String prefix;
+
+    public SetterCommand(int id, String prefix) {
+        super(HystrixCommandGroupKey.Factory.asKey("GetSetGet"));
+        this.id = id;
+        this.prefix = prefix;
+    }
+
+    @Override
+    protected Void run() {
+        // persist the value against the datastore
+        prefixStoredOnRemoteDataStore = prefix;
+        // flush the cache
+        GetterCommand.flushCache(id);
+        // no return value
+        return null;
+    }
+}
+```
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(16) - \345\237\272\344\272\216timeout\346\234\272\345\210\266\346\235\245\344\270\272\345\225\206\345\223\201\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\350\260\203\347\224\250\350\266\205\346\227\266\346\217\220\344\276\233\345\256\211\345\205\250\344\277\235\346\212\244.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(16) - \345\237\272\344\272\216timeout\346\234\272\345\210\266\346\235\245\344\270\272\345\225\206\345\223\201\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\350\260\203\347\224\250\350\266\205\346\227\266\346\217\220\344\276\233\345\256\211\345\205\250\344\277\235\346\212\244.md"
new file mode 100644
index 0000000000..2808e9f696
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(16) - \345\237\272\344\272\216timeout\346\234\272\345\210\266\346\235\245\344\270\272\345\225\206\345\223\201\346\234\215\345\212\241\346\216\245\345\217\243\347\232\204\350\260\203\347\224\250\350\266\205\346\227\266\346\217\220\344\276\233\345\256\211\345\205\250\344\277\235\346\212\244.md"	
@@ -0,0 +1,40 @@
+一般来说，在调用依赖服务的接口的时候，比较常见的一个问题，就是超时
+
+超时是在一个复杂的分布式系统中，导致不稳定，或者系统抖动，或者出现说大量超时，线程资源hang死，吞吐量大幅度下降，甚至服务崩溃
+
+分布式复杂的系统里，可能你的依赖接口的性能很不稳定，有时候2ms，200ms，2s
+
+如果你不对各种依赖接口的调用，做超时的控制，来给你的服务提供安全保护措施，那么很可能你的服务就被各种垃圾的依赖服务的性能给拖死了
+
+# 1 TimeoutMilliseconds
+
+- Timeout value in milliseconds for a command
+
+![](https://ask.qcloudimg.com/http-save/1752328/b9efgx46d9.png)
+
+手动设置timeout时长，一个command运行超出这个时间，就认为是timeout
+
+然后将hystrix command标识为timeout，同时执行fallback降级逻辑
+
+- default => executionTimeoutInMilliseconds: 1000 = 1 second
+默认是1000，也就是1000毫秒
+
+![](https://ask.qcloudimg.com/http-save/1752328/oe2pxk64pi.png)
+
+# 2 TimeoutEnabled
+- Whether timeout should be triggered
+是否应触发超时
+![](https://ask.qcloudimg.com/http-save/1752328/zy2ur2twot.png)
+- 控制是否要打开timeout机制，默认是true
+![](https://ask.qcloudimg.com/http-save/1752328/5u56gzo4v3.png)
+让一个command执行timeout，然后看是否会调用fallback降级
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(17) - \345\237\272\344\272\216Hystrix\347\232\204\351\253\230\345\217\257\347\224\250\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\346\200\273\347\273\223.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(17) - \345\237\272\344\272\216Hystrix\347\232\204\351\253\230\345\217\257\347\224\250\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\346\200\273\347\273\223.md"
new file mode 100644
index 0000000000..9822a7ab1b
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(17) - \345\237\272\344\272\216Hystrix\347\232\204\351\253\230\345\217\257\347\224\250\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\346\200\273\347\273\223.md"	
@@ -0,0 +1,37 @@
+已经学到的东西
+
+hystrix的核心知识
+
+1、hystrix内部工作原理：8大执行步骤和流程
+2、资源隔离：你如果有很多个依赖服务，高可用性，先做资源隔离，任何一个依赖服务的故障不会导致你的服务的资源耗尽，不会崩溃
+3、请求缓存：对于一个request context内的多个相同command，使用request cache，提升性能
+4、熔断：基于短路器，采集各种异常事件，报错，超时，reject，短路，熔断，一定时间范围内就不允许访问了，直接降级，自动恢复的机制
+5、降级：报错，超时，reject，熔断，降级，服务提供容错的机制
+6、限流：在你的服务里面，通过线程池，或者信号量，限制对某个后端的服务或资源的访问量，避免从你的服务这里过去太多的流量，打死某个资源
+7、超时：避免某个依赖服务性能过差，导致大量的线程hang住去调用那个服务，会导致你的服务本身性能也比较差
+
+学会了这些东西以后，我们特意设置了大电商背景，商品详情页系统，缓存服务的业务场景，尽量的去结合一些仿真的业务，去学习hystrix的各项技术
+
+这个东西做起来没那么容易，尽量做了，学习效果更好一些，兴趣也会更好一些
+
+已经可以快速利用hystrix给自己开发的服务增加各种高可用的保障措施了，避免你的系统因为各种各样的异常情况导致崩溃，不可用
+
+hystrix的高阶知识
+
+1、request collapser，请求合并技术
+2、fail-fast和fail-slient，高阶容错模式
+3、static fallback和stubbed fallback，高阶降级模式
+4、嵌套command实现的发送网络请求的降级模式
+5、基于facade command的多级降级模式
+6、request cache的手动清理
+7、生产环境中的线程池大小以及timeout配置优化经验
+8、线程池的自动化动态扩容与缩容技术
+9、hystrix的metric高阶配置
+10、基于hystrix dashboard的可视化分布式系统监控
+11、生产环境中的hystrix工程运维经验
+
+
+# X 联系我
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(9) - \345\237\272\344\272\216Hystrix\347\232\204\344\277\241\345\217\267\351\207\217\346\212\200\346\234\257\345\257\271\345\234\260\347\220\206\344\275\215\347\275\256\350\216\267\345\217\226\351\200\273\350\276\221\350\277\233\350\241\214\350\265\204\346\272\220\351\232\224\347\246\273\344\270\216\351\231\220\346\265\201.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(9) - \345\237\272\344\272\216Hystrix\347\232\204\344\277\241\345\217\267\351\207\217\346\212\200\346\234\257\345\257\271\345\234\260\347\220\206\344\275\215\347\275\256\350\216\267\345\217\226\351\200\273\350\276\221\350\277\233\350\241\214\350\265\204\346\272\220\351\232\224\347\246\273\344\270\216\351\231\220\346\265\201.md"
new file mode 100644
index 0000000000..34c3149e9f
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\234\215\345\212\241\346\236\266\346\236\204\350\256\276\350\256\241(9) - \345\237\272\344\272\216Hystrix\347\232\204\344\277\241\345\217\267\351\207\217\346\212\200\346\234\257\345\257\271\345\234\260\347\220\206\344\275\215\347\275\256\350\216\267\345\217\226\351\200\273\350\276\221\350\277\233\350\241\214\350\265\204\346\272\220\351\232\224\347\246\273\344\270\216\351\231\220\346\265\201.md"	
@@ -0,0 +1,67 @@
+# 0 [Github](https://github.com/Wasabi1234)
+
+# 1 线程池隔离  VS 信号量隔离
+
+Hystrix里面，核心的一项功能，就是**资源隔离**，要解决的最核心的问题，就是**将多个依赖服务的调用分别隔离到各自自己的资源池内**
+
+避免对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上
+
+一旦某个服务的线程资源全部耗尽，可能就会导致服务崩溃，故障甚至还会蔓延
+
+Hystrix实现资源隔离，两种技术
+
+- 线程池的资源隔离
+- 信号量的资源隔离
+
+信号量，semaphore
+
+信号量跟线程池，两种资源隔离的技术，区别到底在哪儿呢？
+
+- 线程池隔离和信号量隔离的原理以及区别
+![](https://ask.qcloudimg.com/http-save/1752328/rq31ha62fc.png)
+
+# 2 适用场景
+
+## 2.1 线程池
+
+适合绝大多数的场景，99%的，线程池，对依赖服务的网络请求的调用和访问，timeout这种问题
+
+## 2.2 信号量
+
+适合访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问，但像这种访问，系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可
+
+因为不需要去捕获timeout类似的问题，算法+数据结构的效率不是太高，并发量突然太高，因为这里稍微耗时一些，导致很多线程卡在这里的话，不太好，所以进行一个基本的资源隔离和访问，避免内部复杂的低效率的代码，导致大量的线程被hang住
+
+- 信号量的资源隔离与限流的说明
+![](https://ask.qcloudimg.com/http-save/1752328/2rbakzj4jz.png)
+
+# 3 实践本地内存获取地理位置数据的逻辑
+
+业务背景里面， 比较适合信号量的是什么场景呢？
+
+比如缓存服务，可能会将部分量特别少，访问又特别频繁的一些数据，放在纯内存
+
+一般我们在获取到商品数据之后，都要去获取商品是属于哪个地理位置，省，市，卖家的
+
+可能在自己的纯内存中，比如就一个Map去获取.对于这种直接访问本地内存的逻辑，比较适合用信号量做一下简单的隔离
+
+优点在于，不用自己管理线程池，不用担心超时，信号量做隔离的话，性能会相对来说高一些
+
+# 4 采用信号量技术对地理位置获取逻辑进行资源隔离与限流
+
+```
+super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
+        .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
+               .withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)));
+```
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(0) - \345\257\274\350\257\273.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(0) - \345\257\274\350\257\273.md"
new file mode 100644
index 0000000000..459a4dbcb6
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(0) - \345\257\274\350\257\273.md"	
@@ -0,0 +1,20 @@
+
+一般来说，互联网的面试，一般都会考察你，什么是分布式系统，高并发，简单的高可用问题
+
+限流、熔断、降级，在分布式的系统架构中，微服务架构中，其实都是最常见、基础和简单的保障系统高可用的手法。dubbo去开发了，spring cloud去开发了，在这个系统的接口调用中，我们是用hystrix去实现一整套的高可用保障机制，基于hystrix做限流、熔断和降级。
+
+hystrix是国外的netflix开源的，netflix是国外很大的视频网站，系统非常复杂，微服务架构，多达几千个服务，为自己的场景，经过大量的工业验证，线上生产环境的实践，产出和开源了高可用相关的一个框架，熔断框架，hystrix。
+
+hystrix未来会成为国内的高可用的限流、熔断和降级这一块的事实上的标准，spring cloud微服务框架，就是集成了hystrix来做微服务架构中的限流、降级和熔断的。
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(1) - hystrix\344\270\216\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\357\274\232\350\265\204\346\272\220\351\232\224\347\246\273+\351\231\220\346\265\201+\347\206\224\346\226\255+\351\231\215\347\272\247+\350\277\220\347\273\264\347\233\221\346\216\247.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(1) - hystrix\344\270\216\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\357\274\232\350\265\204\346\272\220\351\232\224\347\246\273+\351\231\220\346\265\201+\347\206\224\346\226\255+\351\231\215\347\272\247+\350\277\220\347\273\264\347\233\221\346\216\247.md"
new file mode 100644
index 0000000000..c7766bec3d
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(1) - hystrix\344\270\216\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\357\274\232\350\265\204\346\272\220\351\232\224\347\246\273+\351\231\220\346\265\201+\347\206\224\346\226\255+\351\231\215\347\272\247+\350\277\220\347\273\264\347\233\221\346\216\247.md"	
@@ -0,0 +1,54 @@
+# 1 hystrix是什么？
+Netflix（国外最大的类似于，爱奇艺，优酷）视频网站，五六年前，也是，感觉自己的系统，整个网站，经常出故障，可用性不太高
+有时候一些vip会员不能支付，有时候看视频就卡顿，看不了视频。。。
+影响公司的收入!!!
+五六年前，netflix，api team，提升高可用性，开发了一个框架，类似于spring，mybatis，hibernate，等等这种框架
+
+> 高可用性的框架，hystrix
+
+hystrix，框架，提供了高可用相关的各种各样的功能，然后确保说在hystrix的保护下，整个系统可以长期处于高可用的状态
+最理想的状况下，软件的故障，就不应该说导致整个系统的崩溃，服务器硬件的一些故障，服务的冗余
+唯一有可能导致系统彻底崩溃，就是类似于之前，支付宝的那个事故，工人施工，挖断了电缆，导致几个机房都停电
+不可用，和产生一些故障或者bug的区别
+
+# 2 高可用系统架构
+
+## 2.1 资源隔离
+让你的系统里，某一块东西，在故障的情况下，不会耗尽系统所有的资源，比如线程资源
+
+项目中的一个case，有一块东西，是要用多线程做一些事情，小伙伴做项目的时候，没有太留神，资源隔离，那块代码，在遇到一些故障的情况下，每个线程在跑的时候，因为那个bug，直接就死循环了，导致那块东西启动了大量的线程，每个线程都死循环
+
+最终导致系统资源耗尽，崩溃，不工作，不可用，废掉了
+
+资源隔离，那一块代码，最多最多就是用掉10个线程，不能再多了，就废掉了，限定好的一些资源
+
+## 2.2 限流
+高并发的流量涌入进来，比如说突然间一秒钟100万QPS，废掉了，10万QPS进入系统，其他90万QPS被拒绝了
+
+## 2.3  熔断
+系统后端的一些依赖，出了一些故障，比如说MySQL宕机，每次请求都是报错的，熔断了，后续的请求过来直接不接收了，拒绝访问，10分钟之后再尝试去看看MySQL恢复没有
+
+## 2.4  降级
+MySQL挂了，系统发现了，自动降级，从内存里存的少量数据中，去提取一些数据出来
+
+## 2.5  运维监控
+监控+报警+优化，各种异常的情况，有问题就及时报警，优化一些系统的配置和参数，或者代码
+
+如果你的各种依赖的服务有了故障，那么很可能会导致你的系统不可用
+
+hystrix对系统进行各种高可用性的系统加固，来应对各种不可用的情况
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
+
+
+
+
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(2) - hystrix\350\246\201\350\247\243\345\206\263\347\232\204\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\351\227\256\351\242\230\344\273\245\345\217\212\345\205\266\350\256\276\350\256\241\345\216\237\345\210\231.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(2) - hystrix\350\246\201\350\247\243\345\206\263\347\232\204\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\351\227\256\351\242\230\344\273\245\345\217\212\345\205\266\350\256\276\350\256\241\345\216\237\345\210\231.md"
new file mode 100644
index 0000000000..9e87518b1d
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(2) - hystrix\350\246\201\350\247\243\345\206\263\347\232\204\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\345\217\257\347\224\250\346\200\247\351\227\256\351\242\230\344\273\245\345\217\212\345\205\266\350\256\276\350\256\241\345\216\237\345\210\231.md"	
@@ -0,0 +1,103 @@
+# 1 导读
+
+高可用性这个topic，然后咱们会用几讲的时间来讲解一下如何用hystrix，来构建高可用的服务的架构
+
+咱们会用一个真实的项目背景，作为业务场景，来带出来在这个特定的业务场景下，可能会产生哪些各种各样的可用性的一些问题
+
+针对这些问题，我们用hystrix的解决方案和原理是什么
+
+带着大家，纯手工将所有的服务的高可用架构的代码，全部纯手工自己敲出来
+
+形成高可用服务架构的项目实战的一个教程
+
+# 2 Hystrix是什么
+
+在分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很常见的。
+
+Hystrix可以让我们在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。
+
+Hystrix通过将依赖服务进行**资源隔离**，进而避免某个依赖服务出现故障的时候，在整个系统所有的依赖服务调用中蔓延，同时Hystrix还提供故障时的fallback降级机制
+
+总而言之，Hystrix通过这些方法帮助我们提升分布式系统的可用性和稳定性
+
+- 什么是分布式系统以及其中的故障和hystrix
+![](https://ask.qcloudimg.com/http-save/1752328/d1razflqky.png)
+
+# 3 Hystrix的历史
+
+hystrix，一种高可用保障的框架，类似于spring（ioc，mvc），mybatis，activiti，lucene，框架，预先封装好的为了解决某个特定领域的特定问题的一套代码库
+
+框架，用了框架之后，来解决这个领域的特定的问题，就可以大大减少我们的工作量，提升我们的工作质量和工作效率，框架,hystrix，就是高可用性保障的一个框架
+
+Netflix（可以认为是国外的优酷或者爱奇艺之类的视频网站），API团队从2011年开始做一些提升系统可用性和稳定性的工作，Hystrix就是从那时候开始发展出来的。
+
+在2012年的时候，Hystrix就变得比较成熟和稳定了，Netflix中，除了API团队以外，很多其他的团队都开始使用Hystrix。
+
+时至今日，Netflix中每天都有数十亿次的服务间调用，通过Hystrix框架在进行，而Hystrix也帮助Netflix网站提升了整体的可用性和稳定性
+
+2018 年 11 月，Hystrix 在其 [Github 主页](https://github.com/Netflix/Hystrix/blob/master/README.md#hystrix-status)宣布，不再开放新功能，推荐开发者使用其他仍然活跃的开源项目。维护模式的转变绝不意味着 Hystrix 不再有价值。相反，Hystrix 激发了很多伟大的想法和项目，其思想仍值得我们深入学习!
+
+# 4 Hystrix的设计原则
+
+- 对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
+- 在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了，服务A故障了，整套分布式系统全部故障，整体宕机
+- 提供fail-fast（快速失败）和快速恢复的支持
+- 提供fallback优雅降级的支持
+- 支持近实时的监控、报警以及运维操作5 Hystrix要解决的问题在复杂的分布式系统架构中，每个服务都有很多的依赖服务，而每个依赖服务都可能会故障
+如果服务没有和自己的依赖服务进行隔离，那么可能某一个依赖服务的故障就会拖垮当前这个服务
+
+举例来说
+
+某个服务有30个依赖服务，每个依赖服务的可用性非常高，已经达到了99.99%的高可用性
+
+那么该服务的可用性就是99.99%的30次方，也就是99.7%的可用性
+
+99.7%的可用性就意味着3%的请求可能会失败，因为3%的时间内系统可能出现了故障不可用了
+
+对于1亿次访问来说，3%的请求失败，也就意味着300万次请求会失败，也意味着每个月有2个小时的时间系统是不可用的
+
+在真实生产环境中，可能更加糟糕
+
+上面也就是说，即使你每个依赖服务都是99.99%高可用性，但是一旦你有几十个依赖服务，还是会导致你每个月都有几个小时是不可用的
+
+画图分析说，当某一个依赖服务出现了调用延迟或者调用失败时，为什么会拖垮当前这个服务？以及在分布式系统中，故障是如何快速蔓延的？
+
+- 依赖服务的故障导致服务被拖垮以及故障的蔓延示意图
+![](https://ask.qcloudimg.com/http-save/1752328/twu9s9m6xx.png)
+
+# 6 Hystrix的更加细节的设计原则
+
+- 阻止任何一个依赖服务耗尽所有的资源，比如tomcat中的所有线程资源
+- 避免请求排队和积压，采用限流和fail fast来控制故障
+- 提供fallback降级机制来应对故障
+- 使用资源隔离技术，比如bulkhead（舱壁隔离技术），swimlane（泳道技术），circuit breaker（短路技术），来限制任何一个依赖服务的故障的影响
+- 通过近实时的统计/监控/报警功能，来提高故障发现的速度
+- 通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度
+- 保护依赖服务调用的所有故障情况，而不仅仅只是网络故障情况
+
+调用这个依赖服务的时候，client调用包有bug，阻塞，等等，依赖服务的各种各样的调用的故障，都可以处理
+
+# 7 Hystrix如何实现它的目标
+
+- 通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离
+- 对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间，但是一般我们可以自己设置一下
+- 为每一个依赖服务维护一个独立的线程池，或者是semaphore，当线程池已满时，直接拒绝对这个服务的调用
+- 对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计
+- 如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复
+- 当一个服务调用出现失败，被拒绝，超时，短路等异常情况时，自动调用fallback降级机制
+- 对属性和配置的修改提供近实时的支持
+
+画图分析，对依赖进行资源隔离后，如何避免依赖服务调用延迟或失败导致当前服务的故障
+
+- 资源隔离如何保护依赖服务的故障不要拖垮整个系统![](https://ask.qcloudimg.com/http-save/1752328/0tx22cj2bs.png)
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(3) -\347\224\265\345\225\206\345\225\206\345\223\201\350\257\246\346\203\205\351\241\265\347\274\223\345\255\230\350\203\214\346\231\257\345\217\212\346\241\206\346\236\266\350\257\264\346\230\216.md" "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(3) -\347\224\265\345\225\206\345\225\206\345\223\201\350\257\246\346\203\205\351\241\265\347\274\223\345\255\230\350\203\214\346\231\257\345\217\212\346\241\206\346\236\266\350\257\264\346\230\216.md"
new file mode 100644
index 0000000000..e5a4d25133
--- /dev/null
+++ "b/\351\235\242\350\257\225\347\263\273\345\210\227/\351\253\230\345\217\257\347\224\250\347\263\273\347\273\237\346\236\266\346\236\204\347\232\204\350\256\276\350\256\241/\351\253\230\345\217\257\347\224\250\346\236\266\346\236\204\350\256\276\350\256\241(3) -\347\224\265\345\225\206\345\225\206\345\223\201\350\257\246\346\203\205\351\241\265\347\274\223\345\255\230\350\203\214\346\231\257\345\217\212\346\241\206\346\236\266\350\257\264\346\230\216.md"	
@@ -0,0 +1,130 @@
+# [Github](https://github.com/Wasabi1234)
+
+# 0 导读
+
+我们这个教程，基于hystrix，如何来构建高可用的分布式系统的架构，项目实战
+
+模拟真实业务的这么一个小型的项目，来全程贯穿，用这个项目中的业务场景去一个一个的讲解hystrix高可用的每个技术
+
+纯讲hystrix，脱离实际的业务背景，听起来有点枯燥，大家学完了hystrix以后，可能没法完全感受到技术是如何融入我们的项目中的
+
+大背景：电商网站，首页，商品详情页，搜索结果页，广告页，促销活动，购物车，订单系统，库存系统，物流系统
+
+小背景：商品详情页，如何用最快的结果将商品数据填充到一个页面中，然后将页面显示出来
+
+分布式系统：商品详情页，缓存服务，+底层源数据服务，商品信息服务，店铺信息服务，广告信息服务，推荐信息服务，综合起来组成一个分布式的系统
+
+# 1 电商网站的商品详情页系统架构
+
+## 1.1 小型电商网站的商品详情页系统架构(非重点)
+
+![](https://ask.qcloudimg.com/http-save/1752328/g8fb1n804c.png)
+
+## 1.2 大型电商网站的商品详情页系统架构
+
+大型电商网站商品详情页的系统设计中，当商品数据发生变更时，会将变更消息压入消息队列中。
+
+缓存服务从消息队列中消费这条消息时，感知到有数据发生变更，便通过调用数据服务接口，获取变更后的数据，然后将整合好的数据推送至 redis 中。
+
+Nginx 本地缓存的数据是有一定的时间期限的，比如说 10 分钟，当数据过期之后，它就会从 redis 获取到最新的缓存数据，并且缓存到自己本地。
+
+用户浏览网页时，动态将 Nginx 本地数据渲染到本地 html 模板并返回给用户。
+
+虽然没有直接返回 html 页面那么快，但是因为数据在本地缓存，所以也很快，其实耗费的也就是动态渲染一个 html 页面的性能。如果 html 模板发生了变更，不需要将所有的页面重新静态化，也不需要发送请求，没有网络请求的开销，直接将数据渲染进最新的 html 页面模板后响应即可。
+
+在这种架构下，我们需要保证系统的高可用性。
+
+如果系统访问量很高，Nginx 本地缓存过期失效了，redis 中的缓存也被 LRU 算法给清理掉了，那么会有较高的访问量，从缓存服务调用商品服务。但如果此时商品服务的接口发生故障，调用出现了延时，缓存服务全部的线程都被这个调用商品服务接口给耗尽了，每个线程去调用商品服务接口的时候，都会卡住很长时间，后面大量的请求过来都会卡在那儿，此时缓存服务没有足够的线程去调用其它一些服务的接口，从而导致整个大量的商品详情页无法正常显示。
+
+这其实就是一个商品接口服务故障导致缓存服务资源耗尽的现象。
+
+![](https://ask.qcloudimg.com/http-save/1752328/37fnr6h5uu.png)
+
+## 1.3 页面模板
+
+举个例子
+
+将数据动态填充/渲染到一个html模板中，是什么意思呢？
+
+```
+<html>
+	<title>#{name}的页面</title>
+	<body>
+		商品的价格是：#{price}
+		商品的介绍：#{description}
+	</body>
+</html>
+```
+
+上面这个就可以认为是一个页面模板，里面的很多内容是不确定的，#{name}，#{price}，#{description}，这都是一些模板脚本，不确定里面的值是什么？
+
+将数据填充/渲染到html模板中，是什么意思呢？
+
+```
+{
+	"name": "iphone7 plus（玫瑰金+32G）",
+	"price": 5599.50
+	"description": "这个手机特别好用。。。。。。"
+}
+
+<html>
+	<title>iphone7 plus（玫瑰金+32G）的页面</title>
+	<body>
+		商品的价格是：5599.50
+		商品的介绍：这个手机特别好用。。。。。。
+	</body>
+</html>
+```
+
+上面这个就是一份填充好数据的一个html页面
+
+# 2 缓存服务
+
+缓存服务，订阅一个MQ的消息变更，如果有消息变更的话，那么就会发送一个网络请求，调用一个底层的对应的源数据服务的接口，去获取变更后的数据
+
+将获取到的变更后的数据填充到分布式的redis缓存中去
+
+高可用这一块儿，最可能出现说可用性不高的情况，是什么呢？
+
+就是说，在接收到消息之后，可能在调用各种底层依赖服务的接口时，会遇到各种不稳定的情况
+
+比如底层服务的接口调用超时，200ms，2s都没有返回; 底层服务的接口调用失败，比如说卡了500ms之后，返回一个报错
+
+在分布式系统中，对于这种大量的底层依赖服务的调用，就可能会出现各种可用性的问题，一旦没有处理好的话
+
+可能就会导致缓存服务自己本身会挂掉，或者故障掉，就会导致什么呢？
+
+不可以对外提供服务，严重情况下，甚至会导致说整个商品详情页显示不出来
+
+缓存服务接收到变更消息后，去调用各个底层依赖服务时的高可用架构的实现
+
+我们刚才讲解的整套大型电商网站的商品详情页的缓存架构，完整的那个流程，《亿级流量电商详情页系统的大型高并发与高可用缓存架构实战》
+
+# 3 框架结构
+
+围绕着缓存服务去拉取各种底层的源数据服务的数据，调用其接口时，可能出现的系统不可用的问题
+
+从简
+
+spring boot，微服务的非常快速，非常好用的技术框架，脱胎于spring，具体的东西就不讲解，直接带着大家上手搭建一个spring boot的框架
+
+2个服务，缓存服务，商品服务，缓存服务依赖于商品服务
+
+模拟各种商品服务可能接口调用时出现的各种问题，导致系统不可用的场景，然后用hystrix完整的各种技术点全部贯穿在里面
+
+解决了一大堆设计业务背景下的系统不可用问题，hystrix整个技术体系，知识体系，也就讲解完了
+
+消息队列，redis，咱们都不搞了
+
+spring boot + http client + hystrix
+
+# 参考
+
+- 《Java工程师面试突击第1季-中华石杉老师》
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](http://www.shishusheng.com)
+
+## [Github](https://github.com/Wasabi1234)

From c586bd0103060b3782e573027142c126468915c2 Mon Sep 17 00:00:00 2001
From: Wasabi1234 <sss2855845850@gmail.com>
Date: Mon, 5 Aug 2019 00:51:02 +0800
Subject: [PATCH 2/7] =?UTF-8?q?=E6=9B=B4=E6=96=B0README=E6=96=87=E4=BB=B6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .gitignore            | 26 ++++++++++++++++++++++++++
 JavaEdge-Tutorial.iml | 12 ++++++++++++
 README.md             | 37 +++++++++++++++++++++++++++++++++++++
 3 files changed, 75 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 JavaEdge-Tutorial.iml
 create mode 100644 README.md

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..9a016ff1bf
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,26 @@
+# Created by .ignore support plugin (hsz.mobi)
+### Java template
+# Compiled class file
+*.class
+
+# Log file
+*.log
+
+# BlueJ files
+*.ctxt
+
+# Mobile Tools for Java (J2ME)
+.mtj.tmp/
+
+# Package Files #
+*.jar
+*.war
+*.nar
+*.ear
+*.zip
+*.tar.gz
+*.rar
+
+# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
+hs_err_pid*
+
diff --git a/JavaEdge-Tutorial.iml b/JavaEdge-Tutorial.iml
new file mode 100644
index 0000000000..d5c0743275
--- /dev/null
+++ b/JavaEdge-Tutorial.iml
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module type="JAVA_MODULE" version="4">
+  <component name="NewModuleRootManager" inherit-compiler-output="true">
+    <exclude-output />
+    <content url="file://$MODULE_DIR$">
+      <sourceFolder url="file://$MODULE_DIR$/src" isTestSource="false" />
+    </content>
+    <orderEntry type="inheritedJdk" />
+    <orderEntry type="sourceFolder" forTests="false" />
+  </component>
+</module>
+
diff --git a/README.md b/README.md
new file mode 100644
index 0000000000..51fdd7bbe8
--- /dev/null
+++ b/README.md
@@ -0,0 +1,37 @@
+点击订阅[JavaEdge](https://xiaozhuanlan.com/JavaEdge)(专为志于成为Java架构师同学准备)。
+
+点击关注[公众号](#公众号)
+
+## 目录
+
+- [Java](#java)
+    - [JVM](#jvm)
+    - [Spring](#Spring)
+    - [Spring Boot](#Spring Boot)
+    - [Spring Cloud](#Spring Cloud)
+    - [并发编程](#并发编程)
+    - [集合框架](#集合框架)
+- [职业发展](#职业发展)
+- [面试系列](#面试系列)
+
+# 公众号
+
+及时关注最新博客，记得关注公众号哦
+
+JavaEdge
+
+# 笔者简介
+### 华为南研所 - 麒麟解决方案平台软件开发部 - IT应用开发工程师
+### [慕课网认证作者](https://www.imooc.com/u/2396649/articles)
+![](https://img-blog.csdnimg.cn/20190712131328738.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
+![](https://img-blog.csdnimg.cn/20190712130807280.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70)
+![](https://img-blog.csdnimg.cn/20190712131221721.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70)
+
+### [阿里云栖社区博客专家](https://yq.aliyun.com/users/article?spm=a2c4e.8091938.headeruserinfo.3.65993d6eqaQ0O6)
+![](https://img-blog.csdnimg.cn/20190712131824494.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70)
+
+### [腾讯云自媒体邀约计划作者](https://cloud.tencent.com/developer/user/1752328)
+![](https://img-blog.csdnimg.cn/20190712140323352.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70)
+
+[简书程序员专题推荐作者](https://www.jianshu.com/u/32c7d1f520c2)
+![](https://img-blog.csdnimg.cn/2019071214051427.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)

From 316ced26986590742c8263a8db33c6b4d1d57171 Mon Sep 17 00:00:00 2001
From: JavaEdge <sss2855845850@gmail.com>
Date: Thu, 8 Aug 2019 23:00:32 +0800
Subject: [PATCH 3/7] Update README.md

---
 README.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/README.md b/README.md
index 51fdd7bbe8..78b735d793 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,3 @@
-点击订阅[JavaEdge](https://xiaozhuanlan.com/JavaEdge)(专为志于成为Java架构师同学准备)。
-
 点击关注[公众号](#公众号)
 
 ## 目录

From 5a7578329ccb8899478d54d821f4d0341e497ae3 Mon Sep 17 00:00:00 2001
From: Wasabi1234 <sss2855845850@gmail.com>
Date: Sat, 10 Aug 2019 19:56:42 +0800
Subject: [PATCH 4/7] =?UTF-8?q?=E6=9B=B4=E6=96=B0README=E6=96=87=E4=BB=B6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 51fdd7bbe8..0c18fecdfe 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,18 @@
-点击订阅[JavaEdge](https://xiaozhuanlan.com/JavaEdge)(专为志于成为Java架构师同学准备)。
+# 0 JavaEdge - Java程序员充电、求职必备的核心知识库
+
+全方位详细深入阐述从入门到高级Java程序员必备的知识技能。
+
+按照现有计划，主要研究如下方面知识点： 
+
+0. Java SE重难点、包含但不限于集合、多线程、泛型、反射、I/O； 
+1. Java Web重难点，包含但不限于Servlet、JSP、Tomcat、Jetty ；
+2. Java EE开发流行框架，包含但不限于Spring、MyBatis、Hibernate、Vert.X；
+3. 计算机理论基础，包含但不限于计算机操作系统（Linux）、计算机网络、常见的数据结构与算法（Java实现） ；
+4.数据存储组件的基本操作与原理探究，包含但不限于MySQL、Redis、Kafka、Hive、HBase ；
+5. 分布式、微服务时下流行框架及理论，包含但不限于CAP理论及其相关算法、Zookeeper、Spring Cloud Alibaba、Dubbo；
+6. 编程设计模式思想及其在各种框架中的实际应用（Java实现） 
+7. 其他Java程序员提高自身竞争力的知识点技能......
+
 
 点击关注[公众号](#公众号)
 
@@ -7,8 +21,8 @@
 - [Java](#java)
     - [JVM](#jvm)
     - [Spring](#Spring)
-    - [Spring Boot](#Spring Boot)
-    - [Spring Cloud](#Spring Cloud)
+    - [Spring Boot](#SpringBoot)
+    - [Spring Cloud](#SpringCloud)
     - [并发编程](#并发编程)
     - [集合框架](#集合框架)
 - [职业发展](#职业发展)
@@ -21,7 +35,7 @@
 JavaEdge
 
 # 笔者简介
-### 华为南研所 - 麒麟解决方案平台软件开发部 - IT应用开发工程师
+### 华为 - IT应用开发工程师
 ### [慕课网认证作者](https://www.imooc.com/u/2396649/articles)
 ![](https://img-blog.csdnimg.cn/20190712131328738.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_16,color_FFFFFF,t_70)
 ![](https://img-blog.csdnimg.cn/20190712130807280.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70)

From 305d3ea5cac79a65a9528e90bc5ec4453593bcb4 Mon Sep 17 00:00:00 2001
From: Wasabi1234 <sss2855845850@gmail.com>
Date: Sat, 10 Aug 2019 23:08:17 +0800
Subject: [PATCH 5/7] =?UTF-8?q?=E6=9B=B4=E6=96=B0README=E6=96=87=E4=BB=B6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index 0c18fecdfe..421873779f 100644
--- a/README.md
+++ b/README.md
@@ -4,6 +4,7 @@
 
 按照现有计划，主要研究如下方面知识点： 
 
+
 0. Java SE重难点、包含但不限于集合、多线程、泛型、反射、I/O； 
 1. Java Web重难点，包含但不限于Servlet、JSP、Tomcat、Jetty ；
 2. Java EE开发流行框架，包含但不限于Spring、MyBatis、Hibernate、Vert.X；

From 55f65b7d04f44a17daffdeeaf9238d19a6e898ea Mon Sep 17 00:00:00 2001
From: Wasabi1234 <sss2855845850@gmail.com>
Date: Thu, 29 Aug 2019 01:01:30 +0800
Subject: [PATCH 6/7] =?UTF-8?q?=E6=B7=BB=E5=8A=A0=20=E8=AE=A1=E7=AE=97?=
 =?UTF-8?q?=E6=9C=BA=E7=BB=84=E6=88=90=E5=8E=9F=E7=90=86=20=E4=B8=93?=
 =?UTF-8?q?=E9=A2=98?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md                                     |   1 +
 ...23\347\263\273\347\273\223\346\236\204.md" | 211 ++++++++++
 ...ws\344\270\213\350\277\220\350\241\214.md" | 164 ++++++++
 ...2\347\232\204\346\200\247\350\203\275!.md" | 273 +++++++++++++
 ...50\346\200\201\351\223\276\346\216\245.md" | 220 ++++++++++
 ...75\342\200\235\344\271\213\345\267\205.md" | 382 ++++++++++++++++++
 ...07\344\273\244\345\256\236\347\216\260.md" | 268 ++++++++++++
 ...17\347\232\204\350\243\205\350\275\275.md" | 162 ++++++++
 ...347\204\266Stack Overflow\344\272\206!.md" | 309 ++++++++++++++
 ...\351\207\214\344\274\240\351\237\263\".md" | 134 ++++++
 ...01\347\232\204\347\224\261\346\235\245.md" | 153 +++++++
 ...70\345\270\246\347\274\226\347\250\213.md" | 229 +++++++++++
 12 files changed, 2506 insertions(+)
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\200\357\274\211- \345\206\257\302\267\350\257\272\344\276\235\346\233\274\344\275\223\347\263\273\347\273\223\346\236\204.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\203\357\274\211- \347\250\213\345\272\217\346\227\240\346\263\225\345\220\214\346\227\266\345\234\250Linux\345\222\214Windows\344\270\213\350\277\220\350\241\214.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\211\357\274\211- \350\277\233\345\207\273,\346\233\264\345\274\272\347\232\204\346\200\247\350\203\275!.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\271\235\357\274\211- \345\212\250\346\200\201\351\223\276\346\216\245.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\214\357\274\211- \345\210\266\345\256\232\345\255\246\344\271\240\350\267\257\347\272\277\357\274\214\346\224\200\347\231\273\342\200\234\346\200\247\350\203\275\342\200\235\344\271\213\345\267\205.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\224\357\274\211- \"\346\227\213\350\275\254\350\267\263\350\267\203\"\347\232\204\346\214\207\344\273\244\345\256\236\347\216\260.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\253\357\274\211- \347\250\213\345\272\217\347\232\204\350\243\205\350\275\275.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\255\357\274\211- \345\207\275\346\225\260\350\260\203\347\224\250\346\200\216\344\271\210\347\252\201\347\204\266Stack Overflow\344\272\206!.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\344\270\200\357\274\211- \351\227\250\347\224\265\350\267\257\347\232\204\"\345\215\203\351\207\214\344\274\240\351\237\263\".md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\357\274\211- \"\347\203\253\347\203\253\347\203\253\"\344\271\261\347\240\201\347\232\204\347\224\261\346\235\245.md"
 create mode 100644 "\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\233\233\357\274\211- \347\216\251\347\216\251\347\272\270\345\270\246\347\274\226\347\250\213.md"

diff --git a/README.md b/README.md
index 421873779f..80ce0b2047 100644
--- a/README.md
+++ b/README.md
@@ -27,6 +27,7 @@
     - [并发编程](#并发编程)
     - [集合框架](#集合框架)
 - [职业发展](#职业发展)
+- [计算机组成原理](#计算机组成原理)
 - [面试系列](#面试系列)
 
 # 公众号
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\200\357\274\211- \345\206\257\302\267\350\257\272\344\276\235\346\233\274\344\275\223\347\263\273\347\273\223\346\236\204.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\200\357\274\211- \345\206\257\302\267\350\257\272\344\276\235\346\233\274\344\275\223\347\263\273\347\273\223\346\236\204.md"
new file mode 100644
index 0000000000..af4dee4786
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\200\357\274\211- \345\206\257\302\267\350\257\272\344\276\235\346\233\274\344\275\223\347\263\273\347\273\223\346\236\204.md"	
@@ -0,0 +1,211 @@
+![](https://ask.qcloudimg.com/http-save/1752328/g6cdrb45jg.png)
+
+# 1 计算机的基本硬件组成
+
+早期,DIY一台计算机，要先有三大件
+
+- CPU
+- 内存
+- 主板
+
+## 1.1 CPU
+
+计算机最重要的核心配件，中央处理器（Central Processing Unit）。
+
+计算机的所有“计算”都是由CPU来进行的。
+
+- CPU是一个超级精细的印刷电路版
+![](https://ask.qcloudimg.com/http-save/1752328/1ya6ng3q8l.png)
+
+## 1.2 内存（Memory）
+
+你撰写的程序、打开的浏览器、运行的游戏，都要加载到内存里才能运行。
+
+程序读取的数据、计算得到的结果，也都要放在内存里。内存越大，能加载的东西自然也就越多。
+
+内存通常直接可以插在主板上，存放在内存里的程序和数据，需要被CPU读取，CPU计算完之后，还要把数据写回到内存。然而CPU不能直接插到内存上，反之亦然。于是，就带来了最后一个大件——主板（Motherboard）。
+
+- 内存通常直接可以插在主板上
+![](https://ask.qcloudimg.com/http-save/1752328/fzz62il1s0.png)
+
+## 1.3 主板
+
+主板是一个有着各种各样，有时候多达数十乃至上百个插槽的配件。
+
+我们的CPU要插在主板上，内存也要插在主板上。
+
+主板的芯片组（Chipset）和总线（Bus）解决了CPU和内存之间如何通信的问题。
+
+- 芯片组控制了数据传输的流转，也就是数据从哪里到哪里的问题
+- 总线则是实际数据传输的高速公路。总线速度（Bus Speed）决定了数据能传输得多快。
+- 计算机主板上通常有着各种各样的插槽![](https://ask.qcloudimg.com/http-save/1752328/lyress98vj.png)
+
+有了三大件，只要配上**电源**供电，计算机差不多就可以跑起来了。
+
+但是现在还缺少各类输入（Input）/输出（Output）设备，也就是我们常说的**I/O设备**。
+
+如果你用的是自己的个人电脑，那显示器肯定必不可少，只有有了显示器我们才能看到计算机输出的各种图像、文字，这也就是所谓的**输出设备**。
+
+同样的，鼠标和键盘也都是必不可少的配件。这样我才能输入文本，写下这篇文章。它们也就是所谓的**输入设备**。
+
+最后，你自己配的个人计算机，还要配上一个硬盘。这样各种数据才能持久地保存下来。
+
+绝大部分人都会给自己的机器装上一个机箱，配上风扇，解决灰尘和散热的问题。
+
+不过机箱和风扇，算不上是计算机的必备硬件，我们拿个纸板或者外面放个电风扇，也一样能用。
+
+显示器、鼠标、键盘和硬盘这些东西并不是一台计算机必须的部分。
+
+其实只需要有I/O设备，能让我们从计算机里输入和输出信息就可以了。
+
+很多网吧的计算机就没有硬盘，而是直接通过局域网，读写远程网络硬盘里面的数据。
+
+各类云服务器，只要让计算机能通过网络，SSH远程登陆访问就好了，因此也没必要配显示器、鼠标、键盘这些东西。
+
+这样不仅能够节约成本，还更方便维护。
+
+还有一个很特殊的设备，就是**显卡**（Graphics Card）。
+
+现在，使用图形界面操作系统的计算机，无论是Windows、Mac OS还是Linux，显卡都是必不可少的。
+
+有人可能要说了，我装机的时候没有买显卡，计算机一样可以正常跑起来啊！那是因为，现在的主板都带了内置的显卡。
+
+如果你用计算机玩游戏，做图形渲染或者跑深度学习应用，你多半就需要买一张单独的显卡，插在主板上。
+
+显卡之所以特殊，是因为显卡里有除了CPU之外的另一个“处理器”，也就是GPU（Graphics Processing Unit，图形处理器），GPU一样可以做各种“计算”的工作。
+
+鼠标、键盘以及硬盘都是插在主板上的。作为外部I/O设备，它们是通过主板上的**南桥**（SouthBridge）芯片组，来控制和CPU之间的通信的。
+
+“南桥”芯片的名字很直观
+
+- 它在主板上的位置，通常在主板的“南面”
+- 它的作用就是作为“桥”，来连接鼠标、键盘以及硬盘这些外部设备和CPU之间的通信。
+
+有了南桥，自然对应着也有“北桥”。
+
+是的，以前的主板上通常也有“北桥”芯片，用来作为“桥”，连接CPU和内存、显卡之间的通信。
+
+不过，随着时间的变迁，现在的主板上的“北桥”芯片的工作，已经被移到了CPU的内部，所以你在主板上，已经看不到北桥芯片了。
+
+# 2 冯·诺依曼体系结构
+
+刚才我们讲了一台计算机的硬件组成，这说的是我们平时用的个人电脑或者服务器。那我们平时最常用的智能手机的组成，也是这样吗？
+
+我们手机里只有SD卡（Secure Digital Memory Card）类似硬盘功能的存储卡插槽，并没有内存插槽、CPU插槽这些东西。
+
+没错，因为手机尺寸的原因，手机制造商们选择把
+
+CPU、内存、网络通信，乃至摄像头芯片，都封装到一个芯片，然后再嵌入到手机主板上。
+
+这种方式叫**SoC**，也就是System on a Chip（系统芯片）。
+
+看起来，个人电脑和智能手机的硬件组成方式不太一样。
+
+可是，我们写智能手机上的App，和写个人电脑的客户端应用似乎没有什么差别，都是通过“高级语言”这样的编程语言撰写、编译之后，一样是把代码和数据加载到内存里来执行。
+
+无论是个人电脑/服务器/智能手机，还是Raspberry Pi这样的微型卡片机，都遵循着同一个“计算机”的抽象概念。
+
+这是怎么样一个“计算机”呢？这其实就是，计算机鼻祖冯·诺依曼提出的**冯·诺依曼体系结构**（Von Neumann architecture），也叫**存储程序计算机**。
+
+什么是存储程序计算机呢？这里面其实暗含了两个概念
+
+- “可编程”计算机
+- “存储”计算机
+
+什么是“不可编程”？？？
+
+计算机是由各种门电路组合而成的，然后通过组装出一个固定的电路版，完成一个特定的计算程序。
+
+一旦需要修改功能，就要重新组装电路。这样的话，计算机就是“不可编程”的，因为程序在计算机硬件层面是“写死”的。
+
+最常见的就是老式计算器，电路板设好了加减乘除，做不了任何计算逻辑固定之外的事情。
+
+- 计算器的本质是一个不可编程的计算机
+![](https://ask.qcloudimg.com/http-save/1752328/efi2z2i6f1.png)
+
+我们再来看“存储”计算机。
+
+程序本身是存储在计算机的内存里，可以通过加载不同的程序来解决不同的问题。
+
+有“存储程序计算机”，自然也有不能存储程序的计算机。
+
+典型的就是早年的“Plugboard”这样的插线板式的计算机。整个计算机就是一个巨大的插线板，通过在板子上不同的插头或者接口的位置插入线路，来实现不同的功能。这样的计算机自然是“可编程”的，但是编写好的程序不能存储下来供下一次加载使用，不得不每次要用到和当前不同的“程序”的时候，重新插板子，重新“编程”。
+
+- 著名的Engima Machine就用到了Plugboard来进行“编程”
+![](https://ask.qcloudimg.com/http-save/1752328/tni9s3p8vf.png)
+可以看到，无论是“不可编程”还是“不可存储”，都会让使用计算机的效率大大下降。
+而这个对于效率的追求，也就是“存储程序计算机”的由来。
+
+冯，基于当时在秘密开发的EDVAC写了一篇报告First Draft of a Report on the EDVAC，描述了他心目中的一台计算机应该长什么样。这篇报告在历史上有个很特殊的简称，叫First Draft。这样，现代计算机的发展就从祖师爷写的一份草案开始了。
+
+#### First Draft里面说了一台计算机应该有哪些部分组成
+
+首先是一个包含
+
+- 算术逻辑单元（Arithmetic Logic Unit，ALU）
+- 处理器寄存器（Processor Register）
+
+的**处理器单元**（Processing Unit），用来完成各种算术和逻辑运算。
+
+因为它能够完成各种数据的处理或者计算工作，因此也有人把这个叫作数据通路（Datapath）或者运算器。
+
+然后是一个包含
+
+- 指令寄存器（Instruction Reigster）
+- 程序计数器（Program Counter）
+
+的**控制器单元**（Control Unit/CU），用来控制程序的流程，通常就是不同条件下的分支和跳转。
+
+在现在的计算机里，上面的算术逻辑单元和这里的控制器单元，共同组成了我们说的CPU。
+
+接着是用来存储数据（Data）和指令（Instruction）的**内存**。以及更大容量的**外部存储**，在过去，可能是磁带、磁鼓这样的设备，现在通常就是硬盘。
+
+最后就是各种**输入和输出设备**，以及对应的输入和输出机制。
+
+我们现在无论是使用什么样的计算机，其实都是和输入输出设备在打交道。
+
+- 个人电脑的鼠标键盘是输入设备，显示器是输出设备
+- 我们用的智能手机，触摸屏既是输入设备，又是输出设备
+- 跑在各种云上的服务器，则是通过网络来进行输入和输出。这个时候，网卡既是输入设备又是输出设备
+
+> 任何一台计算机的任何一个部件都可以归到运算器、控制器、存储器、输入设备和输出设备中，而所有的现代计算机也都是基于这个基础架构来设计开发的
+
+而所有的计算机程序，也都可以抽象为从**输入设备**读取输入信息，通过**运算器**和**控制器**来执行存储在**存储器**里的程序，最终把结果输出到**输出设备**中。而我们所有撰写的无论高级还是低级语言的程序，也都是基于这样一个抽象框架来进行运作的。
+
+- 冯·诺依曼体系结构示意图
+![](https://ask.qcloudimg.com/http-save/1752328/6u485dctzr.png)
+
+# 3 总结
+
+冯·诺依曼体系结构确立了我们现在每天使用的计算机硬件的基础架构。
+
+因此，学习计算机组成原理，其实就是学习和拆解冯·诺依曼体系结构。
+
+具体来说，其实就是
+
+- 学习控制器、运算器的工作原理，也就是CPU是怎么工作的，以及为何这样设计
+- 学习内存的工作原理，从最基本的电路，到上层抽象给到CPU乃至应用程序的接口是怎样的
+- 学习CPU是怎么和输入设备、输出设备打交道的。=
+
+学习组成原理，就是在理解从控制器、运算器、存储器、输入设备以及输出设备，从电路这样的硬件，到最终开放给软件的接口，是怎么运作的，为什么要设计成这样，以及在软件开发层面怎么尽可能用好它。
+
+# 4 推荐阅读
+
+- First Draft of a Report on the EDVAC
+对于工程师来说，直接读取英文论文的原文，既可以搞清楚、弄明白对应的设计及其背后的思路来源，还可以帮你破除对于论文或者核心技术的恐惧心理。
+
+# 5 思考
+
+计算机行业的两大祖师爷之一，除了冯·诺依曼机之外，还有一位就是著名的图灵（Alan Mathison Turing）。对应的，我们现在的计算机也叫图灵机（Turing Machine）。那么图灵机和冯·诺依曼机是两种不同的计算机么？图灵机是一种什么样的计算机抽象呢？
+
+欢迎留言分享你的思考和疑惑，也可以把本文分享给你的朋友，一起学习和进步！
+
+# 参考
+
+深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\203\357\274\211- \347\250\213\345\272\217\346\227\240\346\263\225\345\220\214\346\227\266\345\234\250Linux\345\222\214Windows\344\270\213\350\277\220\350\241\214.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\203\357\274\211- \347\250\213\345\272\217\346\227\240\346\263\225\345\220\214\346\227\266\345\234\250Linux\345\222\214Windows\344\270\213\350\277\220\350\241\214.md"
new file mode 100644
index 0000000000..d3df785d4f
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\203\357\274\211- \347\250\213\345\272\217\346\227\240\346\263\225\345\220\214\346\227\266\345\234\250Linux\345\222\214Windows\344\270\213\350\277\220\350\241\214.md"	
@@ -0,0 +1,164 @@
+![](https://ask.qcloudimg.com/http-save/1752328/pbod43bmvp.png)
+
+既然程序最终都被变成了一条条机器码去执行，那为什么同一个程序，在同一台计算机上，在Linux下可以运行，而在Windows下却不行呢？
+
+反过来，Windows上的程序在Linux上也是一样不能执行的
+
+可是我们的CPU并没有换掉，它应该可以识别同样的指令呀!!!
+
+如果你和我有同样的疑问，那这一节，我们就一起来解开。
+
+# 1 编译、链接和装载：拆解程序执行
+
+写好的C语言代码，可以通过编译器编译成汇编代码，然后汇编代码再通过汇编器变成CPU可以理解的机器码，于是CPU就可以执行这些机器码了
+
+你现在对这个过程应该不陌生了，但是这个描述把过程大大简化了
+
+下面，我们一起具体来看，C语言程序是如何变成一个可执行程序的。
+
+过去几节，我们通过gcc生成的文件和objdump获取到的汇编指令都有些小小的问题
+
+我们先把前面的add函数示例，拆分成两个文件
+
+- add\_lib.c
+![](https://ask.qcloudimg.com/http-save/1752328/27iteclwnt.png)
+- link\_example.c![](https://ask.qcloudimg.com/http-save/1752328/1runyilel1.png)
+
+通过gcc来编译这两个文件，然后通过objdump命令看看它们的汇编代码。
+
+![](https://ask.qcloudimg.com/http-save/1752328/d5lueryn06.png)
+
+- objdump -d -M intel -S link\_example.o
+![](https://ask.qcloudimg.com/http-save/1752328/xgggoaji7p.png)
+
+既然代码已经被我们“编译”成了指令
+
+不妨尝试运行一下 **./link\_example.o**
+
+- 不幸的是，文件没有执行权限，我们遇到一个Permission denied错误![](https://ask.qcloudimg.com/http-save/1752328/55wl57iwwt.png)
+
+即使通过**chmod**命令赋予**link\_example.o**文件可执行的权限，运行 **./link\_example.o** 仍然只会得到一条**cannot execute binary file: Exec format error**的错误。
+
+仔细看一下objdump出来的两个文件的代码，会发现**两个程序的地址都是从0开始**
+
+如果地址一样，程序如果需要通过call指令调用函数的话，怎么知道应该跳到哪一个文件呢？
+
+无论是这里的运行报错，还是objdump出来的汇编代码里面的重复地址
+
+都是因为 **add\_lib.o** 以及 **link\_example.o** **并不是一个可执行文件（Executable Program），而是目标文件（Object File）**
+
+只有通过**链接器（Linker）** 把多个目标文件以及调用的各种函数库链接起来，我们才能得到一个**可执行文件**
+
+- gcc的-o参数，可以生成对应的可执行文件，对应执行之后，就可以得到这个简单的加法调用函数的结果。
+![](https://ask.qcloudimg.com/http-save/1752328/8tiprqk6at.png)
+
+**C语言代码-汇编代码-机器码** 过程，在我们的计算机上进行的时候是由两部分组成:
+
+- 第一个部分由编译（Compile）、汇编（Assemble）以及链接（Link）三个阶段组成
+三阶段后，就生成了一个可执行文件link\_example:    
+
+```
+file format elf64-x86-64
+Disassembly of section .init:
+...
+Disassembly of section .plt:
+...
+Disassembly of section .plt.got:
+...
+Disassembly of section .text:
+...
+
+ 6b0:   55                      push   rbp
+ 6b1:   48 89 e5                mov    rbp,rsp
+ 6b4:   89 7d fc                mov    DWORD PTR [rbp-0x4],edi
+ 6b7:   89 75 f8                mov    DWORD PTR [rbp-0x8],esi
+ 6ba:   8b 55 fc                mov    edx,DWORD PTR [rbp-0x4]
+ 6bd:   8b 45 f8                mov    eax,DWORD PTR [rbp-0x8]
+ 6c0:   01 d0                   add    eax,edx
+ 6c2:   5d                      pop    rbp
+ 6c3:   c3                      ret    
+00000000000006c4 <main>:
+ 6c4:   55                      push   rbp
+ 6c5:   48 89 e5                mov    rbp,rsp
+ 6c8:   48 83 ec 10             sub    rsp,0x10
+ 6cc:   c7 45 fc 0a 00 00 00    mov    DWORD PTR [rbp-0x4],0xa
+ 6d3:   c7 45 f8 05 00 00 00    mov    DWORD PTR [rbp-0x8],0x5
+ 6da:   8b 55 f8                mov    edx,DWORD PTR [rbp-0x8]
+ 6dd:   8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
+ 6e0:   89 d6                   mov    esi,edx
+ 6e2:   89 c7                   mov    edi,eax
+ 6e4:   b8 00 00 00 00          mov    eax,0x0
+ 6e9:   e8 c2 ff ff ff          call   6b0 <add>
+ 6ee:   89 45 f4                mov    DWORD PTR [rbp-0xc],eax
+ 6f1:   8b 45 f4                mov    eax,DWORD PTR [rbp-0xc]
+ 6f4:   89 c6                   mov    esi,eax
+ 6f6:   48 8d 3d 97 00 00 00    lea    rdi,[rip+0x97]        # 794 <\_IO\_stdin\_used+0x4>
+ 6fd:   b8 00 00 00 00          mov    eax,0x0
+ 702:   e8 59 fe ff ff          call   560 <printf@plt>
+ 707:   b8 00 00 00 00          mov    eax,0x0
+ 70c:   c9                      leave  
+ 70d:   c3                      ret    
+ 70e:   66 90                   xchg   ax,ax
+...
+Disassembly of section .fini:
+```
+
+...你会发现，可执行代码dump出来内容，和之前的目标代码长得差不多，但是长了很多
+
+因为在Linux下，可执行文件和目标文件所使用的都是一种叫**ELF（Execuatable and Linkable File Format）**的文件格式，中文名字叫**可执行与可链接文件格式**
+
+这里面不仅存放了编译成的汇编指令，还保留了很多别的数据。
+
+- 第二部分，我们通过装载器（Loader）把可执行文件装载（Load）到内存中
+CPU从内存中读取指令和数据，来开始真正执行程序
+![](https://ask.qcloudimg.com/http-save/1752328/bz6uwgudne.png)2 ELF格式和链接：理解链接过程程序最终是通过装载器变成指令和数据的，所以其实生成的可执行代码也并不仅仅是一条条的指令
+我们还是通过objdump指令，把可执行文件的内容拿出来看看。
+
+比如我们过去所有objdump出来的代码里，你都可以看到对应的函数名称，像add、main等等，乃至你自己定义的全局可以访问的变量名称，都存放在这个ELF格式文件里
+
+这些名字和它们对应的地址，在ELF文件里面，存储在一个叫作符号表（Symbols Table）的位置里。符号表相当于一个地址簿，把名字和地址关联了起来。
+
+我们先只关注和我们的add以及main函数相关的部分
+
+你会发现，这里面，main函数里调用add的跳转地址，不再是下一条指令的地址了，而是add函数的入口地址了，这就是EFL格式和链接器的功劳
+
+![](https://ask.qcloudimg.com/http-save/1752328/qhfnlsqnmi.png)
+
+ELF文件格式把各种信息，分成一个一个的Section保存起来。ELF有一个基本的文件头（File Header），用来表示这个文件的基本属性，比如是否是可执行文件，对应的CPU、操作系统等等。除了这些基本属性之外，大部分程序还有这么一些Section：
+
+- 首先是.text Section，也叫作代码段或者指令段（Code Section），用来保存程序的代码和指令；
+- 接着是.data Section，也叫作数据段（Data Section），用来保存程序里面设置好的初始化数据信息；
+- 然后就是.rel.text Secion，叫作重定位表（Relocation Table）。重定位表里，保留的是当前的文件里面，哪些跳转地址其实是我们不知道的。比如上面的 link\_example.o 里面，我们在main函数里面调用了 add 和 printf 这两个函数，但是在链接发生之前，我们并不知道该跳转到哪里，这些信息就会存储在重定位表里；
+- 最后是.symtab Section，叫作符号表（Symbol Table）。符号表保留了我们所说的当前文件里面定义的函数名称和对应地址的地址簿。
+
+链接器会扫描所有输入的目标文件，然后把所有符号表里的信息收集起来，构成一个全局的符号表。然后再根据重定位表，把所有不确定要跳转地址的代码，根据符号表里面存储的地址，进行一次修正。最后，把所有的目标文件的对应段进行一次合并，变成了最终的可执行代码。这也是为什么，可执行文件里面的函数调用的地址都是正确的
+
+![](https://ask.qcloudimg.com/http-save/1752328/k2iz4yx0u1.png)
+
+在链接器把程序变成可执行文件之后，要装载器去执行程序就容易多了。装载器不再需要考虑地址跳转的问题，只需要解析 ELF 文件，把对应的指令和数据，加载到内存里面供CPU执行就可以了。
+
+# 3 总结
+
+讲到这里，相信你已经猜到，为什么同样一个程序，在Linux下可以执行而在Windows下不能执行了。其中一个非常重要的原因就是，两个操作系统下可执行文件的格式不一样。
+
+我们今天讲的是Linux下的ELF文件格式，而Windows的可执行文件格式是一种叫作PE（Portable Executable Format）的文件格式。Linux下的装载器只能解析ELF格式而不能解析PE格式。
+
+如果我们有一个可以能够解析PE格式的装载器，我们就有可能在Linux下运行Windows程序了。这样的程序真的存在吗？
+
+没错，Linux下著名的开源项目Wine，就是通过兼容PE格式的装载器，使得我们能直接在Linux下运行Windows程序的。
+
+而现在微软的Windows里面也提供了WSL，也就是Windows Subsystem for Linux，可以解析和加载ELF格式的文件。
+
+我们去写可以用的程序，也不仅仅是把所有代码放在一个文件里来编译执行，而是可以拆分成不同的函数库，最后通过一个静态链接的机制，使得不同的文件之间既有分工，又能通过静态链接来“合作”，变成一个可执行的程序。
+
+对于ELF格式的文件，为了能够实现这样一个静态链接的机制，里面不只是简单罗列了程序所需要执行的指令，还会包括链接所需要的重定位表和符号表。
+
+# 4 推荐阅读
+
+更深入了解程序的链接过程和ELF格式，推荐阅读《程序员的自我修养——链接、装载和库》的1～4章。这是一本难得的讲解程序的链接、装载和运行的好书。
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\211\357\274\211- \350\277\233\345\207\273,\346\233\264\345\274\272\347\232\204\346\200\247\350\203\275!.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\211\357\274\211- \350\277\233\345\207\273,\346\233\264\345\274\272\347\232\204\346\200\247\350\203\275!.md"
new file mode 100644
index 0000000000..5f6c455733
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\270\211\357\274\211- \350\277\233\345\207\273,\346\233\264\345\274\272\347\232\204\346\200\247\350\203\275!.md"	
@@ -0,0 +1,273 @@
+![](https://ask.qcloudimg.com/http-save/1752328/uskvyzme4j.png)
+
+在上一篇中,我们谈到过
+
+```
+程序的CPU执行时间 = 指令数×CPI×Clock Cycle Time
+```
+
+要提升计算机的性能，可以从上面这三方面着手。
+
+通过指令数/CPI，好像都太难了。
+
+因此工程师们，就在CPU上多放晶体管，不断提升CPU的时钟频率，让CPU更快，程序的执行时间就会缩短。
+
+![](https://ask.qcloudimg.com/http-save/1752328/09hlntlacb.png)
+
+- 从1978年Intel发布的8086 CPU开始，计算机的主频从5MHz开始，不断攀升
+- 1980年代中期的80386能够跑到40MHz
+- 1989年的486能够跑到100MHz
+- 直到2000年的奔腾4处理器，主频已经到达了1.4GHz
+
+# 1 功耗：CPU的“人体极限”
+
+[奔腾4的CPU主频从来没有达到过10GHz，最终它的主频上限定格在3.8GHz](https://zh.wikipedia.org/wiki/%25E5%25A5%2594%25E8%2585%25BE4)
+
+而且奔腾4的主频虽然高，但是实际性能却配不上同样的主频
+
+想要用在笔记本上的奔腾4 2.4GHz处理器，其性能只和基于奔腾3架构的奔腾M 1.6GHz匹配
+
+于是不仅让Intel的对手AMD获得了喘息之机，更是代表着“主频时代”的终结。
+
+后面几代Intel CPU主频不但没有上升，反而下降了。
+
+到如今，2019年的最高配置[Intel i9 CPU](https://zh.wikipedia.org/wiki/Intel_Core_i9)，主频也不过是5GHz
+
+相较于1978年到2000年，这20年里300倍的主频提升，从2000年到现在的这19年，CPU的主频大概提高了3倍
+
+- CPU的主频变化，奔腾4时进入瓶颈期![](https://ask.qcloudimg.com/http-save/1752328/mxpvmi6gzl.png)
+
+奔腾4的主频为什么没能超3.8GHz？
+
+就因为功耗.
+
+一个3.8GHz的奔腾4处理器，满载功率是130瓦
+
+130瓦是什么概念呢？机场允许带上飞机的充电宝的容量上限是100瓦时
+
+如果我们把这个CPU安在手机里面，不考虑屏幕内存之类的耗电，这个CPU满载运行45分钟，充电宝里面就没电了
+
+而iPhone X使用ARM架构的CPU，功率则只有4.5瓦左右。
+
+CPU，也称作**超大规模集成电路（Very-Large-Scale Integration，VLSI** 
+
+由一个个晶体管组成
+
+CPU的计算过程，其实就是让晶体管里面的“开关”不断“打开”/“关闭”，组合完成各种运算和功能。
+
+要想算得快
+
+- 增加密度
+在CPU同样的面积，多放晶体管
+- 提升主频
+让晶体管“打开”/“关闭”得快点
+
+这两者，都会增加功耗，带来耗电和散热的问题!!!
+
+可以把CPU想象成一个工厂，有很多工人
+
+就如CPU上面的晶体管，互相之间协同工作。
+
+为了工作快点完成，在工厂里多塞一点人
+
+你可能会问，为什么不把工厂造得大点？
+
+这是因为，人和人之间如果离得远了，互相之间走过去需要花的时间就会变长，这也会导致性能下降!
+
+这就如如果CPU的面积大，晶体管之间的距离变大，电信号传输的时间就会变长，运算速度自然就慢了。
+
+除了多塞一点人，还希望每个人动作快点，同样时间就可多干活了
+
+这就相当于提升CPU主频，但是动作快，每个人就要出汗散热
+
+要是太热了，对工厂里面的人来说会休克，对CPU来说就会崩溃出错。
+
+我们会在CPU上面抹硅脂、装风扇，乃至用上水冷或者其他更好的散热设备
+
+就好像在工厂里面装风扇、空调，发冷饮一样
+
+但是同样的空间下，装上风扇空调能够带来的散热效果也是有极限的
+
+因此，在CPU里面，能够放下的晶体管数量和晶体管的“开关”频率也都是有限的。
+
+一个CPU的功率，可以用这样一个公式来表示：
+
+```
+功耗  ≈ 1/2 ×负载电容 × 电压的平方 × 开关频率 × 晶体管数量
+```
+
+为了提升性能，要不断地增加晶体管数量
+
+同样的面积下，想要多放一点晶体管，就要把晶体管造得小一点
+
+这个就是平时我们所说的提升“制程”
+
+从28nm到7nm，相当于晶体管本身变成了原来的1/4大小
+
+这个就相当于我们在工厂里，同样的活儿，我们要找瘦小一点的工人，这样一个工厂里面就可以多一些人
+
+我们还要提升主频，让开关的频率变快，也就是要找手脚更快的工人
+
+![](https://ask.qcloudimg.com/http-save/1752328/4r5uwxufnv.png)
+
+但功耗增加过多，CPU散热就跟不上
+
+这时就需要降低电压
+
+这里有一点非常关键，在整个功耗的公式里面，功耗和电压的平方是成正比的
+
+这意味着电压下降到原来的1/5，整个的功耗会变成原来的1/25。
+
+事实上，从5MHz主频的8086到5GHz主频的Intel i9，CPU的电压已经从5V左右下降到了1V左右
+
+这也是为什么我们CPU的主频提升了1000倍，但是功耗只增长了40倍
+
+# 2 并行优化 - 阿姆达尔定律
+
+虽然制程的优化和电压的下降，在过去的20年里，让CPU性能有所提升
+
+但是从上世纪九十年代到本世纪初，软件工程师们所用的“面向摩尔定律编程”的套路越来越用不下去了
+
+“写程序不考虑性能，等明年CPU性能提升一倍，到时候性能自然就不成问题了”，这种想法已经不可行了。
+
+于是，从奔腾4开始，Intel意识到通过提升主频比较“难”去实现性能提升
+
+开始推出Core Duo这样的多核CPU，通过提升“吞吐率”而不是“响应时间”，来达到目的。
+
+提升响应时间，就好比提升你用的交通工具的速度
+
+原本你是开汽车，现在变成了高铁乃至飞机
+
+但是，在此之上，再想要提升速度就不太容易了
+
+CPU在奔腾4的年代，就好比已经到了飞机这个速度极限
+
+那你可能要问了，接下来该怎么办呢？
+
+相比于给飞机提速，工程师们又想到了新的办法，可以一次同时开2架、4架乃至8架飞机，这就好像我们现在用的2核、4核，乃至8核的CPU。
+
+虽然从上海到北京的时间没有变，但是一次飞8架飞机能够运的东西自然就变多了，也就是所谓的“吞吐率”变大了。所以，不管你有没有需要，现在CPU的性能就是提升了2倍乃至8倍、16倍。
+
+这也是一个最常见的提升性能的方式，**通过并行提高性能**。
+
+这个思想在很多地方都可以使用
+
+举个例子，我们做机器学习程序的时候，需要计算向量的点积，比如向量
+
+```
+$W = [W_0, W_1, W_2, …, W_{15}]$
+```
+
+和向量
+
+```
+$X = [X_0, X_1, X_2, …, X_{15}]$
+```
+
+```
+$W·X = W_0 * X_0 + W_1 * X_1 +$
+```
+
+```
+$W_2 * X_2 + … + W_{15} * X_{15}$
+```
+
+这些式子由16个乘法和1个连加组成。如果你自己一个人用笔来算的话，需要一步一步算16次乘法和15次加法。
+
+如果这个时候我们把这个人物分配给4个人，同时去算$W_0～W\_3$, $W\_4～W\_7$, $W\_8～W_{11}$, $W_{12}～W_{15}$这样四个部分的结果，再由一个人进行汇总，需要的时间就会缩短。
+
+![](https://ask.qcloudimg.com/http-save/1752328/z6nx9lsihq.png)
+
+但并不是所有问题，都可以通过并行提高性能来解决
+
+要使用这种思想，需要满足以下条件:
+
+- 需要进行的计算，本身可以分解成几个可以并行的任务
+好比上面的乘法和加法计算，几个人可以同时进行，不会影响最后的结果。
+- 需要能够分解好问题，并确保几个人的结果能够汇总到一起
+- 在“汇总”这个阶段，是没有办法并行进行的，还是得顺序执行，一步一步来。
+
+这就引出了性能优化中一个经验定律
+
+- 阿姆达尔定律（Amdahl’s Law）
+对于一个程序进行优化之后，处理器并行运算之后效率提升的情况
+
+具体可以用这样一个公式来表示：
+
+```
+优化后的执行时间 = 受优化影响的执行时间/加速倍数+不受影响的执行时间
+```
+
+在刚刚的向量点积例子里，4个人同时计算向量的一小段点积，就是通过并行提高了这部分的计算性能
+
+但是，这4个人的计算结果，最终还是要在一个人那里进行汇总相加
+
+这部分汇总相加的时间，是不能通过并行来优化的，也就是上面的公式里面**不受影响的执行时间**部分
+
+比如上面的各个向量的一小段
+
+- 点积，需要100ns
+- 加法需要20ns
+
+总共需要120ns。这里通过并行4个CPU有了4倍的加速度。那么最终优化后，就有了100/4+20=45ns
+
+即使我们增加更多的并行度来提供加速倍数，比如有100个CPU，整个时间也需要100/100+20=21ns。
+
+![](https://ask.qcloudimg.com/http-save/1752328/m00nhlporg.png)
+
+# 3 总结
+
+无论是简单地通过提升主频，还是增加更多的CPU核心数量，通过并行提升性能，都会遇到相应的瓶颈
+
+仅靠简单地通过“堆硬件”的方式，在今天已经不能很好地满足我们对于程序性能的期望了。
+
+于是，工程师们需要从其他方面开始下功夫了。
+
+在“摩尔定律”和“并行计算”之外，在整个计算机组成层面，还有这样几个原则性的性能提升方法。
+
+## 3.1 加速大概率事件
+
+深度学习，整个计算过程中，99%都是向量和矩阵计算
+
+于是，工程师们通过用GPU替代CPU，大幅度提升了深度学习的模型训练过程
+
+本来一个CPU需要跑几小时甚至几天的程序，GPU只需要几分钟就好了
+
+Google更是不满足于GPU的性能，进一步地推出了TPU
+
+> 通常我们使用 O 表示一个算法的好坏，我们优化一个算法也是基于 big-O
+> 但是 big-O 其实是一个近似值，就好比一个算法时间复杂度是 O(n^2) + O(n)
+> 这里的 O(n^2) 是占大比重的，特别是当 n 很大的时候，通常我们会忽略掉 O(n)，着手优化 O(n^2) 的部分
+
+## 3.2 通过流水线提高性能
+
+现代的工厂里的生产线叫“流水线”。
+
+我们可以把装配iPhone这样的任务拆分成一个个细分的任务，让每个人都只需要处理一道工序，最大化整个工厂的生产效率。
+
+我们的CPU其实就是一个“运算工厂”
+
+我们把CPU指令执行的过程进行拆分，细化运行，也是现代CPU在主频没有办法提升那么多的情况下，性能仍然可以得到提升的重要原因之一
+
+## 3.3 通过预测提高性能
+
+预测下一步该干什么，而不是等上一步运行结果，提前进行运算，也是让程序跑得更快一点的办法
+
+在一个循环访问数组的时候，凭经验，你也会猜到下一步我们会访问数组的下一项
+
+后面要讲的“分支和冒险”、“局部性原理”这些CPU和存储系统设计方法，其实都是在利用我们对于未来的“预测”，提前进行相应的操作，来提升我们的程序性能。
+
+> 深度优先搜索算法里面的 “剪枝策略”，防止没有必要的分支搜索，这会大幅度提升算法效率
+
+- 整个组成乃至体系结构，都是基于冯·诺依曼架构组成的软硬件一体的解决方案
+- 这里面的方方面面的设计和考虑，除了体系结构层面的抽象和通用性之外，核心需要考虑的是“性能”问题
+
+# 参考
+
+深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\271\235\357\274\211- \345\212\250\346\200\201\351\223\276\346\216\245.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\271\235\357\274\211- \345\212\250\346\200\201\351\223\276\346\216\245.md"
new file mode 100644
index 0000000000..e3c058fc6a
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\271\235\357\274\211- \345\212\250\346\200\201\351\223\276\346\216\245.md"	
@@ -0,0 +1,220 @@
+![](https://ask.qcloudimg.com/http-save/1752328/d0uvxb1xo6.png)
+
+把对应的不同文件内的代码段，合并到一起，成为最后的可执行文件
+
+链接的方式，让我们在写代码的时候做到了“复用”。
+
+同样的功能代码只要写一次，然后提供给很多不同的程序进行链接就行了。
+
+“链接”其实有点儿像我们日常生活中的**标准化、模块化**生产。
+
+有一个可以生产标准螺帽的生产线，就可生产很多不同的螺帽。
+
+只要需要螺帽，都可以通过链接的方式，去复制一个出来，放到需要的地方
+
+但是，如果我们有很多个程序都要通过装载器装载到内存里面，那里面链接好的同样的功能代码，也都需要再装载一遍，再占一遍内存空间。
+
+这就好比，假设每个人都有骑自行车的需要，那我们给每个人都生产一辆自行车带在身边，固然大家都有自行车用了，但是马路上肯定会特别拥挤。
+
+![](https://ask.qcloudimg.com/http-save/1752328/q70qtwc7rw.png)
+
+# 1 链接可以分动、静，共享运行省内存
+
+我们上一节解决程序装载到内存的时候，讲了很多方法。说起来，最根本的问题其实就是**内存空间不够用**。
+
+如果能够让同样功能的代码，在不同的程序里面，不需要各占一份内存空间，那该有多好啊！
+
+就好比，现在马路上的共享单车，我们并不需要给每个人都造一辆自行车，只要马路上有这些单车，谁需要的时候，直接通过手机扫码，都可以解锁骑行。
+
+这个思路就引入一种新的链接方法，叫作**动态链接（Dynamic Link）**
+
+相应的，我们之前说的合并代码段的方法，就是**静态链接（Static Link）**
+
+在动态链接的过程中，我们想要“链接”的，不是存储在硬盘上的目标文件代码，而是加载到内存中的**共享库（Shared Libraries）**
+
+这个加载到内存中的共享库会被很多个程序的指令调用到。
+
+- 在Windows下，这些共享库文件就是.dll文件，也就是Dynamic-Link Libary（DLL，动态链接库）
+用了“动态链接”的意思
+- 在Linux下，这些共享库文件就是.so文件，也就是Shared Object（一般我们也称之为动态链接库）。
+用了“共享”的意思
+
+正好覆盖了两方面的含义。
+
+![](https://ask.qcloudimg.com/http-save/1752328/8x932anaiq.png)
+
+# 2 地址无关很重要，相对地址解烦恼
+
+要在程序运行的时候共享代码，这些机器码必须“**地址无关**”
+
+也就是说，我们编译出来的共享库文件的指令代码，是地址无关码（Position-Independent Code）
+
+换句话说就是，这段代码，无论加载在哪个内存地址，都能够正常执行
+
+> 如果还不明白，我给你举一个生活中的例子
+> 如果我们有一个骑自行车的程序，要“前进500米，左转进入天安门广场，再前进500米”。
+> 它在500米之后要到天安门广场了，这就是地址相关的。
+> 如果程序是“前进500米，左转，再前进500米”，无论你在哪里都可以骑车走这1000米，没有具体地点的限制，这就是地址无关的。
+
+大部分函数库其实都可以做到地址无关，因为它们都接受特定的输入，进行确定的操作，然后给出返回结果就好了。
+
+无论是实现一个向量加法，还是实现一个打印的函数，这些代码逻辑和输入的数据在内存里面的位置并不重要。
+
+而常见的地址相关的代码，比如绝对地址代码（Absolute Code）、利用重定位表的代码等等，都是地址相关的代码
+
+回想一下我们之前讲过的重定位表。在程序链接的时候，我们就把函数调用后要跳转访问的地址确定下来了，这意味着，如果这个函数加载到一个不同的内存地址，跳转就会失败。![](https://ask.qcloudimg.com/http-save/1752328/uu6kphr669.png)
+
+对于所有动态链接共享库的程序来讲，虽然我们的共享库用的都是同一段物理内存地址，但是在不同的应用程序里，它所在的虚拟内存地址是不同的。
+
+没办法、也不应该要求动态链接同一个共享库的不同程序，必须把这个共享库所使用的虚拟内存地址变成一致。
+
+如果这样的话，我们写的程序就必须明确地知道内部的内存地址分配。
+
+那么问题来了，我们要怎么样才能做到，动态共享库编译出来的代码指令，都是地址无关码呢？
+
+动态代码库内部的变量和函数调用都很容易解决，我们只需要使用**相对地址（Relative Address）**
+
+各种指令中使用到的内存地址，给出的不是一个绝对的地址空间，而是一个相对于当前指令偏移量的内存地址
+
+因为 **整个共享库是放在一段连续的虚拟内存地址中的，无论装载到哪一段地址，不同指令之间的相对地址都是不变的**。
+
+# 3 动态链接的解决方案
+
+**PLT和GOT**
+
+要实现动态链接共享库，也并不困难，和前面的静态链接里的符号表和重定向表类似
+
+拿出一小段代码来看一看。
+
+- lib.h
+定义了动态链接库的一个函数 _**show\_me\_the\_money**_
+![](https://ask.qcloudimg.com/http-save/1752328/hir3c9dtp1.png)
+- lib.c
+包含了lib.h的实际实现
+![](https://ask.qcloudimg.com/http-save/1752328/viykg31uft.png)
+- show\_me\_poor.c 
+调用了 lib 里面的函数
+![](https://ask.qcloudimg.com/http-save/1752328/0wxnef9c43.png)
+- 把 lib.c 编译成了一个动态链接库，也就是 .so 文件
+![](https://ask.qcloudimg.com/http-save/1752328/iartw2ewo.png)
+- 最终生成文件集
+![](https://ask.qcloudimg.com/http-save/1752328/vdy19ol1be.png)
+
+在编译的过程中，指定了一个 _**-fPIC**_ 的参数
+
+其实就是Position Independent Code意，也就是要把这个编译成一个地址无关代码
+
+然后，我们再通过gcc编译 _**show\_me\_poor**_ 动态链接了 _**lib.so**_ 的可执行文件
+
+- 在这些操作都完成了之后，我们把 _**show\_me\_poor**_ 这个文件通过**objdump**出来看一下。![](https://ask.qcloudimg.com/http-save/1752328/rcgq9l6eac.png)
+
+```
+0000000000400540 <show_me_the_money@plt-0x10>:
+  400540:       ff 35 12 05 20 00       push   QWORD PTR [rip+0x200512]        # 600a58 <_GLOBAL_OFFSET_TABLE_+0x8>
+  400546:       ff 25 14 05 20 00       jmp    QWORD PTR [rip+0x200514]        # 600a60 <_GLOBAL_OFFSET_TABLE_+0x10>
+  40054c:       0f 1f 40 00             nop    DWORD PTR [rax+0x0]
+
+0000000000400550 <show_me_the_money@plt>:
+  400550:       ff 25 12 05 20 00       jmp    QWORD PTR [rip+0x200512]        # 600a68 <_GLOBAL_OFFSET_TABLE_+0x18>
+  400556:       68 00 00 00 00          push   0x0
+  40055b:       e9 e0 ff ff ff          jmp    400540 <_init+0x28>
+……
+0000000000400676 <main>:
+  400676:       55                      push   rbp
+  400677:       48 89 e5                mov    rbp,rsp
+  40067a:       48 83 ec 10             sub    rsp,0x10
+  40067e:       c7 45 fc 05 00 00 00    mov    DWORD PTR [rbp-0x4],0x5
+  400685:       8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
+  400688:       89 c7                   mov    edi,eax
+  40068a:       e8 c1 fe ff ff          call   400550 <show_me_the_money@plt>
+  40068f:       c9                      leave  
+  400690:       c3                      ret    
+  400691:       66 2e 0f 1f 84 00 00    nop    WORD PTR cs:[rax+rax*1+0x0]
+  400698:       00 00 00 
+  40069b:       0f 1f 44 00 00          nop    DWORD PTR [rax+rax*1+0x0]
+```
+
+我们还是只关心整个可执行文件中的一小部分内容
+
+- 在main函数调用**show\_me\_the\_money**的函数的时候，对应的代码是这样的：
+![](https://ask.qcloudimg.com/http-save/1752328/ibbojhjzom.png)
+
+这里后面有一个@plt的关键字，代表了我们需要从PLT，也就是程序链接表（Procedure Link Table）里面找要调用的函数。对应的地址呢，则是400580这个地址。
+
+那当我们把目光挪到上面的 400580 这个地址，你又会看到里面进行了一次跳转，
+
+- 这个跳转指定的跳转地址，你可以在后面的注释里面可以看到:
+![](https://ask.qcloudimg.com/http-save/1752328/0f0oy8yy3r.png)这里的 _**GLOBAL\_OFFSET\_TABLE**_，就是我接下来要说的全局偏移表。
+
+在动态链接对应的共享库，我们在共享库的data section里面，保存了一张**全局偏移表（GOT，Global Offset Table）**
+
+**虽然共享库的代码部分的物理内存是共享的，但是数据部分是各个动态链接它的应用程序里面各加载一份的。**
+
+所有需要引用当前共享库外部的地址的指令，都会查询GOT，来找到当前运行程序的虚拟内存里的对应位置
+
+而GOT表里的数据，则是在我们加载一个个共享库的时候写进去的。
+
+不同的进程，调用同样的 _**lib.so**_，各自GOT里面指向最终加载的动态链接库里面的虚拟内存地址是不同的。
+
+这样，虽然不同的程序调用的同样的动态库，各自的内存地址是独立的，调用的又都是同一个动态库，但是不需要去修改动态库里面的代码所使用的地址，
+
+而是**各个程序各自维护好自己的GOT，能够找到对应的动态库就好了**
+
+![](https://ask.qcloudimg.com/http-save/1752328/aw185d2obl.png)
+
+GOT表位于共享库自己的数据段里
+
+**GOT表在内存里和对应的代码段位置之间的偏移量，始终是确定的**
+
+这样，**共享库就是地址无关的代码，对应的各个程序只需在物理内存里加载同一份代码**
+
+而我们又要通过各个可执行程序在加载时，**生成的各不相同的GOT表，找到它需要调用到的外部变量和函数的地址**
+
+这是一个典型的、不修改代码，而是通过修改“**地址数据**”来进行关联的办法
+
+> 它有点像我们在C语言里面用函数指针来调用对应的函数，并不是通过预先已经确定好的函数名称来调用，而是利用当时它在内存里面的动态地址来调用。
+
+# 4 总结
+
+终于在静态链接和程序装载后，利用动态链接把我们的内存利用到了极致
+
+同样功能的代码生成的共享库，我们只要在内存里面保留一份就好了
+
+这样
+
+- 不仅能够做到代码在开发阶段的复用
+- 也能做到代码在运行阶段的复用。
+
+实际上，在进行Linux程序开发，一直会用到各种各样的动态链接库。
+
+C语言的标准库就在1MB以上。
+
+撰写任何一个程序可能都需要用到这个库，常见的Linux服务器里，/usr/bin下面就有上千个可执行文件。
+
+如果每一个都把标准库静态链接进来的，几GB乃至几十GB的磁盘空间一下子就用出去了。如果我们服务端的多进程应用要开上千个进程，几GB的内存空间也会一下子就用出去了。这个问题在过去计算机的内存较少的时候更加显著。
+
+通过动态链接这个方式，可以说_彻底解决了这个问题_。
+
+就像共享单车一样，如果仔细经营，是一个很有社会价值的事情，但是如果粗暴地把它变成无限制地复制生产，给每个人造一辆，只会在系统内制造大量无用的垃圾。
+
+已经把程序怎么从源代码变成指令、数据，并装载到内存里面，由CPU一条条执行下去的过程讲完了。希望你能有所收获，对于一个程序是怎么跑起来的，有了一个初步的认识。
+
+# 5 推荐阅读
+
+想要更加深入地了解动态链接，推荐你可以读一读[《程序员的自我修养：链接、装载和库》的第7章](https://book.douban.com/subject/3652388/)
+
+![](https://ask.qcloudimg.com/http-save/1752328/t1hge7r02d.png)
+
+![](https://ask.qcloudimg.com/http-save/1752328/62djlnynxd.png)
+
+里面深入地讲解了，动态链接里程序内的数据布局和对应数据的加载关系。
+
+# 参考
+
+- 深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\214\357\274\211- \345\210\266\345\256\232\345\255\246\344\271\240\350\267\257\347\272\277\357\274\214\346\224\200\347\231\273\342\200\234\346\200\247\350\203\275\342\200\235\344\271\213\345\267\205.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\214\357\274\211- \345\210\266\345\256\232\345\255\246\344\271\240\350\267\257\347\272\277\357\274\214\346\224\200\347\231\273\342\200\234\346\200\247\350\203\275\342\200\235\344\271\213\345\267\205.md"
new file mode 100644
index 0000000000..c01aaacb32
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\214\357\274\211- \345\210\266\345\256\232\345\255\246\344\271\240\350\267\257\347\272\277\357\274\214\346\224\200\347\231\273\342\200\234\346\200\247\350\203\275\342\200\235\344\271\213\345\267\205.md"	
@@ -0,0 +1,382 @@
+# 0 学习路线的知识点概括
+
+![](https://ask.qcloudimg.com/http-save/1752328/z6jdpea3cv.png)
+
+**学习计算机组成原理，就是学习计算机是如何协调运行的**
+
+- 计算机组成原理的英文叫Computer Organization![](https://ask.qcloudimg.com/http-save/1752328/o6fo6b97eb.png)
+
+Organization 意"组织机构"。
+
+该组织机构能够进行各种计算、控制、读取输入，进行输出，达成各种强大的功能。
+
+把整个计算机组成原理的知识点拆分成了四大部分
+
+- 计算机的基本组成
+- 计算机的指令和计算
+- 处理器设计
+- 存储器和I/O设备。
+
+## 0.1 计算机的基本组成
+
+计算机的硬件组成
+
+这些硬件，怎么对应到经典的冯·诺依曼体系结构的
+
+除此之外，还需要了解计算机的两个核心指标
+
+- 性能
+- 功耗
+
+性能和功耗也是我们在应用和设计五大基本组件中需要重点考虑的因素。
+
+## 0.2 计算机的指令和计算
+
+需要搞明白，我们每天撰写的一行行C、Java、PHP程序，是怎么在计算机里面跑起来的。
+
+- 了解我们的程序是怎么通过编译器和汇编器，变成一条条机器指令这样的编译过程（编译过程展开，就是编译原理）
+- 知道我们的操作系统是怎么链接、装载、执行这些程序的（深入学习，就是操作系统）。而这一条条指令执行的控制过程，就是由计算机五大组件之一的控制器来控制的。
+
+计算部分，要从二进制和编码开始，理解我们的数据在计算机里的表示，以及我们是怎么从数字电路层面，实现加法、乘法这些基本的运算功能的。
+
+实现这些运算功能的ALU（Arithmetic Logic Unit/ALU），算术逻辑单元，计算机五大组件之一的运算器。
+
+特别重要的就是浮点数（Floating Point）。
+
+浮点数是我们在日常运用中非常容易用错的一种数据表示形式。掌握浮点数能让你对数据的编码、存储和计算能够有一个从表到里的深入理解。尤其在AI火热的今天，浮点数是机器学习中重度使用的数据表示形式，掌握它更是非常有必要。
+
+## 0.3 CPU的设计
+
+CPU时钟可以用来构造寄存器和内存的锁存器和触发器，因此，CPU时钟应该是我们学习CPU的前导知识。搞明白我们为什么需要CPU时钟（CPU Clock），以及寄存器和内存是用什么样的硬件组成的之后，我们可以再来看看，整个计算机的数据通路是如何构造出来的。
+
+数据通路，其实就是连接了整个运算器和控制器，并最终组成了CPU。而出于对于性能和功耗的考虑，你要进一步理解和掌握面向流水线设计的CPU、数据和控制冒险，以及分支预测的相关技术。
+
+既然CPU作为控制器要和输入输出设备通信，那么我们就要知道异常和中断发生的机制。在CPU设计部分的最后，我会讲一讲指令的并行执行，看看如何直接在CPU层面，通过SIMD来支持并行计算。
+
+## 0.4 存储器的原理
+
+通过存储器的层次结构作为基础的框架引导，需要掌握从上到下的CPU高速缓存、内存、SSD硬盘和机械硬盘的工作原理，它们之间的性能差异，以及实际应用中利用这些设备会遇到的挑战。存储器其实很多时候又扮演了输入输出设备的角色，所以你需要进一步了解，CPU和这些存储器之间是如何进行通信的，以及我们最重视的性能问题是怎么一回事；理解什么是IO\_WAIT，如何通过DMA来提升程序性能。
+
+对于存储器，我们不仅需要它们能够正常工作，还要确保里面的数据不能丢失。于是你要掌握我们是如何通过RAID、Erasure Code、ECC以及分布式HDFS，这些不同的技术，来确保数据的完整性和访问性能。
+
+## 计算机组成原理的学习办法
+
+相较于整个计算机科学中的其他科目，计算机组成原理更像是整个计算机学科里的“纲要”。这门课里任何一个知识点深入挖下去，都可以变成计算机科学里的一门核心课程。
+
+- 程序怎样从高级代码变成指令在计算机里面运行，对应着“编译原理”和“操作系统”这两门课程
+- 计算实现背后则是“数字电路”
+- 如果要深入CPU和存储器系统的优化，必然要深入了解“计算机体系结构”。
+
+为了更快更好地学计算机组成，总结了三个学习方法
+
+### 学会提问自己来串联知识点
+
+学完一个知识点之后，你可以从下面两个方面，问一下自己。
+
+- 我写的程序，是怎样从输入的代码，变成运行的程序，并得到最终结果的？
+- 整个过程中，计算器层面到底经历了哪些步骤，有哪些地方是可以优化的？
+
+无论是程序的编译、链接、装载和执行，以及计算时需要用到的逻辑电路、ALU，乃至CPU自发为你做的流水线、指令级并行和分支预测，还有对应访问到的硬盘、内存，以及加载到高速缓存中的数据，这些都对应着我们学习中的一个个知识点。建议你自己脑子里过一遍，最好时口头表述一遍或者写下来，这样对你彻底掌握这些知识点都会非常有帮助。
+
+### 写一些示例程序来验证知识点
+
+计算机科学是一门实践的学科。计算机组成中的大量原理和设计，都对应着“性能”这个词。因此，通过把对应的知识点，变成一个个性能对比的示例代码程序记录下来，是把这些知识点融汇贯通的好方法。因为，相比于强记硬背知识点，一个有着明确性能对比的示例程序，会在你脑海里留下更深刻的印象。当你想要回顾这些知识点的时候，一个程序也更容易提示你把它从脑海深处里面找出来。
+
+### 通过和计算机硬件发展的历史做对照
+
+计算机的发展并不是一蹴而就的。从第一台电子计算机ENIAC（Electronic Numerical Integrator And Computer，电子数值积分计算机）的发明到现在，已经有70多年了。现代计算机用的各个技术，都是跟随实际应用中遇到的挑战，一个个发明、打磨，最后保留下来的。这当中不仅仅有学术层面的碰撞，更有大量商业层面的交锋。通过了解充满戏剧性和故事性的计算机硬件发展史，让你更容易理解计算机组成中各种原理的由来。
+
+比如说，奔腾4和SPARC的失败，以及ARM的成功，能让我们记住CPU指令集的繁与简、权衡性能和功耗的重要性，而现今高速发展的机器学习和边缘计算，又给计算机硬件设计带来了新的挑战。
+
+## 学习资料推荐
+
+最有效的办法还是“读书百遍，其义自见”。对于不够明白的知识点，多搜索，多看不同来源的资料，多和朋友、同事、老师一起交流，一定能够帮你掌握好想要学习的知识点。
+
+### 入门书籍
+
+- [《计算机是怎样跑起来的》](https://book.douban.com/subject/26397183/)
+![](https://ask.qcloudimg.com/http-save/1752328/67jwgpbwqj.png)
+- [《程序是怎样跑起来的》(入门微缩版“计算机组成原理”)](https://book.douban.com/subject/26365491/)
+![](https://ask.qcloudimg.com/http-save/1752328/32a6by93j.png)
+- 计算机组成中，硬件层面的基础实现，比如寄存器、ALU这些电路是怎么回事Coursera上的北京大学免费公开课《Computer Organization》。
+![](https://ask.qcloudimg.com/http-save/1752328/kwlutbcb71.png)
+
+### 进阶书籍
+
+- [《计算机组成与设计：硬件/软件接口》](https://book.douban.com/subject/2110638/)
+![](https://ask.qcloudimg.com/http-save/1752328/x4b47th0qi.png)
+- [《深入理解计算机系统（原书第3版》(CS APP的经典教材)](https://book.douban.com/subject/26912767/)
+![](https://ask.qcloudimg.com/http-save/1752328/qi7r9keimp.png)
+该书的配套视频
+	- [Bilibili版](https://www.bilibili.com/video/av24540152/)
+	- [Youtube版](https://www.youtube.com/playlist?list=PLmBgoRqEQCWy58EIwLSWwMPfkwLOLRM5R)
+- [《计算机组成：结构化方法》](https://book.douban.com/subject/25982323/)
+![](https://ask.qcloudimg.com/http-save/1752328/y3ef7hx1vq.png)
+- [《计算机体系结构：量化研究方法》](https://book.douban.com/subject/20452387/)
+![](https://ask.qcloudimg.com/http-save/1752328/3trwpxzq58.png)
+
+### 拓展阅读
+
+- [Redhat的What Every Programmer Should Know About Memory](https://people.freebsd.org/~lstewart/articles/cpumemory.pdf)
+- [LMAX开源的Disruptor实际应用程序](https://lmax-exchange.github.io/disruptor/)
+- [《编码：隐匿在计算机软硬件背后的语言》](https://book.douban.com/subject/4822685/)
+
+![](https://ask.qcloudimg.com/http-save/1752328/04djt9ijqc.png)
+
+- [《程序员的自我修养：链接、装载和库》](https://book.douban.com/subject/3652388/)
+理解计算机硬件和操作系统层面代码执行的优秀阅读材料
+![](https://ask.qcloudimg.com/http-save/1752328/jpv8cnyhw9.png)
+
+## 路线学习小结
+
+学习不是死记硬背，学习材料也不是越多越好。
+
+最有效的办法，不是短时间冲刺，而是有节奏地坚持，多在留言区和其他朋友一起交流，就更容易能够“积小步而至千里”，在程序员这个职业上有更长足的发展。
+
+# 欢迎重学计算机组成原理 ! ! !
+
+![](https://ask.qcloudimg.com/http-save/1752328/j0mroi5yoh.png)
+
+- 买电脑时，“原来的电脑性能跟不上啦”
+- 写程序时，“这个程序性能可以优化一下”
+
+这虚无缥缈的“性能”到底指的是什么呢？
+
+我们能不能给性能下一个明确的定义，然后来进行准确的比较呢？
+
+在计算机组成原理乃至体系结构中，“性能”都是最重要的一个主题。
+
+学习和研究计算机组成原理，就是在理解计算机是怎么运作的，以及为什么要这么运作。
+
+“为什么”所要解决的事情，很多时候就是提升“性能”。
+
+# 1 时间的倒数 - 性能
+
+计算机的性能，其实和体力劳动很像，好比是我们要搬东西。
+
+对于计算机的性能，我们需要有个标准来衡量。这个标准中主要有两个指标。
+
+## 1.1 响应时间（Response time）/ 执行时间（Execution time）
+
+让计算机“跑得更快”。
+
+我们执行一个程序，到底需要花多少时间。花的时间越少，自然性能就越好。
+
+- 实际系统里性能监测工具NewRelic中的响应时间，代表了每个外部的Web请求的执行时间![](https://ask.qcloudimg.com/http-save/1752328/is5ffxodq6.png)
+
+## 1.2 吞吐率（Throughput）/ 带宽（Bandwidth）
+
+让计算机“搬得更多”。
+
+服务器使用的网络带宽，通常就是一个吞吐率性能指标.吞吐率是指我们在一定的时间范围内，到底能处理多少事情。这里的“事情”，在计算机里就是处理的数据或者执行的程序指令。
+
+和搬东西对比，如果响应时间短，跑得快，我们可以来回多跑几趟搬几趟。
+
+所以**缩短程序的响应时间，一般来说都会提升吞吐率**。
+
+除了缩短响应时间，我们还有别的方法吗？当然！
+
+我们还可以多找几个人一起来搬，这就类似服务器都是多核的。
+
+人多力量大，同时处理数据，在单位时间内就可以处理更多数据，吞吐率自然也就上去了。
+
+提升吞吐率的办法有很多。大部分时候，我们只要多加一些机器，多堆一些硬件就好了。
+
+但是**响应时间的提升却没有那么容易**，因为CPU的性能提升其实在10年前就处于“挤牙膏”的状态了，所以我们得慎重地来分析对待。
+
+下面我们具体来看。
+
+我们一般把性能，定义成响应时间的倒数，也就是：
+
+```
+性能 = 1/响应时间
+```
+
+响应时间越短，性能数值越高。
+
+同样一个程序
+
+- 在Intel最新的CPU Coffee Lake上，只需要30s就能运行完成
+- 而在5年前CPU Sandy Bridge上，需要1min才能完成
+
+那么我们自然可以算出来，Coffee Lake的性能是1/30，Sandy Bridge的性能是1/60，两个的性能比为2。于是，我们就可以说，Coffee Lake的性能是Sandy Bridge的2倍。
+
+过去几年流行的手机跑分软件，就是把多个预设好的程序在手机上运行，然后根据运行需要的时间，算出一个分数来给出手机的性能评估。
+
+而在业界，各大CPU和服务器厂商组织了一个叫作SPEC（Standard Performance Evaluation Corporation）的第三方机构，专门用来指定各种“跑分”的规则
+
+![](https://ask.qcloudimg.com/http-save/1752328/71f3u69qp0.png)
+
+- 一份SPEC报告通常包含了大量不同测试的评分
+![](https://ask.qcloudimg.com/http-save/1752328/t4osjj9yx3.png)
+
+SPEC提供的CPU基准测试程序，就好像CPU届的“高考”，通过数十个不同的计算程序，对于CPU的性能给出一个最终评分。
+
+这些程序丰富多彩，有编译器、解释器、视频压缩、人工智能国际象棋等等，涵盖了方方面面的应用场景。感兴趣的话，你可以[点击这里](https://www.spec.org/cpu2017/results/cpu2017.html)
+
+# 2 计算机的计时单位：CPU时钟
+
+虽然时间是一个很自然的用来衡量性能的指标，但是用时间来衡量时，有两个问题。
+
+## 2.1 时间的测不准原理
+
+如果用你自己随便写的一个程序，来统计程序运行的时间，每一次统计结果不会完全一样。
+
+为什么会不准呢？这里面有好几个原因。
+
+### 2.1.1 统计时间方法
+
+我们统计时间是用类似于“掐秒表”一样，记录 程序运行结束时间减去程序开始运行的时间。
+
+这个时间也叫Wall Clock Time或者Elapsed Time
+
+就是在运行程序期间，挂在墙上的钟走掉的时间。
+
+但计算机可能同时运行着好多个程序，CPU实际上不停地在各个程序之间进行切换。
+
+在这些走掉的时间里，很可能CPU切换去运行别的程序了。
+
+而且，有些程序在运行的时候，可能要从网络、硬盘去读取数据，要等网络和硬盘把数据读出来，给到内存和CPU。
+
+**要想准确统计某程序的实际运行时间，进而比较程序之间的性能，须把这些额外时间除掉**
+
+那这件事怎么实现呢？？？
+
+Linux下有一个叫time的命令，可助我们一臂之力，同样的Wall Clock Time下，程序实际在CPU上到底花了多少时间。
+
+我们简单运行一下time命令。它会返回三个值
+
+- 第一个 **real time**
+也就是我们说的Wall Clock Time，即运行程序整个过程中流逝掉的时间
+- 第二个 **user time**
+CPU在运行你的程序，在用户态运行指令的时间
+- 第三个**sys time**
+CPU运行你的程序，在操作系统内核里运行指令的时间
+
+**程序实际花费的CPU执行时间（CPU Time），就是user time加上sys time**
+
+![](https://ask.qcloudimg.com/http-save/1752328/9x1gr3rqc5.png)
+
+一般情况下，如果user+sys比real大，甚至仅user比real大的情况出现，都是因为对应的程序被多个进程或者多个线程并行执行了，也很常见。
+
+> 在多核或者多cpu的机器上运行，seq和wc命令会分配到两个cpu上，user和sys是两个cpu时间相加的，而real只是现实时钟里走过的时间，极端情况下user+sys可以到达real的两倍
+
+虽然seq和wc这两个命令都是单线程运行的，但是这两个命令在多核cpu运行的情况下，会分别分配到两个不同的cpu，于是user和sys的时间都是两个cpu上运行的时间之和，就可能超过real的时间。
+
+可以这样来快速验证，运行
+
+```
+time seq 100000000 | wc -l &
+```
+
+让这个命令多跑一会儿，并且在后台运行。
+
+然后利用 top 命令看不同进程的cpu占用情况
+
+你会在top的前几行里看到seq和wc的cpu占用都接近100，实际是各被分配到了一个不同的cpu执行。
+
+### 2.1.2 不一定可直接比较出性能
+
+即使我们已经拿到了CPU时间，我们也不一定可以直接“比较”出两个程序的性能差异
+
+即使在同一台计算机上，CPU可能满载运行也可能降频运行，降频运行的时候自然花的时间会多一些。
+
+除CPU外，时间这个性能指标还会受到主板、内存这些其他相关硬件的影响。
+
+所以，我们需要对“时间”这个我们可以感知的指标进行
+
+## 2.2 CPU时间拆解
+
+```
+程序的CPU执行时间=CPU时钟周期数×时钟周期时间
+```
+
+- 时钟周期时间
+你在买电脑的时候，一定关注过CPU的主频
+我手头的这台电脑就是
+- 2.8 GHz Intel Core i7
+![](https://ask.qcloudimg.com/http-save/1752328/d5zjt7xaif.png)
+
+这里的2.8GHz就是电脑的主频（Frequency/Clock Rate）。
+
+这个2.8GHz，我们可以先简单地理解为，CPU在1秒时间内，可以执行的简单指令的数量是2.8G条。
+
+更准确点，这个2.8GHz就代表，我们CPU的一个“钟表”能够识别出来的最小的时间间隔。
+
+就像我们挂在墙上的挂钟，都是一秒一秒地走，所以通过墙上的挂钟能够识别出来的最小时间单位就是秒。
+
+而在CPU内部，有一个叫晶体振荡器（Oscillator Crystal）的东西，简称为晶振。
+
+把晶振当成CPU内部的电子表来使用。
+
+晶振带来的每一次“滴答”，就是时钟周期时间。
+
+在我这个2.8GHz的CPU上，这个时钟周期时间，就是1/2.8G。
+
+我们的CPU，是按照这个“时钟”提示的时间来进行自己的操作。
+
+主频越高，意味着这个表走得越快，我们的CPU也就走得越快。
+
+“超频”，这说的其实就相当于把买回来的CPU内部的钟给调快了，于是CPU的计算跟着这个时钟的节奏，也就自然变快了。当然这个快不是没有代价的，CPU跑得越快，散热的压力也就越大。就和人一样，超过生理极限，CPU就会崩溃了。
+
+- 回顾之前的CPU执行时间的公式程序的CPU执行时间=CPU时钟周期数×时钟周期时间
+
+最简单的提升性能方案，自然缩短时钟周期时间，也就是提升主频。
+
+换句话说，就是换一块好一点的CPU。
+
+不过，这个是我们这些底层的研发人员控制不了的，所以我们就把目光挪到了乘法的另一个因子——CPU时钟周期数上。
+
+如果能够减少程序需要的CPU时钟周期数量，一样能够提升程序性能。
+
+- 对于CPU时钟周期数，我们可以再做一个分解，把它变成CPU时钟周期数 = 指令数×每条指令的平均时钟周期数（Cycles Per Instruction，简称CPI）不同的指令需要的Cycles是不同的
+加法和乘法都对应着一条CPU指令
+但是乘法需要的Cycles就比加法要多，自然也就慢。
+在这样拆分了之后，我们的程序的CPU执行时间就可以变成这样三个部分的乘积。
+
+```
+程序的CPU执行时间=指令数 × CPI × Clock Cycle Time
+```
+
+因此，要解决性能问题，就是要优化这三者。
+
+- 时钟周期时间
+就是计算机主频，取决于硬件。[摩尔定律](https://zh.wikipedia.org/wiki/%25E6%2591%25A9%25E5%25B0%2594%25E5%25AE%259A%25E5%25BE%258B)就一直在不停提高的主频。
+最早的80386主频只有33MHz，现在手头的笔记本电脑就有2.8GHz，在主频层面，就提升了将近100倍。
+- 每条指令的平均时钟周期数CPI
+一条指令到底需要多少CPU Cycle。在后面讲解CPU结构的时候，我们会看到，现代的CPU通过流水线技术（Pipeline），让一条指令需要的CPU Cycle尽可能地少。因此，对于CPI的优化，也是计算机组成和体系结构中的重要一环。
+- 指令数
+代表执行我们的程序到底需要多少条指令、用哪些指令。
+这个很多时候就把挑战交给了编译器。
+同样的代码，编译成计算机指令时候，就有各种不同的表示方式。
+
+> 把自己想象成一个CPU，坐在那里写程序。
+> 计算机主频就好像是你的打字速度，打字越快，你自然可以多写一点程序。
+
+CPI相当于你在写程序的时候，熟悉各种快捷键，越是打同样的内容，需要敲击键盘的次数就越少。
+
+指令数相当于你的程序设计得够合理，同样的程序要写的代码行数就少。
+
+如果三者皆能实现，你自然可以很快地写出一个优秀的程序，“性能”从外面来看就是好的。
+
+# 3 总结
+
+学完本文，对“性能”这个名词，你应该有了更清晰的认识。
+
+主要对于“响应时间”这个性能指标进行抽丝剥茧，拆解成了计算机时钟周期、CPI以及指令数这三个独立的指标的乘积，并且为指明了优化计算机性能的三条康庄大道。
+
+也就是，提升计算机主频，优化CPU设计使得在单个时钟周期内能够执行更多指令，以及通过编译器来减少需要的指令数。
+
+后面会讲解，具体怎么在电路硬件、CPU设计，乃至指令设计层面，提升计算机的性能。
+
+# 参考
+
+- 豆瓣读书 - 计算机专题
+- 深入浅出计算机组成原理
+- [What do 'real', 'user' and 'sys' mean in the output of time(1)?](https://stackoverflow.com/questions/556405/what-do-real-user-and-sys-mean-in-the-output-of-time1)
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\224\357\274\211- \"\346\227\213\350\275\254\350\267\263\350\267\203\"\347\232\204\346\214\207\344\273\244\345\256\236\347\216\260.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\224\357\274\211- \"\346\227\213\350\275\254\350\267\263\350\267\203\"\347\232\204\346\214\207\344\273\244\345\256\236\347\216\260.md"
new file mode 100644
index 0000000000..e76e83954b
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\344\272\224\357\274\211- \"\346\227\213\350\275\254\350\267\263\350\267\203\"\347\232\204\346\214\207\344\273\244\345\256\236\347\216\260.md"	
@@ -0,0 +1,268 @@
+![](https://ask.qcloudimg.com/http-save/1752328/57mlmnq3i5.png)
+
+CPU执行的也不只是一条指令，一般一个程序包含很多条指令
+
+因为有if…else、for这样的条件和循环存在，这些指令也不会一路平直执行下去。
+
+一个计算机程序是怎么被分解成一条条指令来执行的呢
+
+# 1 CPU如何执行指令
+
+CPU里差不多几百亿个晶体管
+
+实际上，一条条计算机指令执行起来非常复杂
+
+好在CPU在软件层面已经为我们做好了封装
+
+对于程序员来说，我们只要知道，写好的代码变成了指令之后，是一条一条**顺序执行**
+
+不管几百亿的晶体管的背后是怎么通过电路运转起来的
+
+逻辑上，我们可以认为，CPU其实就是由一堆寄存器组成的
+
+而寄存器就是CPU内部，由多个触发器（Flip-Flop）或者锁存器（Latches）组成的简单电路。
+
+> 触发器和锁存器，其实就是两种不同原理的数字电路组成的逻辑门
+> 如果想要深入学习的话，可以学习数字电路的相关课程
+
+N个触发器或者锁存器，就可以组成一个N位（Bit）的寄存器，能够保存N位的数据
+
+比方说，我们用的64位Intel服务器，寄存器就是64位的
+
+![](https://ask.qcloudimg.com/http-save/1752328/uc2jhcvs4t.png)
+
+CPU里有很多种不同功能的
+
+## 1.1 寄存器
+
+寄存器（Register），是中央处理器内的其中组成部分。寄存器是有限存贮容量的高速存贮部件，它们可用来暂存指令、数据和地址。在中央处理器的控制部件中，包含的寄存器有指令寄存器（IR）和程序计数器。在中央处理器的算术及逻辑部件中，包含的寄存器有累加器。
+
+在计算机体系结构里，处理器中的寄存器是少量且速度快的计算机存储器，借由提供快速共同地访问数值来加速计算机程序的运行：典型地说就是在已知时间点所作的之计算中间的数值。
+
+寄存器是存储器层次结构中的最顶端，也是系统操作数据的最快速途径。寄存器通常都是以他们可以保存的比特数量来估量，举例来说，一个8位寄存器或32位寄存器。寄存器现在都以寄存器数组的方式来实现，但是他们也可能使用单独的触发器、高速的核心存储器、薄膜存储器以及在数种机器上的其他方式来实现出来。
+
+这个名词通常都用来意指由一个指令之输出或输入可以直接索引到的寄存器组群。更适当的是称他们为“架构寄存器”。例如，x86指令集定义八个32位寄存器的集合，但一个实现x86指令集的CPU可以包含比八个更多的寄存器。
+
+## 1.1.1 PC寄存器（Program Counter Register）
+
+亦称指令地址寄存器（Instruction Address Register）
+
+存放下一条需要执行的计算机指令的内存地址
+
+## 1.1.2 指令寄存器（Instruction Register）
+
+存放当前正在执行的指令
+
+### 1.1.3 条件码寄存器（Status Register）
+
+用里面的一个一个标记位（Flag），存放CPU进行算术或者逻辑计算的结果
+
+![](https://ask.qcloudimg.com/http-save/1752328/5dmz0r317w.png)
+
+CPU里面还有更多用来存储数据和内存地址的寄存器
+
+这样的寄存器通常一类里面不止一个
+
+通常根据存放的数据内容来给它们取名字，比如
+
+- 常量寄存器
+用来持有只读的数值（例如0、1、圆周率等等）。由于“其中的值不可更改”这一特殊性质，这些寄存器未必会有实体的硬件电路相对应，例如将从零常数寄存器读的操作实现为接通目标寄存器的下拉电阻。
+一般而言，即使真正在硬件中放置常数寄存器也未必会是出于体系结构理论上的考虑，而很可能是由硬件描述语言为了简化操作而自动生成的电路
+- 整数寄存器
+用来存储整数数字（参考以下的浮点寄存器）。在某些简单（或旧）的CPU，特别的数据寄存器是累加器，作为数学计算之用。
+- 浮点数寄存器（FPRs）
+用来存储浮点数字。
+- 向量寄存器
+用来存储由向量处理器运行SIMD指令所得到的数据。
+- 地址寄存器
+持有存储器地址，以及用来访问存储器。在某些简单/旧的CPU里，特别的地址寄存器是索引寄存器（可能出现一个或多个）。
+
+有些寄存器既可以存放数据，又能存放地址，我们就叫它通用寄存器（GPRs）。
+
+![](https://ask.qcloudimg.com/http-save/1752328/fk0nvaoeg9.png)
+
+程序执行的时候，CPU会
+
+1. 根据PC寄存器里的地址
+2. 从内存里面把需要执行的指令读取到指令寄存器里面执行
+3. 然后根据指令长度自增
+4. 开始顺序读取下一条指令
+
+可以看到，一个程序的一条条指令，在**内存里是连续保存**的，也会**一条条顺序加载**
+
+而有些特殊指令，比如上一讲我们讲到J类指令，也就是跳转指令，会修改PC寄存器里面的地址值
+
+这样，下一条要执行的指令就不是从内存里面顺序加载的了
+
+事实上，这些跳转指令的存在，也是我们可以在写程序的时候，使用
+
+- if…else条件语句
+- while/for循环语句
+
+的原因
+
+# 2 从if/else看程序的执行和跳转
+
+我们现在就来看一个包含if…else的简单程序。
+
+- test.c
+![](https://ask.qcloudimg.com/http-save/1752328/iwwo4jmpu5.png)
+
+用rand生成了一个随机数r(0/1)
+
+- 当r是0，我们把之前定义的变量a设成1
+- 不然就设成2
+
+我们把这个程序编译成汇编代码。你可以忽略前后无关的代码，只关注于这里的if…else条件判断语句
+
+- 对应的汇编代码是这样的
+![](https://ask.qcloudimg.com/http-save/1752328/9pdcnxkxi9.png)
+
+对于r == 0的条件判断，被编译成了cmp和jne两条指令。
+
+- cmp指令比较了前后两个操作数的值
+DWORD PTR 代表操作的数据类型是32位的整数
+rbp-0x4则是一个寄存器的地址
+第一个操作数就是从寄存器里拿到的变量r的值
+第二个操作数0x0就是我们设定的常量0的16进制表示
+
+cmp指令的比较结果，会存入到**条件码寄存器**
+
+> 状态寄存器又名条件码寄存器，它是计算机系统的核心部件——运算器的一部分
+> 状态寄存器用来存放两类信息：
+> 	一类是体现当前指令执行结果的各种状态信息（条件码），如有无进位（CF位）、有无溢出（OF位）、结果正负（SF位）、结果是否为零（ZF位）、奇偶标志位（P位）等
+> 另一类是存放控制信息（PSW:程序状态字寄存器），如允许中断(IF位)、跟踪标志（TF位）等
+> 有些机器中将PSW称为标志寄存器FR（Flag Register）。
+
+如果比较结果 True，即 r == 0，就把**零标志条件码**（对应的条件码是ZF，Zero Flag）设置为1
+
+> 条件码是CPU根据运算结果由硬件设置的位，体现当前指令执行结果的各种状态信息
+> 例如：算术运算产生的正、负、零或溢出等的结果。条件码可被测试，作为分支运算的依据，此外，有些条件码可被设置，例如对于最高位进位标志C，可用指令对它置位和复位。 
+
+Intel的CPU下还有
+
+- 进位标志（CF，Carry Flag）
+最近的操作使最高位产生了进位。可以用来检查无符号操作数据的溢出。
+- 符号标志（SF，Sign Flag）
+最近的操作得到的结果为负数。
+- 溢出标志（OF，Overflow Flag）
+最近的操作导致一个补码溢出--正溢出或负溢出
+
+用在不同的判断条件下。
+
+cmp指令执行完成之后，**PC寄存器**会自增，开始执行下一条jne的指令
+
+跟着的jne指令(jump if not equal)，它会查看对应的零标志位
+
+如果为0，会跳转到后面跟着的操作数4a的位置
+
+4a，对应汇编代码的行号，也就是else条件里的第一条指令
+
+当跳转发生，PC寄存器不再是自增变成下一条指令的地址，而被直接设置4a这个地址
+
+这个时候，CPU再把4a地址里的指令加载到指令寄存器执行。
+
+跳转到执行地址为4a的指令，实际是一条mov指令
+
+第一个操作数和前面的cmp指令一样，是另一个32位整型的寄存器地址，以及对应的2的16进制值0x2
+
+mov指令把2设置到对应的寄存器里去，相当于一个赋值操作
+
+然后，PC寄存器里的值继续自增，执行下一条mov指令。
+
+这条mov指令的第一个操作数eax，代表**累加寄存器**
+
+> 在中央处理器中，累加器 (accumulator) 是一种寄存器，用来储存计算产生的中间结果。如果没有像累加器这样的寄存器，那么在每次计算 (加法，乘法，移位等等) 后就必须要把结果写回到 内存，也许马上就得读回来。然而存取主存的速度是比从算术逻辑单元到有直接路径的累加器存取更慢。
+
+第二个操作数0x0则是16进制的0的表示。这条指令其实没有实际的作用，它的作用是一个占位符
+
+if条件如果满足，在赋值的mov指令执行完成之后，有一个jmp的无条件跳转指令
+
+跳转的地址就是这一行的地址51
+
+我们的main函数没有设定返回值，而mov eax, 0x0 其实就是给main函数生成了一个默认的为0的返回值到累加器里面
+
+if条件里面的内容执行完成之后也会跳转到这里，和else里的内容结束之后的位置是一样的。
+
+![](https://ask.qcloudimg.com/http-save/1752328/8ionvro99a.png)
+
+上一讲我们讲打孔卡的时候说到，读取打孔卡的机器会顺序地一段一段地读取指令，然后执行。
+
+执行完一条指令，它会自动地顺序读取下一条指令
+
+如果执行的当前指令带有跳转的地址，比如往后跳10个指令，那么机器会自动将卡片带往后移动10个指令的位置，再来执行指令
+
+同样的，机器也能向前移动，去读取之前已经执行过的指令
+
+这也就是我们的while/for循环实现的原理。
+
+如何通过if…else和goto来实现循环？
+
+![](https://ask.qcloudimg.com/http-save/1752328/i34zi77nz8.png)
+
+我们再看一段简单的利用for循环的程序。我们循环自增变量i三次，三次之后，i>=3，就会跳出循环。整个程序，对应的Intel汇编代码就是这样的：
+
+![](https://ask.qcloudimg.com/http-save/1752328/se8ba2pt92.png)
+
+可以看到，对应的循环也是用1e这个地址上的cmp比较指令
+
+和紧接着的jle条件跳转指令来实现的
+
+主要的差别在于，这里的jle跳转的地址，在这条指令之前的地址14，而非if…else编译出来的跳转指令之后
+
+往前跳转使得条件满足的时候，PC寄存器会把指令地址设置到之前执行过的指令位置，重新执行之前执行过的指令，直到条件不满足，顺序往下执行jle之后的指令，整个循环才结束。
+
+![](https://ask.qcloudimg.com/http-save/1752328/rc2n8yi1jl.png)
+
+如果你看一长条打孔卡的话，就会看到卡片往后移动一段，执行了之后，又反向移动，去重新执行前面的指令。
+
+jle和jmp指令，有点像程序语言里面的goto命令，直接指定了一个特定条件下的跳转位置
+
+虽然我们在用高级语言开发程序的时候反对使用goto，但是实际在机器指令层面，无论是if…else…也好，还是for/while也好，都是用和goto相同的跳转到特定指令位置的方式来实现的。
+
+# 3 总结
+
+学习了程序里的多条指令，究竟是怎么样一条一条被执行的
+
+除了简单地通过PC寄存器自增的方式顺序执行外
+
+条件码寄存器会记录下当前执行指令的条件判断状态
+
+然后通过跳转指令读取对应的条件码
+
+修改PC寄存器内的下一条指令的地址
+
+最终实现if…else以及for/while这样的程序控制流程。
+
+虽然我们可以用高级语言，可以用不同的语法，比如 if…else 这样的条件分支，或者 while/for 这样的循环方式，来实现不用的程序运行流程
+
+但是回归到计算机可以识别的机器指令级别，其实都只是一个简单的地址跳转而已，也就是一个类似于goto的语句。
+
+想要在硬件层面实现这个goto语句，除了本身需要用来保存下一条指令地址，以及当前正要执行指令的PC寄存器、指令寄存器外
+
+我们只需要再增加一个条件码寄存器，来保留条件判断的状态。这样简简单单的三个寄存器，就可以实现条件判断和循环重复执行代码的功能。
+
+# 4 推荐阅读
+
+- 《深入理解计算机系统》的第3章
+详细讲解了C语言和Intel CPU的汇编语言以及指令的对应关系，以及Intel CPU的各种寄存器和指令集。
+
+Intel指令集相对于之前的MIPS指令集要复杂一些
+
+- 所有的指令是变长的
+从1个字节到15个字节不等
+- 即使是汇编代码，还有很多针对操作数据的长度不同有不同的后缀
+
+# 参考
+
+- [状态寄存器](https://baike.baidu.com/item/%25E7%258A%25B6%25E6%2580%2581%25E5%25AF%2584%25E5%25AD%2598%25E5%2599%25A8)
+- [寄存器](https://zh.wikipedia.org/wiki/%25E5%25AF%2584%25E5%25AD%2598%25E5%2599%25A8)
+- [条件码](https://baike.baidu.com/item/%25E6%259D%25A1%25E4%25BB%25B6%25E7%25A0%2581)
+- [累加器](https://zh.wikipedia.org/wiki/%25E7%25B4%25AF%25E5%258A%25A0%25E5%2599%25A8)
+- 深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\253\357\274\211- \347\250\213\345\272\217\347\232\204\350\243\205\350\275\275.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\253\357\274\211- \347\250\213\345\272\217\347\232\204\350\243\205\350\275\275.md"
new file mode 100644
index 0000000000..bc4afe702f
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\253\357\274\211- \347\250\213\345\272\217\347\232\204\350\243\205\350\275\275.md"	
@@ -0,0 +1,162 @@
+![](https://ask.qcloudimg.com/http-save/1752328/f502abne5u.png)
+
+比尔·盖茨在上世纪80年代说的“640K ought to be enough for anyone”
+
+也就是“640K内存对哪个人来说都够用了”
+
+那个年代，微软开发的还是DOS操作系统，程序员们还在绞尽脑汁，想要用好这极为有限的640K内存
+
+而现在，我手头的Mac Book Pro已经是16G内存了，上升了一万倍还不止。
+
+那比尔·盖茨这句话在当时也是完全的无稽之谈么？有没有哪怕一点点的道理呢？这一讲里，我就和你一起来看一看。
+
+# 1 程序装载的挑战
+
+在运行这些可执行文件的时候，我们其实是通过一个装载器，解析ELF或者PE格式的可执行文件
+
+装载器会把对应的指令和数据加载到内存里面来，让CPU去执行。
+
+**装载到内存**,装载器需要满足两个要求
+
+- 可执行程序加载后**占用的内存空间应该是连续的**
+执行指令的时候，程序计数器是顺序地一条一条指令执行。这意味着，这一条条指令需要连续地存储在一起
+- **需要同时加载很多个程序，并且不能让程序自己规定在内存中加载的位置**
+虽然编译出来的指令里已经有了对应的各种各样的内存地址，但是实际加载的时候，我们其实没有办法确保，这个程序一定加载在哪一段内存地址上
+因为现在的计算机通常会同时运行很多个程序，可能你想要的内存地址已经被其他加载了的程序占用
+
+要满足这两个基本的要求，我们很容易想到一个办法。那就是我们可以在内存里面，找到一段连续的内存空间，然后分配给装载的程序，然后把这段连续的内存空间地址，和整个程序指令里指定的内存地址做一个映射。
+
+指令里用到的内存地址叫作**虚拟内存地址（Virtual Memory Address）**
+
+实际在内存硬件里面的空间地址，我们叫**物理内存地址（Physical Memory Address）**
+
+程序里有指令和各种内存地址，我们只需要关心虚拟内存地址就行了
+
+对于任何一个程序来说，它看到的都是同样的内存地址。我们维护一个虚拟内存到物理内存的映射表，这样实际程序指令执行的时候，会通过虚拟内存地址，找到对应的物理内存地址，然后执行。因为是连续的内存地址空间，所以我们只需要维护映射关系的起始地址和对应的空间大小就可以了。
+
+# 2 内存分段
+
+这种找出一段连续的物理内存和虚拟内存地址进行映射的方法，我们叫**分段（Segmentation）**。
+
+这里的段，就是指系统分配出来的那个连续的内存空间。
+
+![](https://ask.qcloudimg.com/http-save/1752328/cm3kvg5lk5.png)
+
+分段的办法很好，解决了程序本身不需要关心具体的物理内存地址的问题，但它也有一些不足之处，第一个就是**内存碎片（Memory Fragmentation）** 
+
+**举个例子**
+
+电脑有1GB的内存
+
+先启动一个图形渲染程序，占用了512MB的内存
+
+接着启动一个Chrome浏览器，占用了128MB内存
+
+再启动一个PY程序，占用了256MB内存
+
+这个时候，我们关掉Chrome，于是空闲内存还有1024 - 512 - 256 = 256MB
+
+按理来说，我们有足够的空间再去装载一个200MB的程序。但是，这256MB的内存空间不是连续的，而是被分成了两段128MB的内存
+
+因此，实际情况是，我们的程序**没办法加载进来**。
+
+![](https://ask.qcloudimg.com/http-save/1752328/hzrjurkssp.png)
+
+当然了,有办法解决 --- **内存交换（Memory Swapping）**
+
+我们可以把Python程序占用的256MB内存写到硬盘，再从硬盘上读回来到内存里面
+
+不过读回来的时候，我们不再把它加载到原来的位置，而是紧紧跟在那已经被占用了的512MB内存后面
+
+这样，我们就有了连续的256MB内存空间，就可以去加载一个新的200MB的程序。如果你自己安装过Linux操作系统，你应该遇到过分配一个swap硬盘分区的问题
+
+这块分出来的磁盘空间，其实就是专门给Linux操作系统进行**内存交换**用的。
+
+**虚拟内存、分段，再加上内存交换**
+
+看起来似乎已经解决了计算机同时装载运行很多个程序的问题
+
+不过三者的组合仍然会遇到一个性能瓶颈
+
+- 硬盘的访问速度要比内存慢很多
+- 而每一次内存交换，我们都需要把一大段连续的内存数据写到硬盘上
+
+所以，如果内存交换的时候，交换的是一个很占内存空间的程序，这样整个机器都会显得卡顿。
+
+# 3 内存分页
+
+既然问题出在内存碎片和内存交换的空间太大上，那么解决问题的办法就是，少出现一些内存碎片。
+
+另外，当需要进行内存交换的时候，让需要交换写入或者从磁盘装载的数据更少一点，这样就可以解决这个问题。
+
+这个办法，在现在计算机的内存管理里面，就叫作**内存分页（Paging）**
+
+\*\*和分段这样分配一整段连续的空间给到程序相比
+
+分页则是把整个物理内存空间切成一段段固定尺寸的大小\*\*
+
+而对应的程序所需要占用的虚拟内存空间，也会同样切成一段段固定尺寸的大小。
+
+这样一个连续并且尺寸固定的内存空间，我们叫**页（Page）**。
+
+从虚拟内存到物理内存的映射，不再是拿整段连续的内存的物理地址，而是按照一个个页来的。
+
+页的尺寸一般远远小于整个程序的大小。
+
+**在Linux下，我们通常只设置成4KB**。你可以通过命令看看你手头的Linux系统设置的页的大小。
+
+![](https://ask.qcloudimg.com/http-save/1752328/zswxol3en7.png)
+
+由于内存空间都是预先划分好的，也就没有不能使用的碎片，而只有被释放出来的很多4KB的页。
+
+即使内存空间不够，需要让现有的、正在运行的其他程序
+
+通过内存交换释放出一些内存的页出来，一次性写入磁盘的也只有少数的一个页或者几个页，不会花太多时间，让整个机器被内存交换的过程给卡住。
+
+![](https://ask.qcloudimg.com/http-save/1752328/634ez5hzoc.png)
+
+分页的方式使得加载程序的时候，不再需要一次性把程序加载到物理内存中
+
+可以在进行虚拟内存和物理内存的页之间的映射后，并不真的把页加载到物理内存里，而是只在程序运行中，需要用到对应虚拟内存页里面的指令和数据时，再加载到物理内存里面去。
+
+实际上，我们的操作系统，的确是这么做的
+
+当要读取特定的页，却发现数据并没有加载到物理内存里的时候，就会触发一个来自于CPU的**缺页错误（Page Fault）**
+
+操作系统会捕捉到这个错误，然后将对应的页，从存放在硬盘上的虚拟内存里读取出来，加载到物理内存里。这种方式，使得我们可以运行那些远大于我们实际物理内存的程序。同时，这样一来，任何程序都不需要一次性加载完所有指令和数据，只需要加载当前需要用到就行了。
+
+通过虚拟内存、内存交换和内存分页这三个技术的组合，我们最终得到了一个让程序不需要考虑实际的物理内存地址、大小和当前分配空间的解决方案。
+
+这些技术和方法，对于我们程序的编写、编译和链接过程都是透明的。这也是我们在计算机的软硬件开发中常用的一种方法，就是**加入一个间接层**。
+
+通过引入虚拟内存、页映射和内存交换，我们的程序本身，就不再需要考虑对应的真实的内存地址、程序加载、内存管理等问题了。任何一个程序，都只需要把内存当成是一块完整而连续的空间来直接使用。
+
+# 4 总结
+
+电脑只要640K内存就够了吗？很显然，现在来看，比尔·盖茨的这个判断是不合理的，那为什么他会这么认为呢？因为他也是一个很优秀的程序员啊！
+
+在虚拟内存、内存交换和内存分页这三者结合之下，你会发现，其实要运行一个程序，“必需”的内存是很少的。CPU只需要执行当前的指令，极限情况下，内存也只需要加载一页就好了。再大的程序，也可以分成一页。每次，只在需要用到对应的数据和指令的时候，从硬盘上交换到内存里面来就好了。以我们现在4K内存一页的大小，640K内存也能放下足足160页呢，也无怪乎在比尔·盖茨会说出“640K ought to be enough for anyone”这样的话。
+
+不过呢，硬盘的访问速度比内存慢很多，所以我们现在的计算机，没有个几G的内存都不好意思和人打招呼。
+
+那么，除了程序分页装载这种方式之外，我们还有其他优化内存使用的方式么？下一讲，我们就一起来看看“动态装载”，学习一下让两个不同的应用程序，共用一个共享程序库的办法。
+
+# 5 推荐阅读
+
+想要更深入地了解代码装载的详细过程，推荐你阅读《程序员的自我修养——链接、装载和库》的第1章和第6章。
+
+# 6 思考
+
+在Java这样使用虚拟机的编程语言里面，我们写的程序是怎么装载到内存里面来的呢？它也和我们讲的一样，是通过内存分页和内存交换的方式加载到内存里面来的么？
+
+jvm已经是上层应用，无需考虑物理分页，一般更直接是考虑对象本身的空间大小，物理硬件管理统一由承载jvm的操纵系统去解决吧
+
+# 参考
+
+深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\255\357\274\211- \345\207\275\346\225\260\350\260\203\347\224\250\346\200\216\344\271\210\347\252\201\347\204\266Stack Overflow\344\272\206!.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\255\357\274\211- \345\207\275\346\225\260\350\260\203\347\224\250\346\200\216\344\271\210\347\252\201\347\204\266Stack Overflow\344\272\206!.md"
new file mode 100644
index 0000000000..6f0650362d
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\205\255\357\274\211- \345\207\275\346\225\260\350\260\203\347\224\250\346\200\216\344\271\210\347\252\201\347\204\266Stack Overflow\344\272\206!.md"	
@@ -0,0 +1,309 @@
+![](https://ask.qcloudimg.com/http-save/1752328/ejqq3ckf3d.png)
+
+用Google搜异常信息，肯定都访问过[Stack Overflow网站](https://stackoverflow.com/)
+
+> 全球最大的程序员问答网站，名字来自于一个常见的报错，就是栈溢出（stack overflow）
+
+从函数调用开始，在计算机指令层面函数间的相互调用是怎么实现的，以及什么情况下会发生栈溢出
+
+# 1 栈的意义
+
+先看一个简单的C程序
+
+- function.c
+![在这里插入图片描述](https://ask.qcloudimg.com/http-save/1752328/p736hs2ow8.png)
+- 直接在Linux中使用GCC编译运行
+
+```
+[hadoop@JavaEdge Documents]$ vim function.c
+[hadoop@JavaEdge Documents]$ gcc -g -c function.c 
+[hadoop@JavaEdge Documents]$ objdump -d -M intel -S function.o
+
+function.o:     file format elf64-x86-64
+
+
+Disassembly of section .text:
+
+0000000000000000 <add>:
+#include <stdio.h>
+int static add(int a, int b)
+{
+   0:	55                   	push   rbp
+   1:	48 89 e5             	mov    rbp,rsp
+   4:	89 7d fc             	mov    DWORD PTR [rbp-0x4],edi
+   7:	89 75 f8             	mov    DWORD PTR [rbp-0x8],esi
+   a:	8b 45 f8             	mov    eax,DWORD PTR [rbp-0x8]
+   d:	8b 55 fc             	mov    edx,DWORD PTR [rbp-0x4]
+  10:	01 d0                	add    eax,edx
+  12:	5d                   	pop    rbp
+  13:	c3                   	ret    
+
+0000000000000014 <main>:
+    return a+b;
+}
+
+
+int main()
+{
+  14:	55                   	push   rbp
+  15:	48 89 e5             	mov    rbp,rsp
+  18:	48 83 ec 10          	sub    rsp,0x10
+    int x = 5;
+  1c:	c7 45 fc 05 00 00 00 	mov    DWORD PTR [rbp-0x4],0x5
+    int y = 10;
+  23:	c7 45 f8 0a 00 00 00 	mov    DWORD PTR [rbp-0x8],0xa
+    int u = add(x, y);
+
+  2a:	8b 55 f8             	mov    edx,DWORD PTR [rbp-0x8]
+  2d:	8b 45 fc             	mov    eax,DWORD PTR [rbp-0x4]
+  30:	89 d6                	mov    esi,edx
+  32:	89 c7                	mov    edi,eax
+  34:	e8 c7 ff ff ff       	call   0 <add>
+  39:	89 45 f4             	mov    DWORD PTR [rbp-0xc],eax
+    return 0;
+  3c:	b8 00 00 00 00       	mov    eax,0x0
+}
+  41:	c9                   	leave  
+  42:	c3                   	ret    
+```
+
+main函数和上一节我们讲的的程序执行区别不大,主要是把jump指令换成了函数调用的call指令,call指令后面跟着的，仍然是跳转后的程序地址
+
+**看看add函数**
+
+add函数编译后，代码先执行了一条push指令和一条mov指令
+
+在函数执行结束的时候，又执行了一条pop和一条ret指令
+
+这四条指令的执行，其实就是在进行我们接下来要讲**压栈（Push）和出栈（Pop）**
+
+函数调用和上一节我们讲的if…else和for/while循环有点像
+
+都是在原来顺序执行的指令过程里，执行了一个内存地址的跳转指令，让指令从原来顺序执行的过程里跳开，从新的跳转后的位置开始执行。
+
+**但是，这两个跳转有个区别**
+
+- if…else和for/while的跳转，是跳转走了就不再回来了，就在跳转后的新地址开始顺序地执行指令，后会无期
+- 函数调用的跳转，在对应函数的指令执行完了之后，还要再回到函数调用的地方，继续执行call之后的指令，地球毕竟是圆的
+
+**有没有一个可以不跳回原来开始的地方,从而实现函数的调用呢**
+
+似乎有.可以把调用的函数指令，直接插入在调用函数的地方，替换掉对应的call指令，然后在编译器编译代码的时候，直接就把函数调用变成对应的指令替换掉。
+
+不过思考一下，你会发现**漏洞**
+
+如果函数A调用了函数B，然后函数B再调用函数A，我们就得面临在A里面插入B的指令，然后在B里面插入A的指令，这样就会产生无穷无尽地替换。
+
+就好像两面镜子面对面放在一块儿，任何一面镜子里面都会看到无穷多面镜子
+
+![](https://ask.qcloudimg.com/http-save/1752328/74k9htdn0d.png)
+
+**Infinite Mirror Effect**
+
+如果函数A调用B，B再调用A，那么代码会无限展开
+
+那就换一个思路，能不能把后面要跳回来执行的指令地址给记录下来呢？
+
+就像PC寄存器一样，可以专门设立一个“程序调用寄存器”，存储接下来要跳转回来执行的指令地址
+
+等到函数调用结束，从这个寄存器里取出地址，再跳转到这个记录的地址，继续执行就好了。
+
+**但在多层函数调用里，只记录一个地址是不够的**
+
+在调用函数A之后，A还可以调用函数B，B还能调用函数C
+
+这一层又一层的调用并没有数量上的限制
+
+在所有函数调用返回之前，每一次调用的返回地址都要记录下来，但是我们CPU里的寄存器数量并不多
+
+> 像我们一般使用的Intel i7 CPU只有16个64位寄存器，调用的层数一多就存不下了。
+
+最终，CSer们想到了一个比单独记录跳转回来的地址更完善的办法
+
+在内存里面开辟一段空间，用栈这个后进先出（LIFO，Last In First Out）的数据结构
+
+> 栈就像一个乒乓球桶，每次程序调用函数之前，我们都把调用返回后的地址写在一个乒乓球上，然后塞进这个球桶
+> 这个操作其实就是我们常说的压栈。如果函数执行完了，我们就从球桶里取出最上面的那个乒乓球，很显然，这就是出栈。
+
+拿到出栈的乒乓球，找到上面的地址，把程序跳转过去，就返回到了函数调用后的下一条指令了
+
+如果函数A在执行完成之前又调用了函数B，那么在取出乒乓球之前，我们需要往球桶里塞一个乒乓球。而我们从球桶最上面拿乒乓球的时候，拿的也一定是最近一次的，也就是最下面一层的函数调用完成后的地址
+
+乒乓球桶的底部，就是**栈底**，最上面的乒乓球所在的位置，就是**栈顶**
+
+![](https://ask.qcloudimg.com/http-save/1752328/gon9gfqvs4.png)
+
+**压栈的不只有函数调用完成后的返回地址**
+
+比如函数A在调用B的时候，需要传输一些参数数据，这些参数数据在寄存器不够用的时候也会被压入栈中
+
+整个函数A所占用的所有内存空间，就是函数A的栈帧（Stack Frame）
+
+> Frame在中文里也有“相框”的意思，所以，每次到这里，都有种感觉，整个函数A所需要的内存空间就像是被这么一个“相框”给框了起来，放在了栈里面。
+
+而实际的程序栈布局，顶和底与我们的乒乓球桶相比是倒过来的
+
+底在最上面，顶在最下面，这样的布局是因为栈底的内存地址是在一开始就固定的。而一层层压栈之后，栈顶的内存地址是在逐渐变小而不是变大
+
+![](https://ask.qcloudimg.com/http-save/1752328/kufrh763at.png)
+
+对应上面函数add的汇编代码，我们来仔细看看，main函数调用add函数时
+
+- add函数入口在0～1行
+- add函数结束之后在12～13行
+
+在调用第34行的call指令时，会把当前的PC寄存器里的下一条指令的地址压栈，保留函数调用结束后要执行的指令地址
+
+- 而add函数的第0行，push rbp指令，就是在压栈
+这里的rbp又叫**栈帧指针（Frame Pointer）**，存放了当前栈帧位置的寄存器。push rbp就把之前调用函数，也就是main函数的栈帧的栈底地址，压到栈顶。
+- 第1行的一条命令mov rbp, rsp，则是把rsp这个栈指针（Stack Pointer）的值复制到rbp里，而rsp始终会指向栈顶
+这个命令意味着，rbp这个栈帧指针指向的地址，变成当前最新的栈顶，也就是add函数的栈帧的栈底地址了。
+- 在函数add执行完成之后，又会分别调用第12行的pop rbp
+将当前的栈顶出栈,这部分操作维护好了我们整个栈帧
+- 然后调用第13行的ret指令，这时候同时要把call调用的时候压入的PC寄存器里的下一条指令出栈，更新到PC寄存器中，将程序的控制权返回到出栈后的栈顶。
+
+# 2 构造Stack Overflow
+
+通过引入栈，我们可以看到，无论有多少层的函数调用，或者在函数A里调用函数B，再在函数B里调用A
+
+这样的递归调用，我们都只需要通过维持rbp和rsp，这两个维护栈顶所在地址的寄存器，就能管理好不同函数之间的跳转
+
+不过，栈的大小也是有限的。如果函数调用层数太多，我们往栈里压入它存不下的内容，程序在执行的过程中就会遇到栈溢出的错误，这就是**stack overflow**
+
+**构造一个栈溢出的错误**
+
+并不困难，最简单的办法，就是我们上面说的**Infiinite Mirror Effect**的方式，让函数A调用自己，并且不设任何终止条件
+
+这样一个无限递归的程序，在不断地压栈过程中，将整个栈空间填满，并最终遇上stack overflow。
+
+```
+int a()
+{
+  return a();
+}
+
+
+int main()
+{
+  a();
+  return 0;
+}
+```
+
+除了无限递归，递归层数过深，在栈空间里面创建非常占内存的变量（比如一个巨大的数组），这些情况都很可能给你带来stack overflow
+
+相信你理解了栈在程序运行的过程里面是怎么回事，未来在遇到stackoverflow这个错误的时候，不会完全没有方向了。
+
+# 3 利用函数内联实现性能优化
+
+上面我们提到一个方法，把一个实际调用的函数产生的指令，直接插入到的位置，来替换对应的函数调用指令。尽管这个通用的函数调用方案，被我们否决了，但是如果被调用的函数里，没有调用其他函数，这个方法还是可以行得通的。
+
+事实上，这就是一个常见的编译器进行自动优化的场景，我们通常叫**函数内联(Inline)**
+
+只要在GCC编译的时候，加上对应的一个让编译器自动优化的参数-O，编译器就会在可行的情况下，进行这样的指令替换。
+
+- 案例
+![](https://ask.qcloudimg.com/http-save/1752328/ko83ajuodf.png)
+为了避免编译器优化掉太多代码，小小修改了一下function.c，让参数x和y都变成了，通过随机数生成，并在代码的最后加上将u通过printf打印
+
+```
+[hadoop@JavaEdge Documents]$ vim function.c
+[hadoop@JavaEdge Documents]$ gcc -g -c -O function.c 
+[hadoop@JavaEdge Documents]$ objdump -d -M intel -S function.o
+
+function.o:     file format elf64-x86-64
+
+
+Disassembly of section .text:
+
+0000000000000000 <main>:
+{
+    return a+b;
+}
+
+int main()
+{
+   0:	53                   	push   rbx
+   1:	bf 00 00 00 00       	mov    edi,0x0
+   6:	e8 00 00 00 00       	call   b <main+0xb>
+   b:	89 c7                	mov    edi,eax
+   d:	e8 00 00 00 00       	call   12 <main+0x12>
+  12:	e8 00 00 00 00       	call   17 <main+0x17>
+  17:	89 c3                	mov    ebx,eax
+  19:	e8 00 00 00 00       	call   1e <main+0x1e>
+  1e:	89 c1                	mov    ecx,eax
+  20:	bf 67 66 66 66       	mov    edi,0x66666667
+  25:	89 d8                	mov    eax,ebx
+  27:	f7 ef                	imul   edi
+  29:	d1 fa                	sar    edx,1
+  2b:	89 d8                	mov    eax,ebx
+  2d:	c1 f8 1f             	sar    eax,0x1f
+  30:	29 c2                	sub    edx,eax
+  32:	8d 04 92             	lea    eax,[rdx+rdx*4]
+  35:	29 c3                	sub    ebx,eax
+  37:	89 c8                	mov    eax,ecx
+  39:	f7 ef                	imul   edi
+  3b:	c1 fa 02             	sar    edx,0x2
+  3e:	89 d7                	mov    edi,edx
+  40:	89 c8                	mov    eax,ecx
+  42:	c1 f8 1f             	sar    eax,0x1f
+  45:	29 c7                	sub    edi,eax
+  47:	8d 04 bf             	lea    eax,[rdi+rdi*4]
+  4a:	01 c0                	add    eax,eax
+  4c:	29 c1                	sub    ecx,eax
+#include <time.h>
+#include <stdlib.h>
+
+int static add(int a, int b)
+{
+    return a+b;
+  4e:	8d 34 0b             	lea    esi,[rbx+rcx*1]
+{
+    srand(time(NULL));
+    int x = rand() % 5;
+    int y = rand() % 10;
+    int u = add(x, y);
+    printf("u = %d\n", u);
+  51:	bf 00 00 00 00       	mov    edi,0x0
+  56:	b8 00 00 00 00       	mov    eax,0x0
+  5b:	e8 00 00 00 00       	call   60 <main+0x60>
+  60:	b8 00 00 00 00       	mov    eax,0x0
+  65:	5b                   	pop    rbx
+  66:	c3                   	ret    
+```
+
+上面的function.c的编译出来的汇编代码，没有把add函数单独编译成一段指令顺序，而是在调用u = add(x, y)的时候，直接替换成了一个add指令。
+
+除了依靠编译器的自动优化，你还可以在定义函数的地方，加上inline的关键字，来提示编译器对函数进行内联。
+
+内联带来的优化是，CPU需要执行的指令数变少了，根据地址跳转的过程不需要了，压栈和出栈的过程也不用了。
+
+不过内联并不是没有代价，内联意味着，我们把可以复用的程序指令在调用它的地方完全展开了。如果一个函数在很多地方都被调用了，那么就会展开很多次，整个程序占用的空间就会变大了。
+
+这样没有调用其他函数，只会被调用的函数，我们一般称之为**叶子函数（或叶子过程）**
+
+![](https://ask.qcloudimg.com/http-save/1752328/tbxu52xt3z.png)
+
+# 3 总结
+
+这一节，我们讲了一个程序的函数间调用，在CPU指令层面是怎么执行的。其中一定需要你牢记的，就是**程序栈**这个新概念。
+
+我们可以方便地通过压栈和出栈操作，使得程序在不同的函数调用过程中进行转移。而函数内联和栈溢出，一个是我们常常可以选择的优化方案，另一个则是我们会常遇到的程序Bug。
+
+通过加入了程序栈，我们相当于在指令跳转的过程种，加入了一个“记忆”的功能，能在跳转去运行新的指令之后，再回到跳出去的位置，能够实现更加丰富和灵活的指令执行流程。这个也为我们在程序开发的过程中，提供了“函数”这样一个抽象，使得我们在软件开发的过程中，可以复用代码和指令，而不是只能简单粗暴地复制、粘贴代码和指令。
+
+# 4 推荐阅读
+
+可以仔细读一下《深入理解计算机系统（第三版）》的3.7小节《过程》，进一步了解函数调用是怎么回事。
+
+另外，我推荐你花一点时间，通过搜索引擎搞清楚function.c每一行汇编代码的含义，这个能够帮你进一步深入了解程序栈、栈帧、寄存器以及Intel CPU的指令集。
+
+# 参考
+
+深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\344\270\200\357\274\211- \351\227\250\347\224\265\350\267\257\347\232\204\"\345\215\203\351\207\214\344\274\240\351\237\263\".md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\344\270\200\357\274\211- \351\227\250\347\224\265\350\267\257\347\232\204\"\345\215\203\351\207\214\344\274\240\351\237\263\".md"
new file mode 100644
index 0000000000..9efb8ebeb7
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\344\270\200\357\274\211- \351\227\250\347\224\265\350\267\257\347\232\204\"\345\215\203\351\207\214\344\274\240\351\237\263\".md"	
@@ -0,0 +1,134 @@
+![](https://ask.qcloudimg.com/http-save/1752328/jfhxac13bw.png)
+
+人用纸和笔来做运算，都是用十进制，直接用十进制和我们最熟悉的符号不是最简单么？
+
+为什么计算机里我们最终要选择二进制呢？
+
+来看看，计算机在硬件层面究竟是怎么表示二进制的，你就会明白，为什么计算机会选择二进制。
+
+# 1 怎么做到“千里传书”
+
+> 马拉松的故事相信你听说过。公元前490年，在雅典附近的马拉松海边，发生了波斯和希腊之间的希波战争。雅典和斯巴达领导的希腊联军胜利之后，雅典飞毛腿菲迪皮德斯跑了历史上第一个马拉松，回雅典报喜。这个时候，人们在远距离报信的时候，采用的是派人跑腿，传口信或者送信的方式。
+
+但是，这样靠人传口信或者送信的方式，实在是太慢了
+
+在军事用途中，信息能否更早更准确地传递出去经常是事关成败的大事
+
+所以我们看到中国古代的军队有“击鼓进军”和“鸣金收兵”，通过打鼓和敲钲发出不同的声音，来传递军队的号令。
+
+如果我们把军队当成一台计算机，那“金”和“鼓”就是这台计算机的“1”和“0”
+
+我们可以通过不同的编码方式，来指挥这支军队前进、后退、转向、追击等等。
+
+“金”和“鼓”比起跑腿传口信，固然效率更高了，但是能够传递的范围还是非常有限，超出个几公里恐怕就听不见了。于是，人们发明了更多能够往更远距离传信的方式，比如海上的灯塔、长城上的烽火台。因为光速比声速更快，传的距离也可以更远。
+
+- 亚历山大港外的法罗斯灯塔，位列世界七大奇迹之一，可惜现在只剩下遗迹了。可见人类社会很早就学会使用类似二进制信号的方式来传输信息
+![](https://ask.qcloudimg.com/http-save/1752328/zmmgt39vdy.png)
+但是，这些传递信息的方式都面临一个问题，就是受限于只有“1”和“0”这两种信号，不能传递太复杂的信息，那电报的发明就解决了这个问题。
+
+从信息编码的角度来说，金、鼓、灯塔、烽火台类似电报的二进制编码
+
+电报传输的信号有两种，一种是短促的点信号（dot信号），一种是长一点的划信号（dash信号）
+
+我们把“点”当成“1”，把“划”当成“0”。这样一来，我们的电报信号就是另一种特殊的二进制编码了
+
+电影里最常见的电报信号是“SOS”，这个信号表示出来就是 “点点点划划划点点点”。
+
+比起灯塔和烽火台这样的设备，电报信号有两个明显的优势
+
+- 信号的传输距离迅速增加
+电报本质上是通过电信号来进行传播的，所以从输入信号到输出信号基本上没有延时
+- 输入信号的速度加快了很多
+电报机只有一个按钮，按下就是输入信号，按的时间短一点，就是发出了一个“点”信号
+按的时间长一些，就是一个“划”信号
+一个手指，就能快速发送电报。
+- 一个摩尔斯电码的电报机
+![](https://ask.qcloudimg.com/http-save/1752328/csg7idsg3y.png)
+
+制造一台电报机也非常容易
+
+电报机本质上就是一个“蜂鸣器+长长的电线+按钮开关”
+
+> 蜂鸣器装在接收方手里，开关留在发送方手里。双方用长长的电线连在一起。当按钮开关按下的时候，电线的电路接通了，蜂鸣器就会响。短促地按下，就是一个短促的点信号；按的时间稍微长一些，就是一个稍长的划信号。
+> ![](https://ask.qcloudimg.com/http-save/1752328/s8yfwfci8l.png)
+
+有了电池开关和铃铛，你就有了最简单的摩尔斯电码发报机
+
+# 2 理解继电器，给跑不动的信号+1s
+
+有了电报机，只要铺设好电报线路，就可以传输我们需要的讯息了
+
+但是这里面又出现了一个新的挑战，就是随着电线的线路越长，电线的电阻就越大
+
+当电阻很大，而电压不够的时候，即使你按下开关，蜂鸣器也不会响。
+
+你可能要说了，我们可以提高电压或者用更粗的电线，使得电阻更小，这样就可以让整个线路铺得更长一些
+
+但是这个再长，也没办法从北京铺设到上海吧
+
+要想从北京把电报发到上海，我们还得想些别的办法。
+
+对于电报来说，电线太长了，使得线路接通也没有办法让蜂鸣器响起来
+
+那么，我们就不要一次铺太长的线路，而把一小段距离当成一个线路，也和驿站建立一个小电报站。我们在小电报站里面安排一个电报员，他听到上一个小电报站发来的信息，然后原样输入，发到下一个电报站去
+
+这样，我们的信号就可以一段段传输下去，而不会因为距离太长，导致电阻太大，没有办法成功传输信号。为了能够实现这样接力传输信号，在电路里面，工程师们造了一个叫作**继电器（Relay）** 的设备。
+
+- 中继，其实就是不断地通过新的电源重新放大已经开始衰减的原有信号![](https://ask.qcloudimg.com/http-save/1752328/s4uucnv1z8.png)
+
+事实上，这个过程中，我们需要在每一阶段原样传输信号，是不是可以设计一个设备来代替这个电报员？
+
+相比使用人工听蜂鸣器的声音，来重复输入信号，利用电磁效应和磁铁，来实现这个事情会更容易。
+
+我们把原先用来输出声音的蜂鸣器，换成一段环形的螺旋线圈，让电路封闭通上电。因为电磁效应，这段螺旋线圈会产生一个带有磁性的电磁场。我们原本需要输入的按钮开关，就可以用一块磁力稍弱的磁铁把它设在“关”的状态。这样，按下上一个电报站的开关，螺旋线圈通电产生了磁场之后，磁力就会把开关“吸”下来，接通到下一个电报站的电路。
+
+如果我们在中间所有小电报站都用这个“螺旋线圈+磁性开关”的方式，来替代蜂鸣器和普通开关，而只在电报的始发和终点用普通的开关和蜂鸣器，我们就有了一个拆成一段一段的电报线路，接力传输电报信号。这样，我们就不需要中间安排人力来听打电报内容，也不需要解决因为线缆太长导致的电阻太大或者电压不足的问题了。我们只要在终点站安排电报员，听写最终的电报内容就可以了。这样是不是比之前更省事了？
+
+事实上，继电器还有一个名字就叫作电驿，这个“驿”就是驿站的驿，可以说非常形象了
+
+这个接力的策略不仅可以用在电报中，在通信类的科技产品中其实都可以用到。
+
+比如说，你在家里用WiFi，如果你的屋子比较大，可能某些房间的信号就不好。你可以选用支持“中继”的WiFi路由器，在信号衰减的地方，增加一个WiFi设备，接收原来的WiFi信号，再重新从当前节点传输出去。这种中继对应的英文名词和继电器是一样的，也叫Relay。
+
+再比如说，我们现在互联网使用的光缆，是用光信号来传输数据。随着距离的增长、反射次数的增加，信号也会有所衰减，我们同样要每隔一段距离，来增加一个用来重新放大信号的中继。
+
+有了继电器之后，我们不仅有了一个能够接力传输信号的方式，更重要的是，和输入端通过开关的“开”和“关”来表示“1”和“0”一样，我们在输出端也能表示“1”和“0”了。
+
+输出端的作用，不仅仅是通过一个蜂鸣器或者灯泡，提供一个供人观察的输出信号，通过“螺旋线圈 + 磁性开关”，使得我们有“开”和“关”这两种状态，这个“开”和“关”表示的“1”和“0”，还可以作为后续线路的输入信号，让我们开始可以通过最简单的电路，来组合形成我们需要的逻辑。
+
+通过这些线圈和开关，我们也可以很容易地创建出 “与（AND）”“或（OR）”“非（NOT）”这样的逻辑。我们在输入端的电路上，提供串联的两个开关，只有两个开关都打开，电路才接通，输出的开关也才能接通，这其实就是模拟了计算机里面的“与”操作。
+
+我们在输入端的电路，提供两条独立的线路到输出端，两条线路上各有一个开关，那么任何一个开关打开了，到输出端的电路都是接通的，这其实就是模拟了计算机中的“或”操作。
+
+当我们把输出端的“螺旋线圈+磁性开关”的组合，从默认关掉，只有通电有了磁场之后打开，换成默认是打开通电的，只有通电之后才关闭，我们就得到了一个计算机中的“非”操作。输出端开和关正好和输入端相反。这个在数字电路中，也叫作**反向器（Inverter）**
+
+![](https://ask.qcloudimg.com/http-save/1752328/z3c8dedjuj.png)
+
+反向器的电路，其实就是开关从默认关闭变成默认开启而已
+
+与、或、非的电路都非常简单，要想做稍微复杂一点的工作，我们需要很多电路的组合。不过，这也彰显了现代计算机体系中一个重要的思想，就是通过分层和组合，逐步搭建起更加强大的功能。
+
+回到我们前面看的电报机原型，虽然一个按钮开关的电报机很“容易”操作，但是却不“方便”操作。因为电报员要熟记每一个字母对应的摩尔斯电码，并且需要快速按键来进行输入。一旦输错很难纠正。但是，因为电路之间可以通过与、或、非组合完成更复杂的功能，我们完全可以设计一个和打字机一样的电报机，每按下一个字母按钮，就会接通一部分电路，然后把这个字母的摩尔斯电码输出出去。
+
+虽然在电报机时代，我们没有这么做，但是在计算机时代，我们其实就是这样做的。我们不再是给计算机“0”和“1”，而是通过千万个晶体管组合在一起，最终使得我们可以用“高级语言”，指挥计算机去干什么。
+
+# 3 总结延伸
+
+可以说，电报是现代计算机的一个最简单的原型。它和我们现在使用的现代计算机有很多相似之处。我们通过电路的“开”和“关”，来表示“1”和“0”。就像晶体管在不同的情况下，表现为导电的“1”和绝缘的“0”的状态。
+
+我们通过电报机这个设备，看到了如何通过“螺旋线圈+开关”，来构造基本的逻辑电路，我们也叫门电路
+
+- 一方面，我们可以通过继电器或者中继，进行长距离的信号传输
+- 另一方面，我们也可以通过设置不同的线路和开关状态，实现更多不同的信号表示和处理方式，这些线路的连接方式其实就是我们在数字电路中所说的门电路。而这些门电路，也是我们创建CPU和内存的基本逻辑单元。我们的各种对于计算机二进制的“0”和“1”的操作，其实就是来自于门电路，叫作组合逻辑电路。
+
+# 4 推荐阅读
+
+《编码：隐匿在计算机软硬件背后的语言》第6～11章，是一个很好的入门材料，可以帮助深入理解数字电路，值得你花时间好好读一读
+
+![](https://ask.qcloudimg.com/http-save/1752328/vd7igp0ezh.png)
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\357\274\211- \"\347\203\253\347\203\253\347\203\253\"\344\271\261\347\240\201\347\232\204\347\224\261\346\235\245.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\357\274\211- \"\347\203\253\347\203\253\347\203\253\"\344\271\261\347\240\201\347\232\204\347\224\261\346\235\245.md"
new file mode 100644
index 0000000000..67d698c3a7
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\215\201\357\274\211- \"\347\203\253\347\203\253\347\203\253\"\344\271\261\347\240\201\347\232\204\347\224\261\346\235\245.md"	
@@ -0,0 +1,153 @@
+![](https://ask.qcloudimg.com/http-save/1752328/behwbrbqz3.png)
+
+> 程序 = 算法 + 数据结构
+
+对应到计算机的组成原理(硬件层面)
+
+- 算法 --- 各种计算机指令
+- 数据结构 --- 二进制数据
+
+计算机用0/1组成的二进制，来表示所有信息
+
+- 程序指令用到的机器码，是使用二进制表示的
+- 存储在内存里面的字符串、整数、浮点数也都是用二进制表示的
+
+万物在计算机里都是0和1，搞清楚各种数据在二进制层面是怎么表示的，是我们的必修课。
+
+在实际应用中最常遇到的问题，也就是文本字符串是怎么表示成二进制的，特别是我们会遇到的乱码究竟是怎么回事儿
+
+在开发的时候，所说的Unicode和UTF-8之间有什么关系。
+
+理解了这些，相信以后遇到任何乱码问题，你都能手到擒来了。
+
+# 1 理解二进制的“逢二进一”
+
+二进制和我们平时用的十进制，并没有本质区别，只是平时是“逢十进一”，这里变成了“逢二进一”
+
+每一位，相比于十进制下的0～9这十个数字，我们只能用0和1这两个数字。
+
+任何一个十进制的整数，都能通过二进制表示出来
+
+把一个二进制数，对应到十进制，非常简单，就是把从右到左的第N位，乘上一个2的N次方，然后加起来，就变成了一个十进制数
+
+当然，既然二进制是一个面向程序员的“语言”，这个从右到左的位置，自然是从0开始的。
+
+比如_0011_这个二进制数，对应的十进制表示，就是
+
+> $0×2^3+0×2^2+1×2^1+1×2^0$
+> $=3$
+
+代表十进制的3
+
+对应地，如果我们想要把一个十进制的数，转化成二进制，使用**短除法**就可以了
+
+也就是，把十进制数除以2的余数，作为最右边的一位。然后用商继续除以2，把对应的余数紧靠着刚才余数的右侧，这样递归迭代，直到商为0就可以了。
+
+- 比如，我们想把13这个十进制数，用短除法转化成二进制，需要经历以下几个步骤：
+![](https://ask.qcloudimg.com/http-save/1752328/q88074vf1x.png)
+因此，对应的二进制数，就是1101
+
+刚才我们举的例子都是正数，对于负数来说，情况也是一样的吗？
+
+我们可以把一个数最左侧的一位，当成是对应的正负号，比如0为正数，1为负数，这样来进行标记。
+
+这样，一个4位的二进制数， 0011就表示为+3。而1011最左侧的第一位是1，所以它就表示-3。这个其实就是整数的**原码表示法**
+
+原码表示法有一个很直观的缺点就是，0可以用两个不同的编码来表示，1000代表0， 0000也代表0。习惯万事一一对应的程序员看到这种情况，必然会被“逼死”。
+
+于是，我们就有了另一种表示方法。我们仍然通过最左侧第一位的0和1，来判断这个数的正负。但是，我们不再把这一位当成单独的符号位，在剩下几位计算出的十进制前加上正负号，而是在计算整个二进制值的时候，在左侧最高位前面加个负号。
+
+比如，一个4位的二进制补码数值1011，转换成十进制，就是
+
+> $-1×2^3+0×2^2+1×2^1+1×2^0$
+> $=-5$
+
+如果最高位是1，这个数必然是负数；最高位是0，必然是正数。并且，只有0000表示0，1000在这样的情况下表示-8。一个4位的二进制数，可以表示从-8到7这16个整数，不会白白浪费一位。
+
+当然更重要的一点是，用补码来表示负数，使得我们的整数相加变得很容易，不需要做任何特殊处理，只是把它当成普通的二进制相加，就能得到正确的结果。
+
+我们简单一点，拿一个4位的整数来算一下，比如 -5 + 4 = -1，-5 + 6 = 1
+
+我们各自把它们转换成二进制来看一看。如果它们和无符号的二进制整数的加法用的是同样的计算方式，这也就意味着它们是同样的电路。
+
+![](https://ask.qcloudimg.com/http-save/1752328/uwxc817k5l.png)
+
+# 2 字符串的表示，从编码到数字
+
+不仅数值可以用二进制表示，字符乃至更多的信息都能用二进制表示
+
+最典型的例子就是**字符串（Character String）**
+
+最早计算机只需要使用英文字符，加上数字和一些特殊符号，然后用8位的二进制，就能表示我们日常需要的所有字符了，这个就是我们常常说的**ASCII码（American Standard Code for Information Interchange，美国信息交换标准代码）**
+
+![](https://ask.qcloudimg.com/http-save/1752328/nkc6zbx230.png)
+
+ASCII码就好比一个字典，用8位二进制中的128个不同的数，映射到128个不同的字符里
+
+> 比如，小写字母a在ASCII里面，就是第97个，也就是二进制的0110 0001，对应的十六进制表示就是 61。而大写字母 A，就是第65个，也就是二进制的0100 0001，对应的十六进制表示就是41。
+
+在ASCII码里面，数字9不再像整数表示法里一样，用0000 1001来表示，而是用0011 1001 来表示。字符串15也不是用0000 1111 这8位来表示，而是变成两个字符1和5连续放在一起，也就是 0011 0001 和 0011 0101，需要用两个8位来表示。
+
+我们可以看到，最大的32位整数，就是2147483647。如果用整数表示法，只需要32位就能表示了。但是如果用字符串来表示，一共有10个字符，每个字符用8位的话，需要整整80位。比起整数表示法，要多占很多空间。
+
+这也是为什么，很多时候我们在存储数据的时候，要采用二进制序列化这样的方式，而不是简单地把数据通过CSV或者JSON，这样的文本格式存储来进行序列化。不管是整数也好，浮点数也好，采用二进制序列化会比存储文本省下不少空间。
+
+ASCII码只表示了128个字符，一开始倒也堪用，毕竟计算机是在美国发明的
+
+然而随着越来越多的不同国家的人都用上了计算机，想要表示譬如中文这样的文字，128个字符显然是不太够用的。于是，计算机工程师们开始各显神通，给自己国家的语言创建了对应的**字符集（Charset）和字符编码（Character Encoding）**
+
+## 字符集
+
+表示的可以是字符的一个集合
+
+比如“中文”就是一个字符集，不过这样描述一个字符集并不准确
+
+想要更精确一点，我们可以说，“第一版《新华字典》里面出现的所有汉字”，这是一个字符集。这样，我们才能明确知道，一个字符在不在这个集合里面
+
+比如，我们日常说的Unicode，其实就是一个字符集，包含了150种语言的14万个不同的字符。
+
+## 字符编码
+
+则是对于字符集里的这些字符，怎么一一用二进制表示出来的一个字典
+
+我们上面说的Unicode，就可以用UTF-8、UTF-16，乃至UTF-32来进行编码，存储成二进制。所以，有了Unicode，其实我们可以用不止UTF-8一种编码形式，我们也可以自己发明一套 GT-32 编码，比如就叫作Geek Time 32好了。只要别人知道这套编码规则，就可以正常传输、显示这段代码。
+
+![](https://ask.qcloudimg.com/http-save/1752328/sm2e79eor5.png)
+
+同样的文本，采用不同的编码存储下来。如果另外一个程序，用一种不同的编码方式来进行解码和展示，就会出现乱码。这就好像两个军队用密语通信，如果用错了密码本，那看到的消息就会不知所云。在中文世界里，最典型的就是“手持两把锟斤拷，口中疾呼烫烫烫”的典故。
+
+没有经验的同学，在看到程序输出“烫烫烫”的时候，以为是程序让CPU过热发出报警，于是尝试给CPU降频来解决问题。
+
+既然今天要彻底搞清楚编码知识，我们就来弄清楚“锟斤拷”和“烫烫烫”的来龙去脉。
+
+## “锟斤拷”的来源
+
+如果我们想要用Unicode编码记录一些文本，特别是一些遗留的老字符集内的文本，但是这些字符在Unicode中可能并不存在。于是，Unicode会统一把这些字符记录为U+FFFD这个编码
+
+如果用UTF-8的格式存储下来，就是\xef\xbf\xbd。如果连续两个这样的字符放在一起，\xef\xbf\xbd\xef\xbf\xbd，这个时候，如果程序把这个字符，用GB2312的方式进行decode，就会变成“锟斤拷”。这就好比我们用GB2312这本密码本，去解密别人用UTF-8加密的信息，自然没办法读出有用的信息。
+
+而“烫烫烫”，则是因为如果你用了Visual Studio的调试器，默认使用MBCS字符集
+
+“烫”在里面是由0xCCCC来表示的，而0xCC又恰好是未初始化的内存的赋值。于是，在读到没有赋值的内存地址或者变量的时候，电脑就开始大叫“烫烫烫”了。
+
+# 3 总结延伸
+
+到这里，相信你发现，我们可以用二进制编码的方式，表示任意的信息。只要建立起字符集和字符编码，并且得到大家的认同，我们就可以在计算机里面表示这样的信息了。所以说，如果你有心，要发明一门自己的克林贡语并不是什么难事。
+
+不过，光是明白怎么把数值和字符在逻辑层面用二进制表示是不够的。我们在计算机组成里面，关心的不只是数值和字符的逻辑表示，更要弄明白，在硬件层面，这些数值和我们一直提的晶体管和电路有什么关系。下一讲，我就会为你揭开神秘的面纱。我会从时钟和D触发器讲起，最终让你明白，计算机里的加法，是如何通过电路来实现的。
+
+# 4 推荐阅读
+
+- 《编码：隐匿在计算机软硬件背后的语言》
+![](https://ask.qcloudimg.com/http-save/1752328/d1owkw56nq.png)
+从电报机到计算机，这本书讲述了很多计算设备的历史故事，当然，也包含了二进制及其背后对应的电路原理。
+
+# 参考
+
+- 深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)
\ No newline at end of file
diff --git "a/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\233\233\357\274\211- \347\216\251\347\216\251\347\272\270\345\270\246\347\274\226\347\250\213.md" "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\233\233\357\274\211- \347\216\251\347\216\251\347\272\270\345\270\246\347\274\226\347\250\213.md"
new file mode 100644
index 0000000000..a9efa397b9
--- /dev/null
+++ "b/\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206/\351\207\215\345\255\246\350\256\241\347\256\227\346\234\272\347\273\204\346\210\220\345\216\237\347\220\206\357\274\210\345\233\233\357\274\211- \347\216\251\347\216\251\347\272\270\345\270\246\347\274\226\347\250\213.md"	
@@ -0,0 +1,229 @@
+- 你在学写程序的时候，有没有想过，古老年代的计算机程序是怎么写出来的？![](https://ask.qcloudimg.com/http-save/1752328/fpfs9776q8.png)
+
+当年写程序，不像现在这样，都是用一种古老的物理设备，叫作“打孔卡（Punched Card）”
+
+用这种设备写程序，没法像今天，掏出键盘就能打字，而是要先在脑海/纸写出程序，然后在纸带/卡片上打洞
+
+这样，要写的程序、要处理的数据，就变成一条条纸带或者一张张卡片，之后再交给当时的计算机去处理
+
+- 上世纪60年代晚期或70年代初期，Arnold Reinold拍摄的FORTRAN计算程序的穿孔卡照片
+![](https://ask.qcloudimg.com/http-save/1752328/yt6jzl6i5v.png)
+人们在特定的位置上打洞或者不打洞，来代表“0”或者“1”。
+
+为什么早期的计算机程序要使用打孔卡，而不能像我们现在一样，用C或者Python这样的高级语言来写呢？
+
+因为计算机或者说CPU本身，并没有能力理解这些高级语言
+
+即使在2019年的今天，我们使用的现代个人计算机，仍然只能处理所谓的“机器码”，也就是一连串的“0”和“1”这样的数字。
+
+我们每天用高级语言的程序，最终是怎么变成一串串“0”和“1”的？这一串串“0”和“1”又是怎么在CPU中处理的？
+
+# 1 在软硬件接口中，CPU帮我们做的事
+
+CPU(Central Processing Unit，中央处理器)就是计算机的大脑
+
+- **硬件的角度**
+一个超大规模集成电路，通过电路实现了加法、乘法乃至各种各样的处理逻辑。
+- **软件工程师的角度**
+一个执行各种计算机指令（Instruction Code）的逻辑机器
+这里的计算机指令，就好比一门CPU能够听得懂的语言，即机器语言（Machine Language）
+
+**不同的CPU能够听懂的语言不太一样**
+
+个人PC用的是Intel的CPU，iPhone用的是ARM的CPU,这两者能听懂的语言就不太一样
+
+类似这样两种CPU各自支持的语言，就是两组不同的计算机指令集(Instruction Set)
+
+这里面的“Set”，其实就是数学上的集合，代表不同的单词、语法
+
+如果我们在自己电脑上写一个程序，然后把这个程序复制一下，装到自己的手机上，肯定是没办法正常运行的，因为这两者语言不通
+
+而一台电脑上的程序，简单复制一下到另外一台电脑上，通常就能正常运行，因为这两台CPU有着相同的指令集，它们语言相通
+
+**存储程序型计算机（Stored-program Computer）**
+
+计算机程序，不可能只有一条指令，而是成千上万条指令组成
+
+但CPU不能一直放着所有指令，所以程序平时是存储在存储器
+
+这种程序指令存储在存储器里面的计算机，我们就叫作
+
+**Plugboard Computer**
+
+在没有现代计算机之前，有着聪明才智的工程师们，早就发明了一种叫Plugboard Computer的计算设备
+
+在一个布满了各种插口和插座的板子上，工程师们用不同的电线来连接不同的插口和插座，从而来完成各种计算任务
+
+- IBM的Plugboard
+![](https://ask.qcloudimg.com/http-save/1752328/kfur1ku1ds.png)
+
+# 2 编译=>汇编 代码=>机器码
+
+代码，到底是怎么变成一条条计算机指令，最后被CPU执行的呢？
+
+- test.c
+![](https://ask.qcloudimg.com/http-save/1752328/js3k7kxsx.png)
+**编译（Compile）成汇编代码**
+要让这段程序在Linux跑起来，需要把整个程序翻译成**汇编语言**（ASM，Assembly Language）的程序
+
+针对汇编代码，可以再用汇编器（Assembler）翻译成机器码（Machine Code）
+
+这些机器码由“0”和“1”组成的机器语言表示,这一条条机器码，就是一条条的计算机指令
+
+这样一串串的16进制数字，就是我们CPU能够真正认识的计算机指令。
+
+在Linux上，可使用gcc和objdump，把对应的汇编代码和机器码都打印出来。
+
+![](https://ask.qcloudimg.com/http-save/1752328/8vxfbnpwgh.png)
+
+左侧一堆数字，就是一条条机器码
+
+右边一系列的push、mov、add、pop等，这些就是对应的汇编代码
+
+一行C语言代码，有时候只对应一条机器码和汇编代码，有时候则是对应两条机器码和汇编代码
+
+汇编代码和机器码之间是一一对应的。
+
+![](https://ask.qcloudimg.com/http-save/1752328/3bewisgjp0.png)
+
+实际在用GCC（GUC编译器套装，GUI Compiler Collectipon）编译器的时候，可直接把代码编译成机器码，为什么还需要汇编代码呢？
+
+那一串数字表示的机器码，摸不着头脑
+
+但即使你没有学过汇编代码，看的时候多少也能“猜”出一些这些代码的含义。
+
+汇编代码就是“**给程序员看的机器码**”
+
+也正因为这样，机器码和汇编代码是一一对应的
+
+很容易记住add、mov这些用英文表示的指令
+
+而8b 45 f8这样的指令，由于很难一下子看明白是在干什么，所以会非常难以记忆
+
+![](https://ask.qcloudimg.com/http-save/1752328/kdm63h20ih.png)
+
+从高级语言到汇编代码，再到机器码，就是一个日常开发程序，最终变成了CPU可以执行的计算机指令的过程。
+
+# 3 解析指令和机器码
+
+了解了这个过程，下面我们放大局部，来看看这一行行的汇编代码和机器指令，到底是什么意思。
+
+Intel CPU，有2000条左右的CPU指令，实在是太多了，没法一一讲解。不过一般来说，常见的指令可以分成五大类。
+
+## 算术类指令
+
+加减乘除，在CPU层面，都会变成一条条算术类指令
+
+## 数据传输类指令
+
+给变量赋值、在内存里读写数据，用的都是数据传输类指令。
+
+## 逻辑类指令
+
+逻辑上的与或非
+
+## 条件分支类指令
+
+日常的“if/else”
+
+## 无条件跳转指令
+
+写一些大一点的程序，我们常常需要写一些函数或者方法
+
+在调用函数的时候，其实就是发起了一个无条件跳转指令。
+
+![](https://ask.qcloudimg.com/http-save/1752328/7vv5rmgd03.png)
+
+汇编器是怎么把对应的汇编代码，翻译成为机器码的。
+
+不同的CPU有不同的指令集，也就对应着不同的汇编语言和不同的机器码
+
+为了方便你快速理解这个机器码的计算方式，我们选用最简单的MIPS指令集，来看看机器码是如何生成的。
+
+MIPS是一组由MIPS技术公司在80年代中期设计出来的CPU指令集。就在最近，MIPS公司把整个指令集和芯片架构都完全开源了。想要深入研究CPU和指令集的同学，推荐[一些资料](https://www.mips.com/mipsopen/)，可以自己了解下。
+
+![](https://ask.qcloudimg.com/http-save/1752328/txs50kegqh.png)
+
+MIPS的指令是一个32位的整数，高6位叫**操作码**（Opcode）
+
+也就是代表这条指令具体是一条什么样的指令，剩下的26位有三种格式，分别是R、I和J。
+
+**R指令**
+
+一般用来做算术和逻辑操作，里面有读取和写入数据的寄存器的地址
+
+如果是逻辑位移操作，后面还有位移操作的位移量
+
+而最后的功能码，则是在前面的操作码不够的时候，扩展操作码表示对应的具体指令的。
+
+**I指令**
+
+通常是用在数据传输、条件分支，以及在运算的时候使用的并非变量还是常数的时候
+
+这个时候，没有了位移量和操作码，也没有了第三个寄存器，而是把这三部分直接合并成了一个地址值或者一个常数。
+
+**J指令**
+
+一个跳转指令，高6位之外的26位都是一个跳转后的地址
+
+```
+add $t0,$s2,$s1
+```
+
+下面都用十进制来表示对应的代码。
+
+对应的MIPS指令里
+
+- opcode是0
+- rs代表第一个寄存器s1的地址是17
+- rt代表第二个寄存器s2的地址是18
+- rd代表目标的临时寄存器t0的地址是8
+- 因为不是位移操作，所以位移量是0
+
+把这些数字拼在一起，就变成了一个MIPS的加法指令。
+
+为了读起来方便，我们一般把对应的二进制数，用16进制表示出来
+
+在这里，也就是0X02324020。这个数字也就是这条指令对应的机器码。
+
+![](https://ask.qcloudimg.com/http-save/1752328/u2sn2l4d4c.png)
+
+回到开头我们说的打孔带
+
+- 打孔代表1
+- 没有打孔代表0
+- 用4行8列代表一条指令来打一个穿孔纸带，那么这条命令大概就长这样：
+![在这里插入图片描述](https://ask.qcloudimg.com/http-save/1752328/7yc15xlp3b.png)
+
+你应该学会了怎么作为人肉编译和汇编器，给纸带打孔编程了，不用再对那些用过打孔卡的前辈们顶礼膜拜了。
+
+# 4 总结
+
+打孔卡，其实就是一种存储程序型计算机。
+
+只是这整个程序的机器码，不是通过计算机编译出来的，而是由程序员的人脑“编译”成一张张卡片的
+
+对应的程序，也不是存储在设备里，而是存储成一张打好孔的卡片
+
+但是整个程序运行的逻辑和其他CPU的机器语言没有什么分别，也是处理一串“0”和“1”组成的机器码而已。
+
+我们看到了一个C语言程序，是怎么被编译成为汇编语言，乃至通过汇编器再翻译成机器码的。
+
+除了C这样的编译型的语言之外，不管是Python这样的解释型语言，还是Java这样使用虚拟机的语言，其实最终都是由不同形式的程序，把我们写好的代码，转换成CPU能够理解的机器码来执行的。
+
+只是解释型语言，是通过解释器在程序运行的时候逐句翻译，而Java这样使用虚拟机的语言，则是由虚拟机对编译出来的中间代码进行解释，或者即时编译成为机器码来最终执行。
+
+# 5 推荐阅读
+
+- 了解Intel CPU的指令集参看
+《计算机组成与设计：软/硬件接口》第5版的2.17小节
+
+# 参考
+
+深入浅出计算机组成原理
+
+# X 交流学习
+![](https://img-blog.csdnimg.cn/20190504005601174.jpg)
+## [Java交流群](https://jq.qq.com/?_wv=1027&k=5UB4P1T)
+## [博客](https://blog.csdn.net/qq_33589510)
+## [Github](https://github.com/Wasabi1234)

From 5e75b17244a65c5f8416c765b3a9710b40e54157 Mon Sep 17 00:00:00 2001
From: Wasabi1234 <sss2855845850@gmail.com>
Date: Thu, 29 Aug 2019 01:06:56 +0800
Subject: [PATCH 7/7] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E7=9B=AE=E5=BD=95?=
 =?UTF-8?q?=E7=B4=A2=E5=BC=95?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/README.md b/README.md
index 80ce0b2047..6491b54e8b 100644
--- a/README.md
+++ b/README.md
@@ -19,16 +19,18 @@
 
 ## 目录
 
-- [Java](#java)
-    - [JVM](#jvm)
-    - [Spring](#Spring)
-    - [Spring Boot](#SpringBoot)
-    - [Spring Cloud](#SpringCloud)
-    - [并发编程](#并发编程)
-    - [集合框架](#集合框架)
-- [职业发展](#职业发展)
-- [计算机组成原理](#计算机组成原理)
-- [面试系列](#面试系列)
+- [Java](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java)
+    - [JVM](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java/JVM)
+    - [Spring](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java/Spring)
+    - [Spring Boot](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java/SpringBoot)
+    - [Spring Cloud](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java/SpringCloud)
+    - [并发编程](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java/并发编程)
+    - [集合框架](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/Java/集合框架)
+- [职业发展](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/职业发展)
+- [计算机组成原理](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BB%84%E6%88%90%E5%8E%9F%E7%90%86)
+- [面试系列](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/面试系列)
+    - [突破Java面试系列](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/面试系列/突破Java面试系列)
+    - [高可用系统架构的设计](https://github.com/Wasabi1234/JavaEdge-Tutorial/tree/master/面试系列/高可用系统架构的设计)
 
 # 公众号