本發(fā)明涉及計(jì)算機(jī)技術(shù)領(lǐng)域，特別涉及計(jì)算機(jī)數(shù)據(jù)處理和性能調(diào)優(yōu)技術(shù)領(lǐng)域，具體為一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)。

背景技術(shù)：

Java是一門(mén)面向?qū)ο缶幊陶Z(yǔ)言，不僅吸收了C++語(yǔ)言的各種優(yōu)點(diǎn)，還摒棄了C++里難以理解的多繼承、指針等概念，因此Java語(yǔ)言具有功能強(qiáng)大和簡(jiǎn)單易用兩個(gè)特征。Java語(yǔ)言作為靜態(tài)面向?qū)ο缶幊陶Z(yǔ)言的代表，極好地實(shí)現(xiàn)了面向?qū)ο罄碚?，允許程序員以?xún)?yōu)雅的思維方式進(jìn)行復(fù)雜的編程。目前很多的應(yīng)用程序都采用Java語(yǔ)言進(jìn)修編寫(xiě)，例如日志分析系統(tǒng)使用了Java。Java最誘人的特性之一是不需要顯式地管理對(duì)象的生命周期，當(dāng)對(duì)象不再被使用時(shí)，會(huì)由JVM(Java Virtual Machine，Java虛擬機(jī))在后臺(tái)自動(dòng)進(jìn)行回收，這種回收稱(chēng)為“垃圾回收”。簡(jiǎn)單來(lái)說(shuō)，垃圾回收由兩步構(gòu)成：查找不再使用的對(duì)象，以及釋放這些對(duì)象所管理的內(nèi)存。垃圾收集器回收對(duì)象或者在內(nèi)存中移動(dòng)對(duì)象時(shí)，對(duì)象的內(nèi)存地址會(huì)發(fā)生變化，所以必須確保應(yīng)用程序線程不再繼續(xù)使用這些對(duì)象。為了確保在回收過(guò)程中，任何應(yīng)用程序都不再訪問(wèn)該對(duì)象，所有的應(yīng)用線程會(huì)在垃圾回收過(guò)程中被停止運(yùn)行，這被稱(chēng)為時(shí)空停頓(stop-the-world)。通常這些停頓對(duì)應(yīng)用的性能影響很大。并且JVM堆內(nèi)存設(shè)置越大，會(huì)導(dǎo)致在垃圾回收過(guò)程中應(yīng)用程序停頓時(shí)間越長(zhǎng)。比如在測(cè)試環(huán)境中，配置JVM堆內(nèi)存為10GB，就會(huì)出現(xiàn)十幾秒的卡頓(圖1)，配置更多的JVM堆內(nèi)存會(huì)導(dǎo)致更長(zhǎng)時(shí)間的卡頓，這對(duì)于實(shí)時(shí)日志分析是不可忍受的性能問(wèn)題。另一方面，我單機(jī)服務(wù)器內(nèi)存有64GB甚至128GB，剩下的內(nèi)存就不能很好的利用了。

現(xiàn)有的一些廠商通過(guò)基于物理機(jī)上的虛擬機(jī)集群的方式來(lái)解決性能問(wèn)題，但是虛擬化對(duì)于硬件性能損耗比較高，資源較為浪費(fèi)。

技術(shù)實(shí)現(xiàn)要素：

鑒于以上所述現(xiàn)有技術(shù)的缺點(diǎn)，本發(fā)明的目的在于提供一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)，用于解決現(xiàn)有技術(shù)無(wú)法有效優(yōu)化服務(wù)器內(nèi)存資源利用率和應(yīng)用程序性能的問(wèn)題。

為實(shí)現(xiàn)上述目的及其他相關(guān)目的，本發(fā)明在一方面提供一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法，應(yīng)用于裝設(shè)Linux系統(tǒng)的服務(wù)器中，所述優(yōu)化服務(wù)器內(nèi)存資源利用率的方法包括以下步驟：于服務(wù)器上配置Docker引擎；于所述服務(wù)器上安裝基于所述Docker引擎獲取的所述服務(wù)器上應(yīng)用程序的Docker鏡像；利用安裝的所述應(yīng)用程序的Docker鏡像啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群；配置各所述Docker容器的堆內(nèi)存的大小；根據(jù)所述服務(wù)器的主機(jī)內(nèi)存的大小實(shí)時(shí)動(dòng)態(tài)調(diào)整所述Docker容器集群中Docker容器的數(shù)量。

于本發(fā)明的一實(shí)施例中，所述應(yīng)用程序?yàn)閷?shí)時(shí)日志分析應(yīng)用程序。

于本發(fā)明的一實(shí)施例中，通過(guò)配置所述應(yīng)用程序的Docker鏡像中的應(yīng)用程序啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群。

于本發(fā)明的一實(shí)施例中，所述Docker容器的堆內(nèi)存的大小范圍為1GB～15GB。

本發(fā)明另一方面還提供一種優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)，應(yīng)用于裝設(shè)Linux系統(tǒng)的服務(wù)器中，所述優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)包括：Docker引擎配置模塊，用于服務(wù)器上配置Docker引擎；Docker鏡像安裝模塊，用于于所述服務(wù)器上安裝基于所述Docker引擎獲取的所述服務(wù)器上應(yīng)用程序的Docker鏡像；Docker容器集群模塊，用于利用安裝的所述應(yīng)用程序的Docker鏡像啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群；堆內(nèi)存配置模塊，用于配置各所述Docker容器的堆內(nèi)存的大?。籇ocker容器數(shù)量調(diào)整模塊，用于根據(jù)所述服務(wù)器的主機(jī)內(nèi)存的大小實(shí)時(shí)動(dòng)態(tài)調(diào)整所述Docker容器集群中Docker容器的數(shù)量。

于本發(fā)明的一實(shí)施例中，所述應(yīng)用程序?yàn)閷?shí)時(shí)日志分析應(yīng)用程序。

于本發(fā)明的一實(shí)施例中，所述Docker容器集群模塊通過(guò)配置所述應(yīng)用程序的Docker鏡像中的應(yīng)用程序啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群。

于本發(fā)明的一實(shí)施例中，所述Docker容器的堆內(nèi)存的大小范圍為1GB～15GB。

本發(fā)明另一方面還提供一種服務(wù)器，所述服務(wù)器中裝設(shè)Linux系統(tǒng)，所述服務(wù)器上包含有如上所述的優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)。

如上所述，本發(fā)明的優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)，具有以下有益效果：

1、本發(fā)明通過(guò)多Docker容器組成的集群控制應(yīng)用程序(例如實(shí)時(shí)日志分析應(yīng)用程序)運(yùn)行，有效提升了服務(wù)器主機(jī)內(nèi)存的利用率，解決了服務(wù)器內(nèi)存資源浪費(fèi)的問(wèn)題。

2、本發(fā)明降低了JVM垃圾回收過(guò)程中的卡頓，卡頓由原來(lái)的十幾秒，到改良后業(yè)務(wù)層面感受不到卡頓，解決了由于JVM堆內(nèi)存配置過(guò)大，導(dǎo)致時(shí)空停頓時(shí)間過(guò)長(zhǎng)的問(wèn)題，有效提升了應(yīng)用程序的性能。

附圖說(shuō)明

圖1顯示為本發(fā)明的優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)中采用的Docker容器的架構(gòu)圖。

圖2顯示為現(xiàn)有技術(shù)中虛擬機(jī)的架構(gòu)圖。

圖3顯示為本發(fā)明的優(yōu)化服務(wù)器內(nèi)存資源利用率的方法的流程示意圖。

圖4顯示為本發(fā)明的優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)的原理結(jié)構(gòu)示意圖。

圖5顯示為本發(fā)明的優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)的應(yīng)用實(shí)例圖。

元件標(biāo)號(hào)說(shuō)明

100 優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)

101 Docker引擎配置模塊

102 Docker鏡像安裝模塊

103 Docker容器集群模塊

104 堆內(nèi)存配置模塊

105 Docker容器數(shù)量調(diào)整模塊

S101～S105 步驟

具體實(shí)施方式

以下通過(guò)特定的具體實(shí)例說(shuō)明本發(fā)明的實(shí)施方式，本領(lǐng)域技術(shù)人員可由本說(shuō)明書(shū)所揭露的內(nèi)容輕易地了解本發(fā)明的其他優(yōu)點(diǎn)與功效。本發(fā)明還可以通過(guò)另外不同的具體實(shí)施方式加以實(shí)施或應(yīng)用，本說(shuō)明書(shū)中的各項(xiàng)細(xì)節(jié)也可以基于不同觀點(diǎn)與應(yīng)用，在沒(méi)有背離本發(fā)明的精神下進(jìn)行各種修飾或改變。需說(shuō)明的是，在不沖突的情況下，以下實(shí)施例及實(shí)施例中的特征可以相互組合。

本實(shí)施例的目的在于提供一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)，用于解決現(xiàn)有技術(shù)無(wú)法有效優(yōu)化服務(wù)器內(nèi)存資源利用率和應(yīng)用程序性能的問(wèn)題。以下將詳細(xì)闡述本實(shí)施例的一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)的原理及實(shí)施方式，使本領(lǐng)域技術(shù)人員不需要?jiǎng)?chuàng)造性勞動(dòng)即可理解本實(shí)施例的一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)。

本實(shí)施例中的一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)本發(fā)針對(duì)應(yīng)用程序(例如日志分析系統(tǒng))所在的服務(wù)器單機(jī)內(nèi)存資源利用率和應(yīng)用程序性能問(wèn)題，提供一種改良的方法，本實(shí)施例中的一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)通過(guò)結(jié)合Docker容器技術(shù)，可以解決應(yīng)用程序(例如單機(jī)日志分析系統(tǒng))的以下問(wèn)題：

1)JVM堆內(nèi)存配置過(guò)大，導(dǎo)致stop-the-world時(shí)間過(guò)長(zhǎng)的問(wèn)題；2)單機(jī)服務(wù)器內(nèi)存(大于64GB)浪費(fèi)的問(wèn)題；3)提升應(yīng)用程序(例如單機(jī)日志分析系統(tǒng))性能的問(wèn)題。

Docker是Paas提供商dotCloud開(kāi)源的一個(gè)基于LXC的高級(jí)容器引擎，源代碼托管在Github上，基于go語(yǔ)言并遵從Apache2.0協(xié)議開(kāi)源。它讓開(kāi)發(fā)者可以打包他們的應(yīng)用以及依賴(lài)包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的Linux機(jī)器上，也可以實(shí)現(xiàn)虛擬化。容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口，幾乎沒(méi)有性能開(kāi)銷(xiāo)，可以很容易地在機(jī)器和數(shù)據(jù)中心中運(yùn)行。最重要的是，它們不依賴(lài)于任何語(yǔ)言、框架。如圖1所示，顯示為本發(fā)明的優(yōu)化服務(wù)器內(nèi)存資源利用率的方法及系統(tǒng)中采用的Docker容器的架構(gòu)圖，如圖2所示，顯示為現(xiàn)有技術(shù)中虛擬機(jī)的架構(gòu)圖。通過(guò)圖1和圖2的對(duì)比，可以知道Docker容器的架構(gòu)和現(xiàn)有虛擬機(jī)的架構(gòu)的區(qū)別，實(shí)際上，Docker可以理解為更為輕量級(jí)的虛擬機(jī)。

具體地，如圖3所示，本實(shí)施例提供一種優(yōu)化服務(wù)器內(nèi)存資源利用率的方法，應(yīng)用于裝設(shè)Linux系統(tǒng)的服務(wù)器中，所述優(yōu)化服務(wù)器內(nèi)存資源利用率的方法包括以下步驟：

步驟S101，于服務(wù)器上配置Docker引擎。

步驟S102，于所述服務(wù)器上安裝基于所述Docker引擎獲取的所述服務(wù)器上應(yīng)用程序的Docker鏡像。Docker提供了命令行工具，通過(guò)命令行“docker pull<鏡像地址>”可以將某個(gè)Docker鏡像從Docker官方倉(cāng)庫(kù)或者私有倉(cāng)庫(kù)中拉到所述服務(wù)器。應(yīng)用程序的Docker鏡像的制作方法可以采用編寫(xiě)Dockerfile來(lái)實(shí)現(xiàn)。

于本實(shí)施例中，所述應(yīng)用程序例如為實(shí)時(shí)日志分析應(yīng)用程序，例如為AnyRobot日志分析系統(tǒng)，所述服務(wù)器即形成日志分析服務(wù)器。

例如，在日志分析服務(wù)器上安裝基于所述Docker引擎獲取的日志分析系統(tǒng)的Docker鏡像。

即于本實(shí)施例中，例如在日志分析服務(wù)器上部署Docker Engine軟件和AnyRobot日志分析系統(tǒng)。

步驟S103，利用安裝的所述應(yīng)用程序的Docker鏡像啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群。

具體地，于本實(shí)施例中，通過(guò)配置所述應(yīng)用程序的Docker鏡像中的應(yīng)用程序啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的AnyRobot日志分析系統(tǒng)集群。本實(shí)施例中的優(yōu)化服務(wù)器內(nèi)存資源利用率的方法通過(guò)Docker容器技術(shù)，可以啟動(dòng)多個(gè)日志分析系統(tǒng)的容器，組成集群，來(lái)提升日志分析系統(tǒng)的內(nèi)存資源利用率和性能。

步驟S104，配置各所述Docker容器的堆內(nèi)存的大小。

其中，所述Docker容器的堆內(nèi)存的大小根據(jù)所述服務(wù)器的內(nèi)存的大小設(shè)置，所述Docker容器的堆內(nèi)存的大小小于所述服務(wù)器的內(nèi)存的大小。

優(yōu)選地，所述Docker容器的堆內(nèi)存的大小范圍為1GB～15GB，例如，所述服務(wù)器的內(nèi)存的大小為32GB，優(yōu)選設(shè)置所述Docker容器的堆內(nèi)存的大小為4GB，例如設(shè)置每個(gè)日志分析系統(tǒng)的Docker容器的堆內(nèi)存為4GB大小。

所以本發(fā)明通過(guò)多個(gè)容器集群的設(shè)置，降低了JVM垃圾回收過(guò)程中的卡頓，卡頓由原來(lái)的十幾秒，到改良后業(yè)務(wù)層面感受不到卡頓，解決了由于JVM堆內(nèi)存配置過(guò)大，導(dǎo)致時(shí)空停頓時(shí)間過(guò)長(zhǎng)的問(wèn)題，有效提升了應(yīng)用程序的性能。

步驟S105，根據(jù)所述服務(wù)器的主機(jī)內(nèi)存的大小實(shí)時(shí)動(dòng)態(tài)調(diào)整所述Docker容器集群中Docker容器的數(shù)量。例如，根據(jù)所述服務(wù)器的主機(jī)內(nèi)存的大小，繼續(xù)增加日志分析系統(tǒng)的Docker容器數(shù)量。例如，所述服務(wù)器的主機(jī)內(nèi)存的大小為64GB，設(shè)置每個(gè)日志分析系統(tǒng)的Docker容器的堆內(nèi)存為11GB大小，形成基于Docker容器的應(yīng)用程序集群時(shí)形成Docker容器的數(shù)量為3個(gè)，查看此時(shí)所述服務(wù)器的主機(jī)內(nèi)存，內(nèi)存剩余較大，調(diào)整日志分析系統(tǒng)的Docker容器數(shù)量為4個(gè)，增加了一個(gè)Docker容器。有效提升了服務(wù)器主機(jī)內(nèi)存的利用率，解決了服務(wù)器內(nèi)存資源浪費(fèi)的問(wèn)題。

本實(shí)施例還提供一種優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)，應(yīng)用于裝設(shè)Linux系統(tǒng)的服務(wù)器中，具體地，如圖4所示，所述優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)100包括：Docker引擎配置模塊101，Docker鏡像安裝模塊102，Docker容器集群模塊103，堆內(nèi)存配置模塊104以及Docker容器數(shù)量調(diào)整模塊105。

具體地，于本實(shí)施例中，所述Docker引擎配置模塊101用于服務(wù)器上配置Docker引擎。如圖5所示的Docker Engine。

具體地，于本實(shí)施例中，所述Docker鏡像安裝模塊102用于于所述服務(wù)器上安裝基于所述Docker引擎獲取的所述服務(wù)器上應(yīng)用程序的Docker鏡像。Docker提供了命令行工具，通過(guò)命令行“docker pull<鏡像地址>”可以將某個(gè)Docker鏡像從Docker官方倉(cāng)庫(kù)或者私有倉(cāng)庫(kù)中拉到所述服務(wù)器。應(yīng)用程序的Docker鏡像的制作方法可以采用編寫(xiě)Dockerfile來(lái)實(shí)現(xiàn)。

于本實(shí)施例中，如圖5所示，所述應(yīng)用程序例如為實(shí)時(shí)日志分析應(yīng)用程序，例如為AnyRobot日志分析系統(tǒng)，所述服務(wù)器即形成日志分析服務(wù)器。

例如，在日志分析服務(wù)器上安裝基于所述Docker引擎獲取的日志分析系統(tǒng)的Docker鏡像。

即于本實(shí)施例中，例如在日志分析服務(wù)器上部署Docker Engine軟件和AnyRobot日志分析系統(tǒng)。

具體地，于本實(shí)施例中，所述Docker容器集群模塊103用于利用安裝的所述應(yīng)用程序的Docker鏡像啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群。

具體地，于本實(shí)施例中，所述Docker容器集群模塊103通過(guò)配置所述應(yīng)用程序的Docker鏡像中的應(yīng)用程序啟動(dòng)多個(gè)用于控制所述應(yīng)用程序運(yùn)行的Docker容器，形成基于Docker容器的應(yīng)用程序集群。

所以本實(shí)施例中的優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)100通過(guò)Docker容器技術(shù)，可以啟動(dòng)多個(gè)日志分析系統(tǒng)的容器，組成集群，來(lái)提升日志分析系統(tǒng)的內(nèi)存資源利用率和性能。

具體地，于本實(shí)施例中，所述堆內(nèi)存配置模塊104用于配置各所述Docker容器的堆內(nèi)存的大小。

其中，所述Docker容器的堆內(nèi)存的大小根據(jù)所述服務(wù)器的內(nèi)存的大小設(shè)置，所述Docker容器的堆內(nèi)存的大小小于所述服務(wù)器的內(nèi)存的大小。

優(yōu)選地，所述Docker容器的堆內(nèi)存的大小范圍為1GB～15GB，例如，所述服務(wù)器的內(nèi)存的大小為32GB，優(yōu)選設(shè)置所述Docker容器的堆內(nèi)存的大小為4GB，例如設(shè)置每個(gè)日志分析系統(tǒng)的Docker容器的堆內(nèi)存為4GB大小。

所以本發(fā)明通過(guò)多個(gè)容器集群的設(shè)置，降低了JVM垃圾回收過(guò)程中的卡頓，卡頓由原來(lái)的十幾秒，到改良后業(yè)務(wù)層面感受不到卡頓，解決了由于JVM堆內(nèi)存配置過(guò)大，導(dǎo)致時(shí)空停頓時(shí)間過(guò)長(zhǎng)的問(wèn)題，有效提升了應(yīng)用程序的性能。

具體地，于本實(shí)施例中，所述Docker容器數(shù)量調(diào)整模塊105用于根據(jù)所述服務(wù)器的主機(jī)內(nèi)存的大小實(shí)時(shí)動(dòng)態(tài)調(diào)整所述Docker容器集群中Docker容器的數(shù)量。

例如，根據(jù)所述服務(wù)器的主機(jī)內(nèi)存的大小，繼續(xù)增加日志分析系統(tǒng)的Docker容器數(shù)量。例如，所述服務(wù)器的主機(jī)內(nèi)存的大小為64GB，設(shè)置每個(gè)日志分析系統(tǒng)的Docker容器的堆內(nèi)存為11GB大小，形成基于Docker容器的應(yīng)用程序集群時(shí)形成Docker容器的數(shù)量為3個(gè)，查看此時(shí)所述服務(wù)器的主機(jī)內(nèi)存，內(nèi)存剩余較大，調(diào)整日志分析系統(tǒng)的Docker容器數(shù)量為4個(gè)，增加了一個(gè)Docker容器。有效提升了服務(wù)器主機(jī)內(nèi)存的利用率，解決了服務(wù)器內(nèi)存資源浪費(fèi)的問(wèn)題。

此外，本實(shí)施例中還提供一種服務(wù)器，所述服務(wù)器中裝設(shè)Linux系統(tǒng)，所述服務(wù)器上包含有如上所述的優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)100。所述服務(wù)器優(yōu)選為日志分析服務(wù)器，所述日志分析服務(wù)器上部署Docker Engine軟件和AnyRobot日志分析系統(tǒng)。

其中，上述已經(jīng)對(duì)所述優(yōu)化服務(wù)器內(nèi)存資源利用率的系統(tǒng)100進(jìn)行了詳細(xì)說(shuō)明，在此不再贅述。

綜上所述，本發(fā)明通過(guò)多Docker容器組成的集群控制應(yīng)用程序(例如實(shí)時(shí)日志分析應(yīng)用程序)運(yùn)行，有效提升了服務(wù)器主機(jī)內(nèi)存的利用率，解決了服務(wù)器內(nèi)存資源浪費(fèi)的問(wèn)題；本發(fā)明降低了JVM垃圾回收過(guò)程中的卡頓，卡頓由原來(lái)的十幾秒，到改良后業(yè)務(wù)層面感受不到卡頓，解決了由于JVM堆內(nèi)存配置過(guò)大，導(dǎo)致時(shí)空停頓時(shí)間過(guò)長(zhǎng)的問(wèn)題，有效提升了應(yīng)用程序的性能。所以，本發(fā)明有效克服了現(xiàn)有技術(shù)中的種種缺點(diǎn)而具高度產(chǎn)業(yè)利用價(jià)值。

上述實(shí)施例僅例示性說(shuō)明本發(fā)明的原理及其功效，而非用于限制本發(fā)明。任何熟悉此技術(shù)的人士皆可在不違背本發(fā)明的精神及范疇下，對(duì)上述實(shí)施例進(jìn)行修飾或改變。因此，舉凡所屬技術(shù)領(lǐng)域中具有通常知識(shí)者在未脫離本發(fā)明所揭示的精神與技術(shù)思想下所完成的一切等效修飾或改變，仍應(yīng)由本發(fā)明的權(quán)利要求所涵蓋。