據海外媒體報導稱福特計畫推出一款全新新能源車型，其很有可能會命名為Model E。
福特公司把這款Model E定位於一款緊湊車型，這款車會推出混動、插電式混動以及純電動版本，主要取代的是純電動版福克斯以及混動版和插電式混動版C-MAX。
另外，福特公司將會投資16億美元的資金，在墨西哥San Luis Potosi建設全新的工廠，並且這款Model E也將會在這座工廠生產。這款車將在2018年正式亮相，在2019年投放市場。
本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
Spring Security是一個功能強大且高度可定製的身份驗證和訪問控制框架，它是用於保護基於Spring的應用程序的實際標準。
Spring Security是一個框架，致力於為Java應用程序提供身份驗證和授權。與所有Spring項目一樣，Spring Security的真正強大之處在於可以輕鬆擴展以滿足自定義要求。
更多信息可以查看官網：https://spring.io/projects/spring-security
新建一個SpringBoot的web項目spring-boot-security。
pom文件中不引入Spring Security，然後新建一個controller：
@RestController
public class AppController {
@GetMapping("/hello")
public String hello() {
return "Hello,spring security!";
}
}然後打開瀏覽器訪問：http://localhost:8080/hello，成功后返回：
Hello,spring security!pom文件中引入Spring Security的starter：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>打開瀏覽器再次訪問http://localhost:8080/hello，會被重定向到登錄頁http://localhost:8080/login，截圖如下：
要登錄系統，我們需要知道用戶名和密碼，Spring Security默認的用戶名是user，項目啟動的時候會生成默認密碼（在啟動日誌中可以看到），輸入用戶名和密碼后就可以訪問/hello接口了。
當然也可以自定義用戶名密碼，在配置文件添加如下內容即可：
spring.security.user.name=java_suisui
spring.security.user.password=123456上面說過Spring Security的功能有“認證”和“授權”，下面通過一個簡單的例子實現下自定義的認證和授權。
假設系統中有兩個角色：
按照下面步驟操作即可。
對於用戶名、密碼、登錄頁面、訪問權限等都可以在 WebSecurityConfigurerAdapter 的實現類中配置。
WebSecurityConfig代碼如下：
/**
* 配置類
* @Author java_suisui
*
*/
@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
//配置內存中的 用戶名、密碼和角色
auth.inMemoryAuthentication().passwordEncoder(new MyPasswordEncoder()).withUser("user").password("123456").roles("USER");
auth.inMemoryAuthentication().passwordEncoder(new MyPasswordEncoder()).withUser("admin").password("123456").roles("ADMIN");
}
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/login").permitAll()
.antMatchers("/user").hasRole("USER") //訪問 /user這個接口，需要有USER角色
.antMatchers("/admin").hasRole("ADMIN")
.anyRequest().authenticated() //剩餘的其他接口，登錄之後就能訪問
.and()
.formLogin().defaultSuccessUrl("/hello");
}
}內存用戶驗證時，Spring Boot 2.0以上版本引用的security 依賴是 spring security 5.X版本，此版本需要提供一個PasswordEncorder的實例。
MyPasswordEncoder代碼如下：
public class MyPasswordEncoder implements PasswordEncoder {
@Override
public String encode(CharSequence rawPassword) {
return rawPassword.toString();
}
@Override
public boolean matches(CharSequence rawPassword, String encodedPassword) {
return encodedPassword.equals(rawPassword);
}
}瀏覽器打開http://localhost:8080/login，
如果使用user登錄后訪問/admin，會報403錯誤，具體錯誤信息如下：
Whitelabel Error Page
This application has no explicit mapping for /error, so you are seeing this as a fallback.
Tue Nov 19 16:26:28 CST 2019
There was an unexpected error (type=Forbidden, status=403).
Forbidden結果和我們預期的一致，說明簡單的自定義認證和授權功能已經實現了。
完整源碼地址：
推薦閱讀
Java碎碎念，一個堅持原創的公眾號，為您提供一系列系統架構、微服務、Java、SpringBoot、SpringCloud等高質量技術文章。
如果覺得文章不錯，希望可以隨手轉發或者”在看“哦，非常感謝哈！
關注下方公眾號后回復「1024」，有驚喜哦！
本文由博客一文多發平台 發布！
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
1 apiVersion: v1 #必選，版本號，例如v1,版本號必須可以用 kubectl api-versions 查詢到 2 kind: Pod #必選，Pod 3 metadata: #必選，元數據 4 name: string #必選，Pod名稱，需符合RFC 1035規範 5 namespace: string #必選，Pod所屬的命名空間，默認為"default" 6 labels: #自定義標籤 7 - name: string #自定義標籤名字 8 annotations: #自定義註釋列表 9 - name: string 10 spec: #必選，Pod中容器的詳細定義 11 containers: #必選，Pod中容器列表 12 - name: string #必選，容器名稱，需符合RFC 1035規範 13 image: string #必選，容器的鏡像名稱 14 imagePullPolicy: [ Always|Never|IfNotPresent ] #獲取鏡像的策略，Alawys表示每次都嘗試下載鏡像，IfnotPresent表示優先使用本地鏡像,否則下載鏡像，Nerver表示僅使用本地鏡像 15 command: [string] #容器的啟動命令列表，如不指定，使用打包時使用的啟動命令 16 args: [string] #容器的啟動命令參數列表 17 workingDir: string #容器的工作目錄 18 volumeMounts: #掛載到容器內部的存儲卷配置 19 - name: string #引用pod定義的共享存儲卷的名稱，需用volumes[]部分定義的的卷名 20 mountPath: string #存儲卷在容器內mount的絕對路徑，應少於512字符 21 readOnly: boolean #是否為只讀模式，默認為讀寫模式 22 ports: #需要暴露的端口庫號列表 23 - name: string #端口的名稱 24 containerPort: int #容器需要監聽的端口號 25 hostPort: int #容器所在主機需要監聽的端口號，默認與Container相同 26 protocol: string #端口協議，支持TCP和UDP，默認TCP 27 env: #容器運行前需設置的環境變量列表 28 - name: string #環境變量名稱 29 value: string #環境變量的值 30 resources: #資源限制和請求的設置 31 limits: #資源限制的設置 32 cpu: string #CPU的限制，單位為core數，將用於docker run --cpu-shares參數 33 memory: string #內存限制，單位可以為Mib/Gib，將用於docker run --memory參數 34 requests: #資源請求的設置 35 cpu: string #CPU請求，容器啟動的初始可用數量 36 memory: string #內存請求,容器啟動的初始可用數量 37 livenessProbe: #對Pod內各容器健康檢查的設置，當探測無響應幾次后將自動重啟該容器，檢查方法有exec、httpGet和tcpSocket，對一個容器只需設置其中一種方法即可 38 exec: #對Pod容器內檢查方式設置為exec方式 39 command: [string] #exec方式需要制定的命令或腳本 40 httpGet: #對Pod內個容器健康檢查方法設置為HttpGet，需要制定Path、port 41 path: string 42 port: number 43 host: string 44 scheme: string 45 HttpHeaders: 46 - name: string 47 value: string 48 tcpSocket: #對Pod內個容器健康檢查方式設置為tcpSocket方式 49 port: number 50 initialDelaySeconds: 0 #容器啟動完成后首次探測的時間，單位為秒 51 timeoutSeconds: 0 #對容器健康檢查探測等待響應的超時時間，單位秒，默認1秒 52 periodSeconds: 0 #對容器監控檢查的定期探測時間設置，單位秒，默認10秒一次 53 successThreshold: 0 54 failureThreshold: 0 55 securityContext: 56 privileged: false 57 restartPolicy: [Always | Never | OnFailure] #Pod的重啟策略，Always表示一旦不管以何種方式終止運行，kubelet都將重啟，OnFailure表示只有Pod以非0退出碼退出才重啟，Nerver表示不再重啟該Pod 58 nodeSelector: obeject #設置NodeSelector表示將該Pod調度到包含這個label的node上，以key：value的格式指定 59 imagePullSecrets: #Pull鏡像時使用的secret名稱，以key：secretkey格式指定 60 - name: string 61 hostNetwork: false #是否使用主機網絡模式，默認為false，如果設置為true，表示使用宿主機網絡 62 volumes: #在該pod上定義共享存儲卷列表 63 - name: string #共享存儲卷名稱 （volumes類型有很多種） 64 emptyDir: {} #類型為emtyDir的存儲卷，與Pod同生命周期的一個臨時目錄。為空值 65 hostPath: string #類型為hostPath的存儲卷，表示掛載Pod所在宿主機的目錄 66 path: string #Pod所在宿主機的目錄，將被用於同期中mount的目錄 67 secret: #類型為secret的存儲卷，掛載集群與定義的secre對象到容器內部 68 scretname: string 69 items: 70 - key: string 71 path: string 72 configMap: #類型為configMap的存儲卷，掛載預定義的configMap對象到容器內部 73 name: string 74 items: 75 - key: string 76 path: string
Pod可以由1個或多個容器組合而成，通常對於緊耦合的兩個應用，應該組合成一個整體對外提供服務，則應該將這兩個打包為一個pod。
屬於一個Pod的多個容器應用之間相互訪問只需要通過localhost即可通信，這一組容器被綁定在一個環境中。
1 [root@k8smaster01 study]# vi frontend-localredis-pod.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: redis-php 6 label: 7 name: redis-php 8 spec: 9 containers: 10 - name: frontend 11 image: kubeguide/guestbook-php-frontend:localredis 12 ports: 13 - containersPort: 80 14 - name: redis-php 15 image: kubeguide/redis-master 16 ports: 17 - containersPort: 6379 18 19 [root@k8smaster01 study]# kubectl create -f frontend-localredis-pod.yaml 20
1 [root@k8smaster01 study]# kubectl get pods #READY為2/2，表示此Pod中運行了yaml定義的兩個容器 2 NAME READY STATUS RESTARTS AGE 3 redis-php 2/2 Running 0 7m45s 4 [root@k8smaster01 study]# kubectl describe pod redis-php #查看詳細信息 5
靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行創建，並且總是在kubelet所在的Node上運行。
創建靜態Pod有兩種方式：配置文件或者HTTP方式。
1 [root@k8snode01 ~]# mkdir -p /etc/kubelet.d 2 [root@k8snode01 ~]# vi /etc/kubelet.d/static-web.yaml 3 apiVersion: v1 4 kind: Pod 5 metadata: 6 name: static-web 7 label: 8 name: static-web 9 spec: 10 containers: 11 - name: static-web 12 image: nginx 13 ports: 14 - name: web 15 containersPort: 80 16 17 [root@k8snode01 ~]# vi /etc/systemd/system/kubelet.service 18 …… 19 --config=/etc/kubelet.d/ \· #加入此參數 20 …… 21 [root@k8snode01 ~]# systemctl daemon-reload 22 [root@k8snode01 ~]# systemctl restart kubelet.service #重啟kubelet 23 [root@k8snode01 ~]# docker ps #查看創建的pod
提示：由於靜態pod不能通過API Server進行管理，因此在Master節點執行刪除操作後會變為Pending狀態，且無法刪除。刪除該pod只能在其運行的node上，將定義POD的yaml刪除。
通過設置kubelet的啟動參數–mainfest-url，會定期從該URL下載Pod的定義文件，並以.yaml或.json文件的格式進行解析，從而創建Pod。
在同一個Pod中的多個容器能夠共享Pod級別的存儲就Volume。Volume可以被定義為各種類型，多個容器各自進行掛載操作，將一個Volume掛載為容器內部需要的目錄。
示例1：
Pod級別設置Volume “app-logs”，同時Pod包含兩個容器，Tomcat向該Volume寫日誌，busybox讀取日誌文件。
1 [root@k8smaster01 study]# vi pod-volume-applogs.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: volume-pod 6 spec: 7 containers: 8 - name: tomcat 9 image: tomcat 10 ports: 11 - containerPort: 8080 12 volumeMounts: 13 - name: app-logs 14 mountPath: /usr/local/tomcat/logs 15 - name: logreader 16 image: busybox 17 command: ["sh","-c","tail -f /logs/catalina*.log"] 18 volumeMounts: 19 - name: app-logs 20 mountPath: /logs 21 volumes: 22 - name: app-logs 23 emptyDir: {}
解釋：
Volume名：app-logs；
emptyDir：為Pod分配到Node的時候創建。無需指定宿主機的目錄文件，為Kubernetes自動分配的目錄。
1 [root@k8smaster01 study]# kubectl create -f pod-volume-applogs.yaml #創建 2 [root@k8smaster01 study]# kubectl get pods #查看 3 [root@k8smaster01 study]# kubectl logs volume-pod -c busybox #讀取log
1 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- ls /usr/local/tomcat/logs 2 catalina.2019-06-29.log localhost_access_log.2019-06-29.txt 3 host-manager.2019-06-29.log manager.2019-06-29.log 4 localhost.2019-06-29.log 5 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- tail /usr/local/tomcat/logs/catalina.2019-06-29.log
提示：通過tomcat容器可查看日誌，對比busybox通過共享Volume查看的日誌是否一致。
應用部署的一個最佳實踐是將應用所需的配置信息與程序進行分離，使程序更加靈活。將相應的應用打包為鏡像，可以通過環境變量或者外掛volume的方式在創建容器的時候進行配置注入，從而實現更好的復用。
Kubernetes提供一種統一的應用配置管理方案：ConfigMap。
ConfigMap供容器使用的主要場景：
ConfigMap以一個或多個key:value的形式定義。value可以是string也可以是一個文件內容，可以通過yaml配置文件或者通過kubectl create configmap 的方式創建configMap。
1 [root@k8smaster01 study]# vi cm-appvars.yaml 2 apiVersion: v1 3 kind: ConfigMap 4 metadata: 5 name: cm-appvars 6 data: 7 apploglevel: info 8 appdatadir: /var/data 9 10 [root@k8smaster01 study]# kubectl create -f cm-appvars.yaml 11 configmap/cm-appvars created 12 [root@k8smaster01 study]# kubectl get configmaps 13 NAME DATA AGE 14 cm-appvars 2 8s 15 [root@k8smaster01 study]# kubectl describe configmaps cm-appvars
1 [root@k8smaster01 study]# kubectl get configmaps cm-appvars -o yaml
語法1
1 # kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source
解釋：通過–from-file參數從文件中創建，可以指定key名稱，也可以制定多個key。
語法2
1 # kubectl create configmap NAME --from-file=config-files-dir
解釋：通過–from-file參數從目錄中創建，該目錄下的每個配置文件名都被設置為key，文件的內容被設置為value。
語法3
1 # kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2
解釋：通過–from-literal參數從文本中創建，直接將指定的key#=value#創建為ConfigMap的內容。
容器應用使用ConfigMap有兩種方式：
1 [root@k8smaster01 study]# vi cm-test-pod.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: cm-test-pod 6 spec: 7 containers: 8 - name: cm-test 9 image: busybox 10 command: ["/bin/sh","-c","env|grep APP"] #容器里執行查看環境變量的命令 11 env: 12 - name: APPLOGLEVEL #定義容器環境變量名稱 13 valueFrom: 14 configMapKeyRef: #環境變量的值來自ConfigMap 15 name: cm-appvars #指定來自cm-appvars的ConfigMap 16 key: apploglevel #key為apploglevel 17 - name: APPDATADIR 18 valueFrom: 19 configMapKeyRef: 20 name: cm-appvars 21 key: appdatadir 22 23 [root@k8smaster01 study]# kubectl create -f cm-test-pod.yaml 24 [root@k8smaster01 study]# kubectl get pods 25 NAME READY STATUS RESTARTS AGE 26 cm-test-pod 0/1 Completed 2 24s
【掛載形式-待補充】
pod擁有唯一的名字、IP地址，並且處於某個Namespace中。pod的容器內獲取pod的信息科通過Downward API實現。具體有以下兩種方式：
舉例1：通過Downward API將Pod的IP、名稱和所在的Namespace注入容器的環境變量。
1 [root@k8smaster01 study]# vi dapi-test-pod.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: dapi-test-pod 6 spec: 7 containers: 8 - name: test-container 9 image: busybox 10 command: [ "/bin/sh", "-c", "env" ] 11 env: 12 - name: MY_POD_NAME 13 valueFrom: 14 fieldRef: 15 fieldPath: metadata.name 16 - name: MY_POD_NAMESPACE 17 valueFrom: 18 fieldRef: 19 fieldPath: metadata.namespace 20 - name: MY_POD_IP 21 valueFrom: 22 fieldRef: 23 fieldPath: status.podIP 24 restartPolicy: Never
提示：Downward API提供如下變量：
metadata.name：Pod的名稱，當Pod通過RC生成時，其名稱是RC隨機產生的唯一名稱；
status.podIP：Pod的IP地址，POd的IP屬於狀態數據，而非元數據；
metadata.namespace：Pod所在的namespace。
1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod.yaml 2 [root@k8smaster01 study]# kubectl logs dapi-test-pod | grep MY_POD 3 MY_POD_NAMESPACE=default 4 MY_POD_IP=172.30.240.4 5 MY_POD_NAME=dapi-test-pod 6
舉例2：通過Downward API將Container的自願請求和限制信息注入容器的環境變量。
1 [root@k8smaster01 study]# vi dapi-test-pod-container-vars.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: dapi-test-pod-container-vars 6 spec: 7 containers: 8 - name: test-container 9 image: busybox 10 imagePullPolicy: Never 11 command: [ "/bin/sh", "-c" ] 12 args: 13 - while true; do 14 echo -en '\n'; 15 printenv MY_CPU_REQUEST MY_CPU_LIMIT; 16 printenv MY_MEM_REQUEST MY_MEM_LIMIT; 17 sleep 3600; 18 done; 19 resources: 20 requests: 21 memory: "32Mi" 22 cpu: "125m" 23 limits: 24 memory: "64Mi" 25 cpu: "250m" 26 env: 27 - name: MY_CPU_REQUEST 28 valueFrom: 29 resourceFieldRef: 30 containerName: test-container 31 resource: requests.cpu 32 - name: MY_CPU_LIMIT 33 valueFrom: 34 resourceFieldRef: 35 containerName: test-container 36 resource: limits.cpu 37 - name: MY_MEM_REQUEST 38 valueFrom: 39 resourceFieldRef: 40 containerName: test-container 41 resource: requests.memory 42 - name: MY_MEM_LIMIT 43 valueFrom: 44 resourceFieldRef: 45 containerName: test-container 46 resource: limits.memory 47 restartPolicy: Never
提示：Downward API提供如下變量：
requests.cpu：容器的CPU請求值；
limits.cpu：容器的CPU限制值；
requests.memory：容器的內存請求值；
limits.memory：容器的內存限制值。
1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-container-vars.yaml 2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-container-vars 3 1 4 1 5 33554432 6 67108864
舉例3：通過Downward API將Pod的Label、Annotation列表通過Volume掛載為容器內的一個文件。
1 [root@k8smaster01 study]# vi dapi-test-pod-volume.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: dapi-test-pod-volume 6 labels: 7 zone: us-est-coast 8 cluster: test-cluster1 9 rack: rack-22 10 annotations: 11 build: two 12 builder: john-doe 13 spec: 14 containers: 15 - name: test-container 16 image: busybox 17 imagePullPolicy: Never 18 command: [ "/bin/sh", "-c" ] 19 args: 20 - while true; do 21 if [[ -e /etc/labels ]]; then 22 echo -en '\n\n'; cat /etc/labels; fi; 23 if [[ -e /etc/annotations ]]; then 24 echo -en '\n\n'; cat /etc/annotations; fi; 25 sleep 3600; 26 done; 27 volumeMounts: 28 - name: podinfo 29 mountPath: /etc 30 readOnly: false 31 volumes: 32 - name: podinfo 33 downwardAPI: 34 items: 35 - path: "labels" 36 fieldRef: 37 fieldPath: metadata.labels 38 - path: "annotations" 39 fieldRef: 40 fieldPath: metadata.annotations
注意：Volume中的ddownwardAPI的items語法，將會以path的名稱生成文件。如上所示，會在容器內生產/etc/labels和/etc/annotations兩個文件，分別包含metadata.labels和metadata.annotations的全部Label。
1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-volume.yaml 2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-volume 3
提示：DownwardAPI意義：
在某些集群中，集群中的每個節點需要將自身的標識（ID）及進程綁定的IP地址等信息事先寫入配置文件中，進程啟動時讀取此類信息，然後發布到某個類似註冊服務中心。此時可通過DowanwardAPI，將一個預啟動腳本或Init Container，通過環境變量或文件方式獲取Pod自身的信息，然後寫入主程序配置文件中，最後啟動主程序。本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
學習Netty也有一段時間了，Netty作為一個高性能的異步框架，很多RPC框架也運用到了Netty中的知識，在rpc框架中豐富的數據協議及編解碼可以讓使用者更加青睞；
Netty支持豐富的編解碼框架，其本身內部提供的編解碼也可以應對各種業務場景；
今天主要就是學習下Netty中提供的編、解碼類，之前只是簡單的使用了下Netty提供的解碼類，今天更加深入的研究下Netty中編、解碼的源碼及部分使用。
編碼（Encoder）
編碼就是將我們發送的數據編碼成字節數組方便在網絡中進行傳輸，類似Java中的序列化，將對象序列化成字節傳輸解碼（Decoder）
解碼和編碼相反，將傳輸過來的字節數組轉化為各種對象來進行展示等，類似Java中的反序列化
如：
// 將字節數組轉化為字符串
new String(byte bytes[], Charset charset)ByteToMessageDecoder: 解碼超類，將字節轉換成消息
解碼解碼一般用於將獲取到的消息解碼成系統可識別且自己需要的數據結構；因此ByteToMessageDecoder需要繼承ChannelInboundHandlerAdapter入站適配器來獲取到入站的數據，在handler使用之前通過channelRead獲取入站數據進行一波解碼；通過channelRead獲取入站數據，將數據緩存至cumulation數據緩衝區，最後在傳給decode進行解碼，在read完成之後清空緩存的數據
1. 獲取入站數據
/**
* 通過重寫channelRead方法來獲取入站數據
*/
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
// 檢測是否是byteBuf對象格式數據
if (msg instanceof ByteBuf) {
// 實例化字節解碼成功輸出集合 即List<Object> out
CodecOutputList out = CodecOutputList.newInstance();
try {
// 獲取到的請求的數據
ByteBuf data = (ByteBuf) msg;
// 如果緩衝數據區為空則代表是首次觸發read方法
first = cumulation == null;
if (first) {
// 如果是第一次read則當前msg數據為緩衝數據
cumulation = data;
} else {
// 如果不是則觸發累加，將緩衝區的舊數據和新獲取到的數據通過 expandCumulation 方法累加在一起存入緩衝區cumulation
// cumulator 累加類，將緩衝池中數據和新數據進行組合在一起
// private Cumulator cumulator = MERGE_CUMULATOR;
cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
}
// 將緩衝區數據cumulation進行解碼
callDecode(ctx, cumulation, out);
} catch (DecoderException e) {
throw e;
} catch (Throwable t) {
throw new DecoderException(t);
} finally {
// 在解碼完畢后釋放引用和清空全局字節緩衝區
if (cumulation != null && !cumulation.isReadable()) {
numReads = 0;
cumulation.release();
cumulation = null;
// discardAfterReads為netty中設置的讀取多少次后開始丟棄字節 默認值16
// 可通過setDiscardAfterReads(int n)來設置值不設置默認16次
} else if (++ numReads >= discardAfterReads) {
// We did enough reads already try to discard some bytes so we not risk to see a OOME.
// 在我們讀取了足夠的數據可以嘗試丟棄一些字節已保證不出現內存溢出的異常
//
// See https://github.com/netty/netty/issues/4275
// 讀取次數重置為0
numReads = 0;
// 重置讀寫指針或丟棄部分已讀取的字節
discardSomeReadBytes();
}
// out為解碼成功的傳遞給下一個handler
int size = out.size();
decodeWasNull = !out.insertSinceRecycled();
// 結束當前read傳遞到下個ChannelHandler
fireChannelRead(ctx, out, size);
// 回收響應集合 將insertSinceRecycled設置為false；
// insertSinceRecycled用於channelReadComplete判斷使用
out.recycle();
}
} else {
// 不是的話直接fire傳遞給下一個handler
ctx.fireChannelRead(msg);
}
}
public static final Cumulator MERGE_CUMULATOR = new Cumulator() {
/**
* alloc ChannelHandlerContext分配的字節緩衝區
* cumulation 當前ByteToMessageDecoder類全局的字節緩衝區
* in 入站的字節緩衝區
**/
@Override
public ByteBuf cumulate(ByteBufAllocator alloc, ByteBuf cumulation, ByteBuf in) {
final ByteBuf buffer;
// 如果全局ByteBuf寫入的字節+當前入站的字節數據大於全局緩衝區最大的容量或者全局緩衝區的引用數大於1個或全局緩衝區只讀
if (cumulation.writerIndex() > cumulation.maxCapacity() - in.readableBytes()
|| cumulation.refCnt() > 1 || cumulation.isReadOnly()) {
// Expand cumulation (by replace it) when either there is not more room in the buffer
// or if the refCnt is greater then 1 which may happen when the user use slice().retain() or
// duplicate().retain() or if its read-only.
//
// See:
// - https://github.com/netty/netty/issues/2327
// - https://github.com/netty/netty/issues/1764
// 進行擴展全局字節緩衝區（容量大小 = 新數據追加到舊數據末尾組成新的全局字節緩衝區）
buffer = expandCumulation(alloc, cumulation, in.readableBytes());
} else {
buffer = cumulation;
}
// 將新數據寫入緩衝區
buffer.writeBytes(in);
// 釋放當前的字節緩衝區的引用
in.release();
return buffer;
}
};
/**
* alloc 字節緩衝區操作類
* cumulation 全局累加字節緩衝區
* readable 讀取到的字節數長度
*/
// 字節緩衝區擴容方法
static ByteBuf expandCumulation(ByteBufAllocator alloc, ByteBuf cumulation, int readable) {
// 舊數據
ByteBuf oldCumulation = cumulation;
// 通過ByteBufAllocator將緩衝區擴大到oldCumulation + readable大小
cumulation = alloc.buffer(oldCumulation.readableBytes() + readable);
// 將舊數據重新寫入到新的字節緩衝區
cumulation.writeBytes(oldCumulation);
// 舊字節緩衝區引用-1
oldCumulation.release();
return cumulation;
}@Override
public boolean release() {
return release0(1);
}
@Override
public boolean release(int decrement) {
return release0(checkPositive(decrement, "decrement"));
}
/**
* decrement 減量
*/
private boolean release0(int decrement) {
for (;;) {
int refCnt = this.refCnt;
// 當前引用小於減量
if (refCnt < decrement) {
throw new IllegalReferenceCountException(refCnt, -decrement);
}
// 這裏就利用里線程併發中的知識CAS，線程安全的設置refCnt的值
if (refCntUpdater.compareAndSet(this, refCnt, refCnt - decrement)) {
// 如果減量和引用量相等
if (refCnt == decrement) {
// 全部釋放
deallocate();
return true;
}
return false;
}
}
}4. 將全局字節緩衝區進行解碼
/**
* ctx ChannelHandler的上下文，用於傳輸數據與下一個handler來交互
* in 入站數據
* out 解析之後的出站集合 （此出站不是返回給客戶端的而是傳遞給下個handler的）
*/
protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
try {
// 如果入站數據還有沒解析的
while (in.isReadable()) {
// 解析成功的出站集合長度
int outSize = out.size();
// 如果大於0則說明解析成功的數據還沒被消費完，直接fire掉給通道中的後續handler繼續 消費
if (outSize > 0) {
fireChannelRead(ctx, out, outSize);
out.clear();
// Check if this handler was removed before continuing with decoding.
// 在這個handler刪除之前檢查是否還在繼續解碼
// If it was removed, it is not safe to continue to operate on the buffer.
// 如果移除了，它繼續操作緩衝區是不安全的
//
// See:
// - https://github.com/netty/netty/issues/4635
if (ctx.isRemoved()) {
break;
}
outSize = 0;
}
// 入站數據字節長度
int oldInputLength = in.readableBytes();
// 開始解碼數據
decodeRemovalReentryProtection(ctx, in, out);
// Check if this handler was removed before continuing the loop.
//
// If it was removed, it is not safe to continue to operate on the buffer.
//
// See https://github.com/netty/netty/issues/1664
if (ctx.isRemoved()) {
break;
}
// 解析完畢跳出循環
if (outSize == out.size()) {
if (oldInputLength == in.readableBytes()) {
break;
} else {
continue;
}
}
if (oldInputLength == in.readableBytes()) {
throw new DecoderException(
StringUtil.simpleClassName(getClass()) +
".decode() did not read anything but decoded a message.");
}
if (isSingleDecode()) {
break;
}
}
} catch (DecoderException e) {
throw e;
} catch (Throwable cause) {
throw new DecoderException(cause);
}
}
final void decodeRemovalReentryProtection(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
// 設置解碼狀態為正在解碼 STATE_INIT = 0; STATE_CALLING_CHILD_DECODE = 1; STATE_HANDLER_REMOVED_PENDING = 2; 分別為初始化； 解碼； 解碼完畢移除
decodeState = STATE_CALLING_CHILD_DECODE;
try {
// 具體的解碼邏輯（netty提供的解碼器或自定義解碼器中重寫的decode方法）
decode(ctx, in, out);
} finally {
// 此時decodeState為正在解碼中 值為1，返回false
boolean removePending = decodeState == STATE_HANDLER_REMOVED_PENDING;
// 在設置為初始化等待解碼
decodeState = STATE_INIT;
// 解碼完成移除當前ChannelHandler標記為不處理
// 可以看看handlerRemoved源碼。如果緩衝區還有數據直接傳遞給下一個handler
if (removePending) {
handlerRemoved(ctx);
}
}
}@Override
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
// 讀取次數重置
numReads = 0;
// 重置讀寫index
discardSomeReadBytes();
// 在channelRead meth中定義賦值 decodeWasNull = !out.insertSinceRecycled();
// out指的是解碼集合List<Object> out; 咱們可以點進
if (decodeWasNull) {
decodeWasNull = false;
if (!ctx.channel().config().isAutoRead()) {
ctx.read();
}
}
// fire掉readComplete傳遞到下一個handler的readComplete
ctx.fireChannelReadComplete();
}
/**
* 然後我們可以搜索下insertSinceRecucled在什麼地方被賦值了
* Returns {@code true} if any elements where added or set. This will be reset once {@link #recycle()} was called.
*/
boolean insertSinceRecycled() {
return insertSinceRecycled;
}
// 搜索下insert的調用我們可以看到是CodecOutputList類即為channelRead中的out集合，眾所周知在 decode完之後，解碼數據就會被調用add方法，此時insertSinceRecycled被設置為true
private void insert(int index, Object element) {
array[index] = element;
insertSinceRecycled = true;
}
/**
* 清空回收數組內部的所有元素和存儲空間
* Recycle the array which will clear it and null out all entries in the internal storage.
*/
// 搜索recycle的調用我么可以知道在channelRead的finally邏輯中 調用了out.recycle();此時 insertSinceRecycled被設置為false
void recycle() {
for (int i = 0 ; i < size; i ++) {
array[i] = null;
}
clear();
insertSinceRecycled = false;
handle.recycle(this);
}
至此ByteToMessageDecoder解碼類應該差不多比較清晰了！！！
MessageToByteEncoder: 編碼超類，將消息轉成字節進行編碼發出
何謂編碼，就是將發送數據轉化為客戶端和服務端約束好的數據結構和格式進行傳輸，我們可以在編碼過程中將消息體body的長度和一些頭部信息有序的設置到ByteBuf字節緩衝區中；方便解碼方靈活的運用來判斷（是否完整的包等）和處理業務；解碼是繼承入站數據，反之編碼應該繼承出站的數據；接下來我們看看編碼類是怎麼進行編碼的；既然是繼承出站類，我們直接看看write方法是怎麼樣的
/**
* 通過write方法獲取到出站的數據即要發送出去的數據
* ctx channelHandler上下文
* msg 發送的數據 Object可以通過繼承類指定的泛型來指定
* promise channelPromise異步監聽，類似ChannelFuture，只不過promise可以設置監聽的結果，future只能通過獲取監聽的成功失敗結果；可以去了解下promise和future的區別
*/
@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
ByteBuf buf = null;
try {
// 檢測發送數據的類型 通過TypeParameterMatcher類型匹配器
if (acceptOutboundMessage(msg)) {
@SuppressWarnings("unchecked")
I cast = (I) msg;
// 分配字節緩衝區 preferDirect默認為true
buf = allocateBuffer(ctx, cast, preferDirect);
try {
// 進行編碼
encode(ctx, cast, buf);
} finally {
// 完成編碼后釋放對象的引用
ReferenceCountUtil.release(cast);
}
// 如果緩衝區有數據則通過ctx發送出去，promise可以監聽數據傳輸並設置是否完成
if (buf.isReadable()) {
ctx.write(buf, promise);
} else {
// 如果沒有數據則釋放字節緩衝區的引用併發送一個empty的空包
buf.release();
ctx.write(Unpooled.EMPTY_BUFFER, promise);
}
buf = null;
} else {
// 非TypeParameterMatcher類型匹配器匹配的類型直接發送出去
ctx.write(msg, promise);
}
} catch (EncoderException e) {
throw e;
} catch (Throwable e) {
throw new EncoderException(e);
} finally {
if (buf != null) {
buf.release();
}
}
}
// 初始化設置preferDirect為true
protected MessageToByteEncoder() {
this(true);
}
protected MessageToByteEncoder(boolean preferDirect) {
matcher = TypeParameterMatcher.find(this, MessageToByteEncoder.class, "I");
this.preferDirect = preferDirect;
}編碼： 重寫encode方法，根據實際業務來進行數據編碼
// 此處就是我們需要重寫的編碼方法了，我們和根據約束好的或者自己定義好想要的數據格式發送給對方
// 下面是我自己寫的demo的編碼方法；頭部設置好body的長度，服務端可以根據長度來判斷是否是完整的包，僅僅自學寫的簡單的demo非正常線上運營項目的邏輯
public class MyClientEncode extends MessageToByteEncoder<String> {
@Override
protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out) throws Exception {
if (null != msg) {
byte[] request = msg.getBytes(Charset.forName("UTF-8"));
out.writeInt(request.length);
out.writeBytes(request);
}
}
}編碼類相對要簡單很多，因為只需要將發送的數據序列化，按照一定的格式進行發送數據！！！
項目實戰
項目主要簡單的實現下自定義編解碼器的運用及LengthFieldBasedFrameDecoder的使用
│ hetangyuese-netty-06.iml
│ pom.xml
│
├─src
│ ├─main
│ │ ├─java
│ │ │ └─com
│ │ │ └─hetangyuese
│ │ │ └─netty
│ │ │ ├─client
│ │ │ │ MyClient06.java
│ │ │ │ MyClientChannelInitializer.java
│ │ │ │ MyClientDecoder.java
│ │ │ │ MyClientEncode.java
│ │ │ │ MyClientHandler.java
│ │ │ │ MyMessage.java
│ │ │ │
│ │ │ └─server
│ │ │ MyChannelInitializer.java
│ │ │ MyServer06.java
│ │ │ MyServerDecoder.java
│ │ │ MyServerDecoderLength.java
│ │ │ MyServerEncoder.java
│ │ │ MyServerHandler.java
│ │ │
│ │ └─resources
│ └─test
│ └─java
Serverhandler: 只是簡單的將解碼的內容輸出
public class MyServerHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("客戶端連接成功 time: " + new Date().toLocaleString());
}
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
System.out.println("客戶端斷開連接 time: " + new Date().toLocaleString());
}
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
String body = (String) msg;
System.out.println("content:" + body);
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
// 出現異常關閉通道
cause.printStackTrace();
ctx.close();
}
}解碼器
public class MyServerDecoder extends ByteToMessageDecoder {
// 此處我頭部只塞了長度字段佔4個字節，別問為啥我知道，這是要客戶端和服務端約束好的
private static int min_head_length = 4;
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
// 解碼的字節長度
int size = in.readableBytes();
if(size < min_head_length) {
System.out.println("解析的數據長度小於頭部長度字段的長度");
return ;
}
// 讀取的時候指針已經移位到長度字段的尾端
int length = in.readInt();
if (size < length) {
System.out.println("解析的數據長度與長度不符合");
return ;
}
// 上面已經讀取到了長度字段，後面的長度就是body
ByteBuf decoderArr = in.readBytes(length);
byte[] request = new byte[decoderArr.readableBytes()];
// 將數據寫入空數組
decoderArr.readBytes(request);
String body = new String(request, Charset.forName("UTF-8"));
out.add(body);
}
}將解碼器加入到channelHandler中：記得加到業務handler的前面否則無效
public class MyChannelInitializer extends ChannelInitializer<SocketChannel> {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline()
// .addLast(new MyServerDecoderLength(10240, 0, 4, 0, 0))
// .addLast(new LengthFieldBasedFrameDecoder(10240, 0, 4, 0, 0))
.addLast(new MyServerDecoder())
.addLast(new MyServerHandler())
;
}
}ClientHandler
public class MyClientHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("與服務端連接成功");
for (int i = 0; i<10; i++) {
ctx.writeAndFlush("hhhhh" + i);
}
}
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
System.out.println("與服務端斷開連接");
}
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
System.out.println("收到服務端消息:" +msg+ " time: " + new Date().toLocaleString());
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
cause.printStackTrace();
ctx.close();
}
}編碼器
public class MyClientEncode extends MessageToByteEncoder<String> {
@Override
protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out) throws Exception {
if (null != msg) {
byte[] request = msg.getBytes(Charset.forName("UTF-8"));
out.writeInt(request.length);
out.writeBytes(request);
}
}
}將編碼器加到ClientHandler的前面
public class MyClientChannelInitializer extends ChannelInitializer<SocketChannel> {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline()
.addLast(new MyClientDecoder())
.addLast(new MyClientEncode())
.addLast(new MyClientHandler())
;
}
}MyServer06 is start ...................
客戶端連接成功 time: 2019-11-19 16:35:47
content:hhhhh0
content:hhhhh1
content:hhhhh2
content:hhhhh3
content:hhhhh4
content:hhhhh5
content:hhhhh6
content:hhhhh7
content:hhhhh8
content:hhhhh9將自定義編碼器換成LengthFieldBasedFrameDecoder(10240, 0, 4, 0, 0)
public class MyChannelInitializer extends ChannelInitializer<SocketChannel> {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline()
// .addLast(new MyServerDecoderLength(10240, 0, 4, 0, 0))
.addLast(new LengthFieldBasedFrameDecoder(10240, 0, 4, 0, 0))
// .addLast(new MyServerDecoder())
.addLast(new MyServerHandler())
;
}
}
// 怕忘記的各個參數的含義在這在說明一次，自己不斷的修改每個值觀察結果就可以更加深刻的理解
/**
* maxFrameLength：消息體的最大長度，好像默認最大值為1024*1024
* lengthFieldOffset 長度字段所在字節數組的下標 （我這是第一個write的所以下標是0）
* lengthFieldLength 長度字段的字節長度（int類型佔4個字節）
* lengthAdjustment 長度字段補償的數值 （lengthAdjustment = 數據包長度 - lengthFieldOffset - lengthFieldLength - 長度域的值），解析需要減去對應的數值
* initialBytesToStrip 是否去掉長度字段（0不去除，對應長度域字節長度）
*/
public LengthFieldBasedFrameDecoder(
int maxFrameLength,
int lengthFieldOffset, int lengthFieldLength,
int lengthAdjustment, int initialBytesToStrip)MyServer06 is start ...................
客戶端連接成功 time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh0, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh1, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh2, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh3, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh4, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh5, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh6, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh7, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh8, time: 2019-11-19 17:53:42
收到客戶端發來的消息: hhhhh9, time: 2019-11-19 17:53:42如果我們在客戶端的長度域中做手腳 LengthFieldBasedFrameDecoder(10240, 0, 4, 0, 0)
舊： out.writeInt(request.length);
新： out.writeInt(request.length + 1);// 看結果就不正常，0後面多了一個0；但是不知道為啥只解碼了一次？？？ 求解答
MyServer06 is start ...................
客戶端連接成功 time: 2019-11-19 17:56:55
收到客戶端發來的消息: hhhhh0 , time: 2019-11-19 17:56:55
// 正確修改為 LengthFieldBasedFrameDecoder(10240, 0, 4, -1, 0)
// 結果：
MyServer06 is start ...................
客戶端連接成功 time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh0, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh1, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh2, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh3, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh4, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh5, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh6, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh7, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh8, time: 2019-11-19 18:02:18
收到客戶端發來的消息: hhhhh9, time: 2019-11-19 18:02:18捨棄長度域 ：LengthFieldBasedFrameDecoder(10240, 0, 4, 0, 4)
// 結果
MyServer06 is start ...................
客戶端連接成功 time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh0, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh1, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh2, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh3, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh4, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh5, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh6, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh7, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh8, time: 2019-11-19 18:03:44
收到客戶端發來的消息:hhhhh9, time: 2019-11-19 18:03:44 * <pre>
* lengthFieldOffset = 0
* lengthFieldLength = 2
* <b>lengthAdjustment</b> = <b>-2</b> (= the length of the Length field)
* initialBytesToStrip = 0
*
* BEFORE DECODE (14 bytes) AFTER DECODE (14 bytes)
* +--------+----------------+ +--------+----------------+
* | Length | Actual Content |----->| Length | Actual Content |
* | 0x000E | "HELLO, WORLD" | | 0x000E | "HELLO, WORLD" |
* +--------+----------------+ +--------+----------------+
* </pre>長度域中0x000E為16進制，轉換成10進制是14，說明消息體長度為14；根據公式：14-0-2-14 = -2* <pre>
* lengthFieldOffset = 0
* lengthFieldLength = 3
* <b>lengthAdjustment</b> = <b>2</b> (= the length of Header 1)
* initialBytesToStrip = 0
*
* BEFORE DECODE (17 bytes) AFTER DECODE (17 bytes)
* +----------+----------+----------------+ +----------+----------+----------------+
* | Length | Header 1 | Actual Content |----->| Length | Header 1 | Actual Content |
* | 0x00000C | 0xCAFE | "HELLO, WORLD" | | 0x00000C | 0xCAFE | "HELLO, WORLD" |
* +----------+----------+----------------+ +----------+----------+----------------+
* </pre>從上的例子可以知道；lengthAdjustment(2) = 17- 12（00000C）-lengthFieldOffset(0) - lengthFieldLength(3);…….等等
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
美國蒙大拿州密蘇拉（Missoula）聯邦地區法官克里斯坦森（Dana Christensen）與環保人士及美國原住民站在同一陣線，駁回美國魚類暨野生動物管理局（US Fish and Wildlife Service）將灰熊從瀕危物種名單除名的決定。
環保人士主張，根據瀕臨滅絕物種保護法，對這些灰熊與蒙大拿州和下48州（Lower 48）的其他灰熊族群採取差別待遇，是生物學上靠不住且非法行為，法官也同意這類說法。
環保人士說，儘管灰熊數量有所回升，倘若沒有受到聯邦持續保護，牠們的復育情況就會受到影響。此外，氣候變遷導致灰熊食物供給出現變化和人為死亡率高，也對灰熊生存構成威脅。
本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
 |
因應龐大需求，電動車龍頭廠商特斯拉（Tesla）表示將積極擴產，目標在2018年達成年產量50萬輛車。
特斯拉2015年的產量約為5萬輛，但Model 3甫一推出就獲得40萬輛的超大筆訂單。為滿足這些預購車主的需求，特斯拉表示將積極擴產五倍，將原先2020年年產量50萬輛的目標提前到2018年實現，從中可望取得可觀的美國政府補助。而2016年，特斯拉預計將交車8~9萬輛。
特斯拉執行長Elon Musk於5月4日發表公司經營狀況時表示已將自己的辦公桌「移至生產線尾端，整個團隊都全力以赴」，彰顯急速擴張的決心。但他也坦言這個目標極具挑戰，若能成功，全球電動車市場將產生結構性的變化。
特斯拉財報：首季虧損
特斯拉在4日所發表的財報顯示，該公司今年第一季營收較去年同期大幅增加22%，為11.5億美元。但由於公司正在高速擴張，使營業費用比去年同期增加四成，至5億美元；加上Model X交車進度略有落後，使首季出現虧損，淨損為2.83億美元，高於去年第一季的淨損1.54億美元。扣除非常態性項目後，相當於每股虧損0.57美元。
未見起色的財報直接衝擊特斯拉股情。4日當天，特斯拉股價一度下滑4.2%，為222.56美元。不過，當Musk再宣布目標於2018年擴產至50萬輛後，股價再度回彈，最高漲至每股239.72美元。
特斯拉能否如期實現年產能50萬輛的目標，仍待觀察。近期有兩位高階副總即將離職，且特斯拉營運燒錢速度快於盈利回收，也是一隱憂。但特斯拉表示目前仍不需要依靠融資。
本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
一.前言
通過前面的文章至的學習，我們已經有實現了傳統的ASP.NET Core MVC+EasyUI的增刪改查功能。本篇文章我們要實現了使用ABP提供的WebAPI方式+EasyUI來實現增刪改查的功能。本文中我們將不在使用DataGrid表格控件，而是使用樹形表格（TreeGrid）控件。
我先上圖，讓我們來看一下功能完成之後的組織管理信息列表頁面。如下圖。
這個組織管理列表頁面使用TreeGrid來實現的。我們接下來介紹一下TreeGrid。
首先、在定義TreeGrid時有兩個屬性必須要有一個是idField，這個要唯一；另一個是treeField的定義，這是樹節點的值，必須要有。
其次、easyui加載treegrid的json數據格式有三種，我就介紹我常用的這種。其他兩種方式，請查看easyui的相關文檔。
{"total":7,"rows":[
{"id":1,"name":"All Tasks","begin":"3/4/2010","end":"3/20/2010","progress":60,"iconCls":"icon-ok"},
{"id":2,"name":"Designing","begin":"3/4/2010","end":"3/10/2010","progress":100,"_parentId":1,"state":"closed"},
{"id":21,"name":"Database","persons":2,"begin":"3/4/2010","end":"3/6/2010","progress":100,"_parentId":2},
{"id":22,"name":"UML","persons":1,"begin":"3/7/2010","end":"3/8/2010","progress":100,"_parentId":2},
{"id":23,"name":"Export Document","persons":1,"begin":"3/9/2010","end":"3/10/2010","progress":100,"_parentId":2},
{"id":3,"name":"Coding","persons":2,"begin":"3/11/2010","end":"3/18/2010","progress":80},
{"id":4,"name":"Testing","persons":1,"begin":"3/19/2010","end":"3/20/2010","progress":20}
],"footer":[
{"name":"Total Persons:","persons":7,"iconCls":"icon-sum"}
]}
下面介紹一下上面數據中的幾個重要屬性：
1） _parentId ：字段_parentId必不可少，且名稱唯一。記得前面有“_” ，他是用來記錄父級節點，沒有這個屬性，是沒法展示父級節點 其次就是這個父級節點必須存在，不然信息也是展示不出來，在後台遍歷組合的時候，如果父級節點不存在或為0時，此時 _parentId 應該不賦值，或設為“”。如果賦值 “0” 則在表格中不显示數據。
2） state：是否展開
3） checked：是否選中（用於複選框）
4） iconCls：選項前面的圖標，如果自己不設定，父級節點默認為文件夾圖標，子級節點為文件圖標
下面我們來開始實現組織管理頁面的相關功能。首先我們要創建一個組織信息實體。
三、創建Org實體
1. 在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊“ABP.TPLMS.Core”項目的“Entitys”文件夾，在彈出菜單中選擇“添加” >
> “類”。 將類命名為 Org，然後選擇“添加”。
2.創建Org類繼承自Entity<int>，通過實現審計模塊中的IHasCreationTime來實現保存創建時間。根據TreeGrid所需要的數據格式的要求。代碼如下：
using Abp.Domain.Entities; using Abp.Domain.Entities.Auditing; using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.Text; namespace ABP.TPLMS.Entitys { public partial class Org : Entity<int>, IHasCreationTime { int m_parentId = 0; public Org() { this.Id = 0; this.Name = string.Empty; this.HotKey = string.Empty; this.ParentId = 0; this.ParentName = string.Empty; this.IconName = string.Empty; this.Status = 0; this.Type = 0; this.BizCode = string.Empty; this.CustomCode = string.Empty; this.CreationTime = DateTime.Now; this.UpdateTime = DateTime.Now; this.CreateId = 0; this.SortNo = 0; } [Required] [StringLength(255)] public string Name { get; set; } [StringLength(255)] public string HotKey { get; set; } public int ParentId { get { return m_parentId; } set { m_parentId = value; } } [Required] [StringLength(255)] public string ParentName { get; set; } public bool IsLeaf { get; set; } public bool IsAutoExpand { get; set; } [StringLength(255)] public string IconName { get; set; } public int Status { get; set; } public int Type { get; set; } [StringLength(255)] public string BizCode { get; set; } [StringLength(100)] public string CustomCode { get; set; } public DateTime CreationTime { get; set; } public DateTime UpdateTime { get; set; } public int CreateId { get; set; } public int SortNo { get; set; } public int? _parentId { get { if (m_parentId == 0) { return null; } return m_parentId; } } } }
3.定義好實體之後，我們去“ABP.TPLMS.EntityFrameworkCore”項目中的“TPLMSDbContext”類中定義實體對應的DbSet，以應用Code First 數據遷移。添加以下代碼
using Microsoft.EntityFrameworkCore; using Abp.Zero.EntityFrameworkCore; using ABP.TPLMS.Authorization.Roles; using ABP.TPLMS.Authorization.Users; using ABP.TPLMS.MultiTenancy; using ABP.TPLMS.Entitys; namespace ABP.TPLMS.EntityFrameworkCore { public class TPLMSDbContext : AbpZeroDbContext<Tenant, Role, User, TPLMSDbContext> { /* Define a DbSet for each entity of the application */ public TPLMSDbContext(DbContextOptions<TPLMSDbContext> options) : base(options) { } public DbSet<Module> Modules { get; set; } public DbSet<Supplier> Suppliers { get; set; } public DbSet<Cargo> Cargos { get; set; } public DbSet<Org> Orgs { get; set; } } }
4.從菜單中選擇“工具->NuGet包管理器器—>程序包管理器控制台”菜單。
5. 在PMC中，默認項目選擇EntityframeworkCore對應的項目后。輸入以下命令：Add-Migration AddEntityOrg，創建遷移。如下圖。
6. 在上面的命令執行完畢之後，創建成功后，會在Migrations文件夾下創建時間_AddEntityOrg格式的類文件，這些代碼是基於DbContext指定的模型。如下圖。
7.在程序包管理器控制台，輸入Update-Database，回車執行遷移。執行成功后，如下圖。
8. 在SQL Server Management Studio中查看數據庫，Orgs表創建成功。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
根據《中華人民共和國行政許可法》和《國務院對確需保留的行政審批專案設定行政許可的決定》的規定，工信部日前將許可的汽車、摩托車、三輪汽車和低速貨車生產企業及產 品（第285批）予以了公告，共有218款新能源車型入選。進入該公告的新能源汽車可開展生產銷售，但是要獲得補貼，還需再獲得《新能源汽車推廣應用推薦車型目錄》准入。
純電動轎車/乘用車方面，北汽、長城、禦捷馬、卡威、吉利等12款車型入選。
插電式乘用車方面，比亞迪、寶馬、之諾、上汽等7款車型入選。
純電動客車方面，安凱、江淮、安源、北奔、北方、福田、比亞迪、白雲、五菱、陸地方舟、尼歐凱、友誼、青年、海格、開沃、依維柯、飛燕、大通、象牌、野馬、華新、金龍、金旅、宇通、黃河、中通、中植汽車、穗通等28個品牌75款車型入選。
插電式混動客車方面， 安凱、海格、易聖達、金龍、金旅、宇通6個品牌21款車型入選。
新能源專用車方面，福田、北京、大運、黃海、東風、華神、揚子江、東風、福建、環球、藍速、田野、中悅 、卡威、陸地方舟、青年曼、康迪、五菱、暢達、躍進、金龍、凱馬、時風、太行成功、東風、金杯、邢牛、海德、解放、神州、宇通、長帆汽車、迪馬、炫虎等33個品牌103款車型入選。
本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
5月28日，財政部發佈聲明稱，關於新能源汽車推廣騙補核查，現場核查已經完成，目前處於會審階段。核查及處理情況，將按資訊公開有關規定及時公開。
中國新能源汽車產業的發展受到政策的強力推動。從2010年開始，我國便實施新能源汽車補貼政策，由於監督機制不完善，騙補隨之愈演愈烈。2016年1月份，工信部、財政部、科技部、發改委聯合啟動對新能源汽車相關情況的專項核查工作，新能源汽車生產企業、運營企業、租賃企業、企事業單位等新能源汽車使用者全部列入核查物件。國務院也把遏制新能源汽車騙補行為作為重點工作之一。
此前，央視曝光了10家涉及騙補的企業，分別是蘇州吉姆西客車製造有限公司、陝西通家汽車股份有限公司、重慶力帆乘用車有限公司、江蘇陸地方舟新能源電動汽車有限公司、奇瑞萬達貴州客車股份有限公司、國宏汽車有限公司、江蘇奧新新能源汽車有限公司、蕪湖寶騏汽車製造有限公司、重慶力帆汽車有限公司，以及金華青年汽車製造有限公司。這些企業的共同特點是，2015年12月單月產量（主要依據是機動車出廠合格證）均超過全年產量的50%。
對於騙補行為，工信部部長苗圩曾公開表示，“局部地區確實存在少部分企業騙補的現象，對於騙補企業，沒補貼的錢不會下發，已補貼的錢一定要扣回。依法進行處置，直至取消這些企業的資質”。
對於騙補的企業到底有哪些？將受到怎樣的處罰？這些問題一直受到業界的關注和猜測。此次，財政部公開發佈新能源汽車推廣核查有關情況的聲明，表示“現場核查已經完成，目前處於會審階段”。聲明特別強調“財政部和部內有關司局至今未接受過媒體採訪，核查及處理情況，將按資訊公開有關規定及時公開”。
本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!
目錄
就在前幾天，有位讀者朋友私信宜春，說期待出一篇多線程的文章，我當時內心是小鹿亂撞啊….於是這幾天茶不思飯不想，好幾天深夜皆是輾轉反側，兩目深凝，以至於這幾天走起路來格外飄飄然，左搖右晃的，魔鬼般的步伐，一般兩步，走在大馬路中央上差點被打~我承認太誇張了，感覺又要被打~。最終還是君意不可違，答應了這位讀者朋友，從這位讀者朋友的博客頭像可以看的出來，這位朋友絕bi歷經滄桑，對生活無盡的坦然浩對，看透俗世凡塵、世態炎涼、趨炎附勢，擁有着極高的安心恬盪情懷…啥？啥子？這個是系統默認頭像….嗯嗯嗯呃。。。那個那個宜春啥都沒說哈，別把什麼事都扯宜春身上，你們一天天的，我啥都沒說（理直氣壯）…
@
由於併發肯定涉及到多線程，因此在進入併發編程主題之前，我們先來了解一下進程和線程的由來，這對後面對併發編程的理解將會有很大的幫助。
進程和線程的對比這一知識點由於過於基礎，正因為過於基礎，所以我們更應該透徹它！我們必須掌握什麼是線程和進程，掌握線程與進程的關係、區別及優缺點 ！
首先我們來看一下進程的概念：
進程：是指一個內存中運行的應用程序，每個進程都有一個獨立的內存空間，一個應用程序可以同時運行多個進程；進程也是程序的一次執行過程，是系統運行程序的基本單位；系統運行一個程序即是一個進程從創建、運行到消亡的過程。
看完之後，是不是感覺很抽象？很懵bi？懵bi就對了，說明你和我智商一樣高….~開個玩笑~
不妨先憋棄上面的概念，放鬆一下大腦，雙擊打開LOL，秒選德馬打野，輸了直接退出遊戲並且保持微笑，然後正襟危坐心平氣和的看宜春寫的博客….
這個時候的你不僅僅是愉快的擼了一把遊戲，而且還親自體驗擼了一把進程…其實在你雙擊打開LOL的時候就已經創建了進程，此話怎講？眾所周知，我們的電腦安裝的軟件比如：LOL、微信、谷歌等等都是存儲在我們的硬盤上的，硬盤上的數據可以說是永久存儲（ORM）,當我們雙擊LOL的時候，LOL程序執行就進入了內存中，所有的程序必須進入內存中才能執行，內存屬於臨時存儲（RAM），而進入內存的程序都可以叫做是進程，把LOL程序退出的時候，LOL程序就會退出內存，進程也就隨之銷毀了！因此說各位擼了一把進程也不為過吧。
啥？字太多了，看的不夠明了，不如看圖得勁….額。。。
上面主要是通過抽象的描述了進程，其實進程是可以很直觀的看的到的，我們可以再電腦底部任務欄，右鍵—–>打開任務管理器,可以查看當前任務的進程：
其實，關於線程博主我完全可以一兩句話概括，但是這樣並不負責，畢竟這篇文章標題就是要讓你徹底入門java多線程。如果連進程都理解不好談何徹底理解多線程？
同樣的，我們先來看線程的概念
線程是進程中的一個執行單位，負責當前進程中程序的執行。一個進程中至少有一個線程，也就是說一個進程可以有多個線程的，而多個線程的進程運用程序就叫做多線程程序
線程的概念稍微好理解很多，但是想更深層次的去理解光靠上面一段文字的概述是完全不夠的！
這不打LOL的過程中，屬實卡的一批，果然花高價998買的6手戴爾筆記本打LOL屬實像極了愛情。這個時候不得不雙擊打開電腦安全管家進行殺毒，果然2500天沒有進行過病毒查殺，我天。。。其實我相信很多人都用過電腦管家或者手機管家之類的安全軟件，我們都很清楚我們開啟病毒查殺之後一般要幾分鐘掃描查殺，這個時候我們是可以讓它後台進行的，我們不會等而是開啟另一個垃圾清理的功能，這個時候我們也不會等而是再去啟動電腦加速功能。等到 這些操作都完成之後果斷退出電腦管家，繼續LOL，果然高價998買的6手戴爾筆記本再怎麼殺毒打LOL還是照樣的卡….
其實清楚線程必然涉及到CPU的相關概念了，將上面文字所描述的用圖片概括，大致為：
從上一節中，我們也提到過多線程，所以理解起來應該不難。
多線程就是多個線程同時運行 或 交替運行。
單核CPU：交替運行。
多核CPU：同時運行。
其實，多線程程序並不能提高程序的運行速度，但能夠提高程序運行效率，讓CPU的使用率更高。
說起線程調度優先級這個概念，就讓我想到現在我們大部分人投簡歷一樣。如果你的學歷或者工作經驗越高，那麼你的優先級就越高，面試官很大幾率就會讓你去面試但也不是一定只是幾率特別大，如果線程的優先級相同，那麼會隨機選擇一個(線程隨機性)！在我們每個人的電腦中線程是可以設置線程的優先級的，但是生活中沒有優先級（學歷、工作經驗）的孩子就只能靠自己的能力了~媽耶，太真實了…~
線程優先級具有繼承特性比如A線程啟動B線程，則B線程的優先級和A是一樣的。
線程優先級具有隨機性也就是說線程優先級高的不一定每一次都先執行完，只是被執行的可能性更大。
在今後的多線程學習旅遊中我們會使用到getPriority()方法獲取線程的優先級。
線程與進程相似，但線程是一個比進程更小的執行單位，是程序執行的最小單位。一個進程在其執行的過程中可以產生多個線程。與進程不同的是同類的多個線程共享同一塊內存空間和一組系統資源，所以系統在產生一個線程，或是在各個線程之間作切換工作時，負擔要比進程小得多，也正因為如此，線程也被稱為輕量級進程。同時線程是程序執行的最小單位。使用多線程而不是用多進程去進行併發程序的設計，是因為線程間的切換和調度的成本遠遠小於進程。
而使用多線程，多線程會將程序運行方式從串行運行變為併發運行，效率會有很大提高。
在博主認為併發和并行是兩個非常容易被混淆的概念。為了防止繞暈大家，所以我選擇長話短說！
時間段內同時發生（並不是同時發生）。時刻發生（真正的同時發生）。它們都可以表示兩個或者多個任務一起執行，但是偏重點有些不同。
於此同時，我們不妨回顧一下上面所提到過的CPU，並再次理解併發與并行的區別，從而溫故知新 ~我TM簡直是個天才！~
單核CPU：交替運行【併發】
多核CPU：同時運行【并行】
併發給人的感覺是同時運行，那是因為分時交替運行的時間是非常短的！
我們常說的主線程就是Main線程，它是一個特殊的單線程，話不多說，直接擼碼：
定義一個用於測試的demo類Person
package demo;
public class Person {
public String name;
public Person(String name){
this.name=name;
}
public void run(){
int i=1;
while (i<5){
System.out.println(name+i);
i++;
}
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}編寫Main方法
package demo;
public class MainThreadDemo {
public static void main(String[] args) {
Person per=new Person("常威");
per.run();
Person Per2=new Person("來福");
Per2.run();
}
}運行結果就已經很顯而易見了，放心我不是靠你們運行結果而是單純的先分析主線程。
運行結果：
常威1
常威2
常威3
常威4
來福1
來福2
來福3
來福4單線程不僅效率低下，而且存在很大的局限性，惟一的優點就是安全。所以說女孩子長得安全其實也是一種優點，噗哈哈哈…
如何體現出單線程效率低下以及它的局限性呢？其實只要一句代碼即可，還是以上面的單線程Main線程為例：
package demo;
public class MainThreadDemo {
public static void main(String[] args) {
Person per=new Person("常威");
per.run();
int a=6/0; //=====================特別注意這行代碼
Person Per2=new Person("來福");
Per2.run();
}
}試想一下運行結果…
如果對上面的運行結果有問題，或者疑問。那沒錯了，你簡直是個天（小）才（白）！真真的天（小）才（白），很有可能異常機制沒學好，好吧我給你貼出來：
言歸正傳，效率低下何以見得？這是數據少，如果是一億條數據呢，單線程就是一個一個打印。那局限性又何以見得呢？從上面運行結果來看也能看出，只因為一行代碼而導致下面代碼不再執行。已經很明顯了。
說是說創建多線程有四種方式，但考慮到是入門文章還是主要寫入門的兩種方式，剩下的兩個暫時忽略。忽略的兩種方法有：實現Callable接口通過FutureTask包裝器來創建Thread線程、使用ExecutorService、Callable、Future實現有返回結果的線程。現在可能對於入門的童鞋來說是接收不了的，以後再去了解也不晚！
Java使用java.lang.Thread類代表線程，所有的線程對象都必須是Thread類或其子類的實例。每個線程的作用是完成一定的任務，實際上就是執行一段程序流即一段順序執行的代碼。Java使用線程執行體來代表這段程序流。
Java中通過繼承Thread類來創建並啟動多線程的步驟如下：
Thread類的子類，並重寫該類的run()方法，該run()方法的方法體就代表了線程需要完成的任務,因此把run()方法稱為線程執行體。Thread子類的實例，即創建了線程對象start()方法來啟動該線程代碼如下：
測試類：
public class Demo01 {
public static void main(String[] args) {
//創建自定義線程對象
MyThread mt = new MyThread("新的線程！");
//開啟新線程
mt.start();
//在主方法中執行for循環
for (int i = 0; i < 10; i++) {
System.out.println("main線程！"+i);
}
}
}自定義線程類：
public class MyThread extends Thread {
//定義指定線程名稱的構造方法
public MyThread(String name) {
//調用父類的String參數的構造方法，指定線程的名稱
super(name);
}
/**
* 重寫run方法，完成該線程執行的邏輯
*/
@Override
public void run() {
for (int i = 0; i < 10; i++) {
System.out.println(getName()+"：正在執行！"+i);
}
}
}Thread類本質上是實現了Runnable接口的一個實例，代表一個線程的實例。啟動線程的唯一方法就是通過Thread類的start()實例方法。start()方法是一個native方法，它將啟動一個新線程，並執行run()方法。這種方式實現多線程很簡單，通過自己的類直接extend Thread，並複寫run()方法，就可以啟動新線程並執行自己定義的run()方法。
如果自己的類已經繼承另一個類，就無法直接繼承Thread，此時，可以實現一個Runnable接口來創建線程，顯然實現Runnable接口方式創建線程的優勢就很明顯了。
直接擼碼：
自定義一個類實現Runnable接口，並重寫接口中的run()方法，併為run方法添加要執行的代碼方法。
public class RunableDemo implements Runnable{
@Override
public void run() {
int a = 1;
while (a<20){
System.out.println(Thread.currentThread().getName()+ a);//Thread.currentThread().getName()為獲取當前線程的名字
a++;
}
}
}編寫Main方法
為了啟動自定義類RunableDemo ，需要首先實例化一個Thread，並傳入RunableDemo 實例：
public class MainThreadDemo {
public static void main(String[] args) {
RunableDemo runn=new RunableDemo();
//實例化一個Thread並傳入自己的RunableDemo 實例
Thread thread=new Thread(runn);
thread.start();
int a = 1;
while (a<20){
//Thread.currentThread().getName()為獲取當前線程的名字
System.out.println(Thread.currentThread().getName()+ a);
a++;
}
}
}運行結果：
main1
main2
main3
Thread-01
Thread-02
Thread-03
Thread-04
Thread-05
Thread-06
....其實多運行幾遍，你會方法每次運行的結果順序都不一樣，這主要是由於多線程會去搶佔CPU的資源，誰搶到了誰就執行，而Main和Thread兩個線程一直在爭搶。
實際上，當傳入一個Runnable target（目標）參數給Thread后，Thread的run()方法就會調用target.run()，參考JDK源代碼：
public void run() {
if (target != null) {
target.run();
}
} 採用繼承Thread類方式：
（1）優點：編寫簡單，如果需要訪問當前線程，無需使用Thread.currentThread()方法，直接使用this，即可獲得當前線程。
（2）缺點：因為線程類已經繼承了Thread類，所以不能再繼承其他的父類。
採用實現Runnable接口方式：
（1）優點：線程類只是實現了Runable接口，還可以繼承其他的類。在這種方式下，可以多個線程共享同一個目標對象，所以非常適合多個相
同線程來處理同一份資源的情況，從而可以將CPU代碼和數據分開，形成清晰的模型，較好地體現了面向對象的思想。
（2）缺點：編程稍微複雜，如果需要訪問當前線程，必須使用Thread.currentThread()方法。
小結：
如果一個類繼承Thread，則不適合資源共享。但是如果實現了Runable接口的話，則很容易的實現資源共享。
實現Runnable接口比繼承Thread類的優勢:
1.適合多個相同代碼的線程去處理同一個資源。
2.可以避免java中單繼承的限制。
3.增加代碼的健壯性，實現解耦。代碼可以被多個線程共享，代碼和數據獨立。
4.線程池中只能放入實現Runnable或Callable類線程，不能放入繼承Thread的類【線程池概念之後會慢慢涉及】
所以，如果選擇哪種方式，盡量選擇實現Runnable接口！
其實學到後面的線程池，你會發現上面兩種創建線程的方法實際上很少使用，一般都是用線程池的方式比較多一點。使用線程池的方式也是最推薦的一種方式，另外，《阿里巴巴Java開發手冊》在第一章第六節併發處理這一部分也強調到“線程資源必須通過線程池提供，不允許在應用中自行显示創建線程”。不過處於入門階段的童鞋博主還是強烈建議一步一個腳印比較好！
談起匿名內部類，可能很多小白是比較陌生的，畢竟開發中使用的還是比較少，但是同樣是非常重要的一個知識！於此同時我就貼出關於匿名內部類的文章如果小白童鞋能看懂下面這個代碼，真的你不需要看那篇文章了，你T喵的簡直是個天才！
package AnonymousInner;
public class NiMingInnerClassThread {
public static void main(String[] args) {
Runnable r = new Runnable() {
@Override
public void run() {
for (int i = 0; i<5;i++){
System.out.println("熊孩子："+i);
}
}
};
new Thread(r).start();
for (int i = 0; i < 5 ; i++){
System.out.println("傻狍子:"+i);
}
}
}小白童鞋還愣着幹啥呀趕緊去補補…
線程安全問題主要是共享資源競爭的問題，也就是在多個線程情況下，一個或多個線程同時搶佔同一資源導致出現的一些不必要的問題，最典型的例子就是火車四個窗口售票問題了，這裏就不再舉售票例子了，已經爛大街了，這裏就簡單實現一個線程安全問題代碼….
實現Runnable接口方式為例，主要實現過程是：實例化三個Thread，並傳入同一個RunableDemo 實例作為參數，最後開啟三條相同參數的線程，代碼如下：
public class RunableDemo implements Runnable{
public int a = 100;//線程共享數據
@Override
public void run() {
while (a>0){
System.out.println("線程"+Thread.currentThread().getName()+"執行到"+ a);
a--;
}
}
}public class MainThreadDemo {
public static void main(String[] args) {
RunableDemo runn=new RunableDemo();
Thread thread1=new Thread(runn);
Thread thread2=new Thread(runn);
Thread thread3=new Thread(runn);
thread1.start();
thread2.start();
thread3.start();
}
}運行結果：
Thread-0==100
Thread-0==99
Thread-1==100
Thread-1==97
Thread-1==96
Thread-1==95
Thread-2==98
...根據結果可以看出，確實是三條線程（Thread-0、1、2）在執行，安全問題就出在線程會出現相同的結果比如上面的100就出現了兩次，如果循環條件更改一下可能也會出現負數的情況。這種情況該怎麼解決呢？這個時候就需要線程同步了！
實際上，線程安全問題的解決方法有三種：
1、同步代碼塊
2、同步方法
3、鎖機制
第一種方法：同步代碼塊
格式：
synchronized(鎖對象) {
可能會出現線程安全問題的代碼（訪問共享數據的代碼）
}使用同步代碼塊特別注意：
1、通過代碼塊的鎖對象，可以是任意對象
2、必須保證多個線程使用的鎖對象必須是同一個
3、鎖對象的作用是把同步代碼快鎖住，只允許一個線程在同步代碼塊執行
還是以上麵線程安全問題為例子，使用同步代碼塊舉例：
public class RunableDemo implements Runnable{
public int a = 100;//線程共享數據
Object object=new Object(); //事先準備好一個鎖對象
@Override
public void run() {
synchronized (object){ //使用同步代碼塊
while (a>0){
System.out.println("線程"+Thread.currentThread().getName()+"執行到"+ a);
a--;
}
}
}
}Main方法沒有任何改動，運行一下結果是絕對沒問題的，數據都是正確的沒有出現重複情況這一出，各位可以自己嘗試一下！
同步代碼塊的原理：
使用了一個鎖對象，叫同步鎖，對象鎖，也叫同步監視器，當開啟多個線程的時候，多個線程就開始搶奪CPU的執行權，比如現在t0線程首先的到執行，就會開始執行run方法，遇到同步代碼快，首先檢查是否有鎖對象，發現有，則獲取該鎖對象，執行同步代碼塊中的代碼。之後當CUP切換線程時，比如t1得到執行，也開始執行run方法，但是遇到同步代碼塊檢查是否有鎖對象時發現沒有鎖對象，t1便被阻塞，等待t0執行完畢同步代碼塊，釋放鎖對象，t1才可以獲取從而進入同步代碼塊執行。
同步中的線程，沒有執行完畢是不會釋放鎖的，這樣便實現了線程對臨界區的互斥訪問，保證了共享數據安全。
缺點：頻繁的獲取釋放鎖對象，降低程序效率
使用步驟：
1、把訪問了共享數據的代碼抽取出來，放到一個方法中
2、在該方法上添加synchronized修飾符
格式：
修飾符 synchronized 返回值類型 方法名稱（參數列表） {
方法體...
}代碼示例：
public class RunableDemo implements Runnable{
public int a = 100;//線程共享數據
@Override
public void run() {
while (true){
sell(); //調用下面的sell方法
}
}
//訪問了共享數據的代碼抽取出來，放到一個方法sell中
public synchronized void sell(){
while (a>0){
System.out.println("線程"+Thread.currentThread().getName()+"執行到"+ a);
a--;
}
}
}同步方法的也是一樣鎖住同步的代碼，但是鎖對象的是Runable實現類對象，也就是this，誰調用方法，就是誰。
說到同步方法，就不得不說一下靜態同步方法，顧名思義，就是在同步方法上加上static，靜態的同步方法，添加一個靜態static修飾符，此時鎖對象就不是this了，靜態同步方法的鎖對象是本類的class屬性，class文件對象（反射）
public class RunableDemo implements Runnable{
public static int a = 100;//線程共享數據 =====此時共享數據也要加上static
@Override
public void run() {
while (true){
sell();
}
}
public static synchronized void sell(){ //注意添加了static關鍵字
while (a>0){
System.out.println("線程"+Thread.currentThread().getName()+"執行到"+ a);
a--;
}
}
}使用靜態同步方法時，此時共享數據也要加上static，因為static成員才能訪問static成員，如果對static關鍵字不是他別理解的可以補補了，放心，博主有信心讓你有所收穫，會讓你重新認識到static的魅力：
當然靜態同步方法了解即可！
Lock接口位於java.util.concurrent.locks.Lock它是JDK1.5之後出現的，Lock接口中的方法：
void lock(): 獲取鎖
void unlock(): 釋放鎖
Lock接口的一個實現類java.util.concurrent.locks.ReentrantLock implements Lock接口
使用方法：
1、在Runable實現類的成員變量創建一個ReentrantLock對象
2、在可能產生線程安全問題的代碼前該對象調用lock方法獲取鎖
3、在可能產生線程安全問題的代碼后該對象調用unlock方法釋放鎖
代碼示例：
import java.util.concurrent.locks.ReentrantLock;
public class RunableDemo implements Runnable{
public static int a = 100;//線程共享數據
//1、在Runable實現類的成員變量創建一個ReentrantLock對象============
ReentrantLock reentrantLock = new ReentrantLock();
@Override
public void run() {
// 2、在可能產生線程安全問題的代碼前該對象調用lock方法獲取鎖=======
reentrantLock.lock();
while (a>0){
System.out.println("線程"+Thread.currentThread().getName()+"執行到"+ a);
a--;
}
// 3、在可能產生線程安全問題的代碼后該對象調用unlock方法獲取鎖======
reentrantLock.unlock();
}
}當然更安全的寫法是，在線程安全問題代碼中try...catchy，最後在finally語句中添加reentrantLock.unlock();，這樣方為上上策！
第一種
synchronized 同步代碼塊：可以是任意的對象必須保證多個線程使用的鎖對象是同一個
第二種
synchronized 同步方法： 鎖對象是this，誰調用鎖對象就是誰
synchronized 靜態同步方法： 鎖對象是其class對象，該對象可以用
this.getClass()方法獲取，也可以使用當前類名.class表示。【了解即可】
第三種
Look鎖方法：該方法提供的方法遠遠多於synchronized方式，主要在Runable實現類的成員變量創建一個ReentrantLock對象，並使用該對象調用lock方法獲取鎖以及unlock方法釋放鎖！
Thread()：用於構造一個新的Thread。
Thread(Runnable target)：用於構造一個新的Thread，該線程使用了指定target的run方法。
Thread(ThreadGroup group,Runnable target)：用於在指定的線程組中構造一個新的Thread，該
線程使用了指定target的run方法。
currentThread()：獲得當前運行線程的對象引用。
interrupt()：將當前線程置為中斷狀態。
sleep(long millis)：使當前運行的線程進入睡眠狀態，睡眠時間至少為指定毫秒數。
join()：等待這個線程結束，即在一個線程中調用other.join()，將等待other線程結束后才繼續本線程。
yield()：當前執行的線程讓出CPU的使用權，從運行狀態進入就緒狀態，讓其他就緒線程執行。
wait()：讓當前線程進入等待阻塞狀態，直到其他線程調用了此對象的notify()或notifyAll()方法后，當前線程才被喚醒進入就緒狀態。
notify()：喚醒在此對象監控器（鎖對象）上等待的單個線程。
notifyAll()：喚醒在此對象監控器（鎖對象）上等待的所有線程。
注意：
wait()、notify()、notifyAll()都依賴於同步鎖，而同步鎖是對象持有的，且每個對象只有一個，所以這些方法定義在Object類中，而不是Thread類中。
wait()：讓線程從運行狀態進入等待阻塞狀態，並且會釋放它所持有的同步鎖。
yield()：讓線程從運行狀態進入就緒狀態，不會釋放它鎖持有的同步鎖。
sleep()：讓線程從運行狀態進入阻塞狀態，不會釋放它鎖持有的同步鎖。
以上只是簡單的一個線程狀態圖，其實線程狀態博大精深，要講清楚還是要一大篇文筆，作為入門文章先了解一下吧，之後的併發編程文章將再講述吧！
如果想要去深入了解一下的話也是可以的：
在java中只要說到池，基本都是一個套路，啥數據庫連接池、jdbc連接池等，思想基本上就是：一個容納多個要使用資源的容器，其中的資源可以反覆使用，省去了頻繁創建線程對象的操作，無需反覆創建資源而消耗過多資源。
線程池其實就是一個容納多個線程的容器，其中的線程可以反覆使用，省去了頻繁創建線程對象的操作，無需反覆創建線程而消耗過多資源。
合理利用線程池能夠帶來三個好處：
- 降低資源消耗。減少了創建和銷毀線程的次數，每個工作線程都可以被重複利用，可執行多個任務。
- 提高響應速度。當任務到達時，任務可以不需要的等到線程創建就能立即執行。
- 提高線程的可管理性。可以根據系統的承受能力，調整線程池中工作線線程的數目，防止因為消耗過多的內存，而把服務器累趴下(每個線程需要大約1MB內存，線程開的越多，消耗的內存也就越大，最後死機)。
Java裏面線程池的最頂級接口是java.util.concurrent.Executor，但是嚴格意義上講Executor並不是一個線程池，而只是一個執行線程的工具。真正的線程池接口是java.util.concurrent.ExecutorService。
要配置一個線程池是比較複雜的，尤其是對於線程池的原理不是很清楚的情況下，很有可能配置的線程池不是較優的，因此在java.util.concurrent.Executors線程工廠類裏面提供了一些靜態工廠，生成一些常用的線程池。官方建議使用Executors工程類來創建線程池對象。
Executors類中有個創建線程池的方法如下：
public static ExecutorService newFixedThreadPool(int nThreads)：返回線程池對象。(創建的是有界線程池,也就是池中的線程個數可以指定最大數量)獲取到了一個線程池ExecutorService 對象，那麼怎麼使用呢，在這裏定義了一個使用線程池對象的方法如下：
public Future<?> submit(Runnable task):獲取線程池中的某一個線程對象，並執行Future接口：用來記錄線程任務執行完畢后產生的結果。線程池創建與使用。
使用線程池中線程對象的步驟：
- 創建線程池對象。
- 創建Runnable接口子類對象。(task)
- 提交Runnable接口子類對象。(take task)
- 關閉線程池(一般不操作這一步)。
Runnable實現類代碼：
public class MyRunnable implements Runnable {
@Override
public void run() {
System.out.println("我要一個游泳教練");
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("教練來了： " + Thread.currentThread().getName());
System.out.println("教我游泳,教會後，教練又回到了游泳池");
}
}線程池測試類：
public class ThreadPoolDemo {
public static void main(String[] args) {
// 創建線程池對象
ExecutorService service = Executors.newFixedThreadPool(2);//包含2個線程對象
// 創建Runnable實例對象
MyRunnable r = new MyRunnable();
//自己創建線程對象的方式
// Thread t = new Thread(r);
// t.start(); ---> 調用MyRunnable中的run()
// 從線程池中獲取線程對象,然後調用MyRunnable中的run()
service.submit(r);
// 再獲取個線程對象，調用MyRunnable中的run()
service.submit(r);
service.submit(r);
// 注意：submit方法調用結束后，程序並不終止，是因為線程池控制了線程的關閉。
// 將使用完的線程又歸還到了線程池中
// 關閉線程池
//service.shutdown();
}
}以上只是簡單的使用線程池，僅僅是入門階段！道阻且長，路還很長….
到這裏，本文章入門暫時告一段落，以後有時間盡量抽空更新….
如果本文章對你有幫助，哪怕是一點點，請點個讚唄，謝謝你~
歡迎各位關注我的公眾號，一起探討技術，嚮往技術，追求技術…說好了來了就是盆友喔…
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※試算大陸海運運費!