"java - server"와 "java - client"의 실제 차이점은 무엇입니까?

"java - server"와 "java - client"의 실제 차이점은 무엇입니까?

"java - server"와 "java - client" 사이에 실질적인 차이가 있습니까?

Sun의 사이트에서 찾을 수 있는 것은 모호한 정보뿐입니다.

"-서버 시작 속도는 느리지만 실행 속도는 빨라야 합니다."

진짜 차이점은 무엇인가요?(현재 JDK 1.6.0_07 사용).

이는 HotSpot 및 클라이언트와 서버 구성에 따라 다른 기본 옵션 값(Java HotSpot VM 옵션)과 실제로 연결되어 있습니다.

백서 2장(Java HotSpot Performance Engine 아키텍처):

JDK에는 클라이언트 측 오퍼링과 서버 애플리케이션용으로 조정된 VM의 두 가지 맛의 VM이 포함되어 있습니다.이 두 솔루션은 Java HotSpot 런타임 환경 코드 베이스를 공유하지만 클라이언트와 서버의 고유한 성능 특성에 적합한 다른 컴파일러를 사용합니다.이러한 차이점에는 컴파일인라인 정책 및 힙 기본값이 포함됩니다.

서버와 클라이언트 VM은 비슷하지만 서버 VM은 피크 동작 속도를 최대화할 수 있도록 특별히 조정되어 있습니다.이것은, 기동 시간이 빠를 뿐만 아니라, 런타임 메모리의 설치 공간도 적게 할 뿐만 아니라, 가능한 한 고속의 동작 속도를 필요로 하는, 장시간 실행되는 서버 애플리케이션을 실행하는 것을 목적으로 하고 있습니다.

클라이언트 VM 컴파일러는 이전 버전의 JDK에서 사용된 Classic VM 및 JIT(Just-in-Time) 컴파일러의 업그레이드 역할을 합니다.클라이언트 VM은 애플리케이션 및 애플릿의 런타임 성능을 향상시킵니다.Java HotSpot 클라이언트 VM은 애플리케이션 시작 시간과 메모리 설치 공간을 줄이도록 특별히 조정되어 클라이언트 환경에 특히 적합합니다.일반적으로 클라이언트시스템은 GUI에 적합합니다.

따라서 진정한 차이는 컴파일러 수준에서도 볼 수 있습니다.

클라이언트 VM 컴파일러는 서버 VM에서 컴파일러에 의해 실행되는 보다 복잡한 최적화의 대부분을 실행하려고 하지 않지만, 그 대신 코드 일부를 분석 및 컴파일하는 데 걸리는 시간이 줄어듭니다.즉, 클라이언트 VM을 보다 빠르게 기동할 수 있어 메모리 설치 공간을 줄일 필요가 있습니다.

서버 VM에는 C++ 컴파일러의 최적화에 의해 실행되는 동일한 유형의 최적화와 가상 메서드의 기동간에 적극적인 인라인화 등 기존 컴파일러에서는 실행할 수 없었던 일부 최적화를 지원하는 고도의 적응형 컴파일러가 포함되어 있습니다.이는 스태틱 컴파일러에 비해 경쟁력과 퍼포먼스가 뛰어납니다.적응형 최적화 기술은 접근 방식이 매우 유연하며 일반적으로 고급 정적 분석 및 컴파일 기술보다 성능이 우수합니다.

주의: jdk6 업데이트 10 릴리스(업데이트 릴리스 노트:1.6.0_10)의 변경은 시작 시간을 개선하려고 했지만 핫스팟 옵션과는 다른 이유로 훨씬 작은 커널에서는 다르게 패키징되었습니다.

---

G. Demecki는 코멘트에서 JDK의 64비트 버전에서-client옵션은 오랫동안 무시되고 있습니다.
Windows 명령어 참조:

-client

Java HotSpot VM을 사용합니다.
64비트 지원 JDK는 현재 이 옵션을 무시하고 Java 핫스팟 서버 VM을 사용합니다.

---

2022: JavaSE6/Server-Class Machine Detection 코멘트에서 Holger는 다음과 같이 언급합니다.

시스템, 32비트 Windows -client무조건 뽑혔어요.
다른 시스템에서는 2개 이상의 코어와 2GiB 이상의 메모리가 있을 때 컴퓨터가 "서버 클래스"인지 여부를 확인했습니다.

것이 '아예'를 사용하고 있습니다.-server가장 저렴한 컴퓨터도 "서버 클래스" 머신입니다.Sun/Oracle 64 vm sunvmvm JVM sun sun sun 。

는 Java에 입니다.-client-server과 같은 정보를얻을 수 있습니다.예를 들어 Linux 시스템에서는 다음과 같은 정보를 얻을 수 있습니다.

$ java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E 'heapsize|permsize|version'
uintx AdaptivePermSizeWeight               = 20               {product}
uintx ErgoHeapSizeLimit                    = 0                {product}
uintx InitialHeapSize                     := 66328448         {product}
uintx LargePageHeapSizeThreshold           = 134217728        {product}
uintx MaxHeapSize                         := 1063256064       {product}
uintx MaxPermSize                          = 67108864         {pd product}
uintx PermSize                             = 16777216         {pd product}
java version "1.6.0_24"

로는 「」입니다.-server 단에서는-client션션: :

$ java -client -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E 'heapsize|permsize|version'
uintx AdaptivePermSizeWeight               = 20               {product}
uintx ErgoHeapSizeLimit                    = 0                {product}
uintx InitialHeapSize                     := 16777216         {product}
uintx LargePageHeapSizeThreshold           = 134217728        {product}
uintx MaxHeapSize                         := 268435456        {product}
uintx MaxPermSize                          = 67108864         {pd product}
uintx PermSize                             = 12582912         {pd product}
java version "1.6.0_24"

해서-server은 이 메모리 제한이나 이 훨씬 더 .java전입니니다다

그러나 이러한 값은 아키텍처, 운영 체제 및 jvm 버전의 다양한 조합에 따라 변경될 수 있습니다.jvm의 최신 버전에서는 플래그가 제거되고 서버와 클라이언트의 차이점이 많이 변경되었습니다.

, 실행중의 을 모두 할 수 있는 말아 주세요.jvm를 사용합니다.jvisualvm은 사용자 하여 을(를) 하는 경우에 유용합니다JAVA_OPTS또는 명령줄 옵션을 변경하는 스크립트를 사용합니다.이를 통해 다른 많은 통계 정보와 함께 힙 및 퍼머젠 공간 사용률도 실시간으로 모니터링할 수 있습니다.

-client 및 -server 시스템은 서로 다른 바이너리입니다.이들은 기본적으로 동일한 런타임 시스템에 인터페이스하는2개의 다른 컴파일러(JIT)입니다.클라이언트 시스템은 빠른 부팅 시간이나 작은 설치 공간을 필요로 하는 애플리케이션에 최적입니다.서버 시스템은 전체적인 퍼포먼스가 가장 중요한 애플리케이션에 최적입니다.일반적으로 클라이언트 시스템은 GUI와 같은 인터랙티브 애플리케이션에 적합합니다.

양쪽 스위치로 다음 코드를 실행합니다.

package com.blogspot.sdoulger;

public class LoopTest {
    public LoopTest() {
        super();
    }

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        spendTime();
        long end = System.currentTimeMillis();
        System.out.println("Time spent: "+ (end-start));

        LoopTest loopTest = new LoopTest();
    }

    private static void spendTime() {
        for (int i =500000000;i>0;i--) {
        }
    }
}

주의: 코드는 한 번만 컴파일됩니다!클래스는 두 번의 주행에서 동일합니다!

" " " " 시라 :
- C comjava.exe -client - classpath C:\mywork\classes com.blogspot.sdouger. Test (루프 테스트)
요 7 : 766

「 」 「 」 :
java.exe -server -classpath C:\mywork\classes com.blogspot.sdouger. Test (루프 테스트)
시간: 0

서버 시스템의 최적화를 적극적으로 실시할수록, 루프가 어떠한 액션도 실시하지 않는 것을 인식하고 있기 때문에, 루프를 삭제해 주세요.

언급

제가 방금 깨달은 한 가지 차이점은 클라이언트 모드에서는 JVM이 실제로 사용하지 않는 메모리를 운영체제로 되돌려주는 것처럼 보이지만 서버 모드에서는 JVM이 메모리를 확보하면 메모리를 돌려주지 않는다는 것입니다.에서는 (Java6를 사용한 Solaris를 사용한 경우) 됩니다.prstat -Z프로세스에 할당된 메모리 양을 확인합니다).

Oracle의 온라인 문서에는 Java SE 7에 대한 몇 가지 정보가 나와 있습니다.

Java – Windows용 Java 응용 프로그램런처 페이지에서-client JDK64의 JDK에서는 됩니다.

Java HotSpot 클라이언트 VM을 선택합니다.64비트 지원 jdk는 현재 이 옵션을 무시하고 Java HotSpot 서버 VM을 사용합니다.

() 에는 (재미있게)-server하다

Java HotSpot 서버 VM을 선택합니다.64비트 지원 jdk에서는 Java HotSpot 서버 VM만 지원되므로 -server 옵션은 암묵적입니다.이는 향후 릴리즈에서 변경될 수 있습니다.

[ Server - Class Machine Detection ]페이지에는 OS 및 아키텍처에 의해 선택된 VM에 대한 정보가 표시됩니다.

이게 JDK 6에 얼마나 적용되는지 모르겠어요.

Goetz에서 - Java 동시 실행:

6. """를 해야 합니다.-serverJVM을 호출할 때 JVM 명령줄 스위치(개발 및 테스트 시에도 해당)서버 JVM은 클라이언트 JVM보다 더 많은 최적화를 수행합니다.예를 들어 루프 내에서 수정되지 않은 변수를 루프 밖으로 끌어올립니다.개발 환경(클라이언트 JVM)에서 동작하는 것처럼 보이는 코드가 전개 환경(서버 JVM)에서 파손될 수 있습니다.예를 들어 List 3.4에서 변수 sleeve를 휘발성으로 선언하는 것을 "잊어버렸다"고 하면 서버 JVM은 테스트를 루프에서 끌어올릴 수 있지만(무한 루프로 전환한다), 클라이언트 JVM은 그렇지 않습니다.개발 중에 나타나는 무한 루프는 실제 가동 시에만 나타나는 루프보다 훨씬 비용이 적게 듭니다.

리스트 3.4양을 세다.

volatile boolean asleep;
...
while (!asleep)
   countSomeSheep();

내가 강조하는 것.YMMV

IIRC 서버 VM은 부팅 시 더 많은 핫스팟 최적화를 수행하므로 실행은 빨라지지만 시작에는 다소 시간이 걸리고 더 많은 메모리를 사용합니다.클라이언트 VM은 보다 빠른 부팅을 위해 대부분의 최적화를 지연시킵니다.

추가할 편집:여기 Sun의 정보가 있습니다. 구체적이지는 않지만 몇 가지 아이디어를 드릴 것입니다.

IIRC는 쓰레기 수집 전략을 수반합니다.이 이론은 클라이언트와 서버가 단수명 오브젝트라는 점에서 다르다는 것입니다.이것은 현대의 GC 알고리즘에 있어서 중요합니다.

서버 모드에 대한 링크를 다음에 나타냅니다.아아, 클라이언트 모드에 대해서는 언급하지 않았습니다.

여기 GC 전반에 대한 매우 상세한 링크가 있습니다.이것은 보다 기본적인 기사입니다.주소 -server와 클라이언트 중 어느 쪽인지 확실하지 않지만 관련 자료입니다.

No Fluff Just Stuff에서 Ken Sipe와 Glenn Vandenburg 둘 다 이런 것에 대해 훌륭한 대화를 나눈다.

2개의 기동 시간의 차이는 없었지만, 「-server」(Solaris 서버, SunRays를 사용해 앱을 실행하는 모든 사람)로 애플리케이션 퍼포먼스의 향상을 최소한으로 억제했습니다.1.5 미만이었어요.

마지막으로 봤을 때 가장 큰 차이는 쓰레기 수거입니다.

IIRC:

• 서버 힙 VM에는 클라이언트 VM과 다른 세대 수와 다른 가비지 수집 알고리즘이 있습니다.이것은 더 이상 사실이 아닐지도 모른다.
• 서버 VM은 메모리를 할당하고 OS에 메모리를 릴리스하지 않습니다.
• 서버 VM은 보다 고도의 최적화 알고리즘을 사용하기 때문에 최적화를 위한 시간과 메모리 요건이 커집니다.

jvisualvm 도구를 사용하여 2개의 Java VM, 1개의 클라이언트, 1개의 서버를 비교할 수 있는 경우 가비지 컬렉션의 빈도와 효과 및 세대 수에 차이가 있습니다.

차이를 잘 보여주는 스크린샷이 두 개 있었지만 서버 VM만 구현하는 64비트 JVM을 가지고 있기 때문에 복제할 수 없습니다(또한 32비트 버전을 시스템에 다운로드하여 문제삼을 필요도 없습니다).

지금은 그렇지 않은 것 같습니다.서버와 클라이언트 VM을 모두 사용하여 Windows에서 몇 가지 코드를 실행해 본 결과, 양쪽에서 같은 세대의 모델을 얻을 수 있었습니다.

1.4에서 1.7("1.7.0_55") 버전으로 이행하는 경우.여기서 알게 된 것은 힙사이즈|펌사이즈|에 할당된 기본값에는 이와 같은 차이가 없다는 것입니다.클라이언트 및 서버 모드의 ThreadStackSize 파라미터.

참고로 (http://www.oracle.com/technetwork/java/ergo5-140223.html)).위의 링크에서 가져온 스니펫입니다.

initial heap size of 1/64 of physical memory up to 1Gbyte
maximum heap size of ¼ of physical memory up to 1Gbyte

ThreadStackSize는 1.7보다 높지만 Open JDK 포럼을 거치는 동안 프레임 사이즈가 1.7 버전보다 다소 높은 것에 대해 논의되고 있습니다.어플리케이션의 동작에 따라 실행 시 실제 차이를 측정할 수 있을 것으로 생각됩니다.

언급URL : https://stackoverflow.com/questions/198577/real-differences-between-java-server-and-java-client