JAVAEE 프로젝트 구조와 동시성 생각

오랫동안 javaee 분야를 지배해온 스캐폴딩은 spring struts2 mybatis/hibernate가 주도합니다.

Spring:

Spring은 Java 서비스만을 위한 것이 아닙니다. CGI 표준의 구현으로서 Spring은 Java 분야의 프레임워크가 아니라 C# 플랫폼에서 여전히 이점을 얻을 수 있습니다. Spring은 Javaee 프로젝트 기본을 크게 단순화하는 추상화 또는 bootde 통합 솔루션과 같은 다양한 편리한 주석 구성 방법을 제공합니다. >

스프링을 사용하는 과정에서 두 가지 측면이 있습니다. 한 부분은 경량 주석이고 다른 부분은 전체 주석으로 기울어집니다.

우선 주석의 전제는 프록시, 동적, 정적, cglib 프록시를 거쳐야 한다는 것입니다. 경량 주석의 경우 관점은 컨트롤러 주석과 같은 정적 또는 일회성 주석입니다. 이러한 일회성 주석 또는 컴파일 타임 주석은 서비스 및 기타 유사한 주석과 관련되어 프로젝트 컨텍스트에서 초기화됩니다. , 이는 단일 경량 객체 인스턴스를 제공합니다. 첫 번째 선택으로 간주됩니다. 이렇게 하면 런타임 중에 프록시 및 반사 비용이 줄어들고 런타임 중에 스택에 더 나은 리소스가 절약됩니다.

또 다른 유형은 동적 주석 또는 런타임 주석인 responsebody입니다. 이 주석의 반영은 요청이 이루어질 때마다 실행됩니다. 런타임 중 주석은 자연스럽게 리소스를 차지합니다.

일반적으로 Annotation은 필요하지 않으면 생략 가능하며, 서블릿 기반의 요청 및 응답 방식을 기반으로 매개변수 검색, 매개변수 전달, 반환 등 MVC가 해결할 수 없는 문제는 없습니다. 등이 있으며 런타임 주석이 전혀 필요하지 않습니다. 런타임 주석은 이 프로세스의 다양한 단점을 보완하기 위해 주석을 실행하기 위해 링을 실행합니다. 메서드 내부에서 사용하세요. 메서드에 작성된 param 주석의 경우 request get을 사용할 때와 비교하여 어떤 코드가 누락되어 있나요? 단지 원래의 1단계 프로세스에 코드 차단 계층을 추가했을 뿐입니다.

주석이 런타임인지 아니면 컴파일 시간 주석인지 확인하는 방법은 매우 간단합니다. Ctrl 키를 누른 채 마우스를 클릭하면 다음이 표시됩니다.

@Target({ElementType. TYPE, ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

@Documented

Retention 이 열거 유형은 사용하는 주석의 유효 기간을 완전하고 명확하게 설명합니다. .

스프링을 사용하세요. 이는 모두가 싱글톤을 사용하는 것을 좋아합니다. 싱글톤은 리소스 식별 경쟁을 유발해야 한다는 점을 제외하면 동시성 자체와 관련이 없습니다. 즉, MVC는 기본적으로 매개변수와 반환을 취하며, 별도의 요청 응답에는 들어오고 나가는 항목이 완전히 격리되어 있습니다. mybatis에 대해 말하면, 많은 사람들이 mybatis의 한 구성에서 다양한 resmapper를 사용합니다. 매번 다양한 Bean이 요청될 때 매개변수로 Bean을 사용할 수 있어야 하며 Mybatis는 표면에서 명확한 SQL 유지 관리를 수행해야 합니다. .Jdbc의 효율성을 크게 떨어뜨리는 대신에 많은 사람들이 그것에 관심을 두지 않습니다. 그들은 문제가 발생하면 메모리를 추가하고 GC에 대해 관심을 갖지 않습니다. 문제는 시간과 공간을 교환하는 것입니다. 동일한 매개변수와 결과 매핑을 사용하면 새 Bean을 생성하고 jdk의 맵을 사용할 수 있습니다. 어느 것이 더 좋을까요? 당연히 jdk 자체의 맵입니다.

저는 항상 jdk 자체의 객체라고 고집스럽게 믿어왔습니다. 빈을 직접 정의하는 것보다 훨씬 적은 양을 소비합니다. 왜요? 미안해요. 나도 모르겠어요. 그래서 나는 항상 오기 위해 지도를 작성하고 가기 위해 지도를 작성합니다. mybatis를 사용할 때, 귀하의 항목이 귀하의 클래스에 프록시되어 있는지 자세히 확인해야 합니다. 방법은 매우 간단합니다. 프로젝트 로그에서 디버그를 열고 로그가 매번 새로운 sqlsession을 생성하는지 확인하십시오. mybatis 세션은 풀링되지 않고 사물에 의해 프록시되지 않습니다. 경쟁하는 SQL이 메서드에 나타나면 죄송하지만 오류는 없지만 데이터베이스는 SQL을 실행하지 않습니다. 곧 연결 풀이 빠르게 사용되고 새 연결이 자주 생성된다는 것을 알게 될 것입니다. 물론, 마이바티스 없이도 할 수 있다면 망설이지 말고 사용하지 않는 것이 맞다.

정적 주석을 최대한 많이 사용해야 하는 이유는 매우 간단합니다. Spring 클래스는 기본적으로 싱글톤입니다. 프로젝트가 충분히 크면 이러한 싱글톤이 차지하는 공간이 충분할까요? 객체 인스턴스는 힙 공간에 있고 참조는 스택에 있습니다. 그렇다면 gc는 언제 이러한 싱글톤 객체를 재활용합니까? 당신은 어떻게 생각하세요? 따라서 주석을 기반으로 하는 경우 동적 프록시의 사용을 줄이십시오. 필요한 곳에 더 많은 자원을 남겨두십시오.

과거에는 힙이 없으면 스택이 없다고 했지만 이제는 jdk1.7의 문자열 상수 풀이 힙에 배치되도록 변경되었습니다.

컴파일과 해석 중 어느 것이 더 좋나요? 물론 분석적이며 컴파일된 것은 중개 모델과 비슷합니다. 따라서 훌륭한 컴파일 언어를 구축하는 것은 해석 언어보다 훨씬 더 어렵습니다.

웹의 구조는 매우 명확합니다. 먼저 컨텍스트이고 그 다음에는 일련의 구성 요소가 순서대로 있습니다. 가장 중요한 것은 Javaee의 표준인 서블릿 구성 요소입니다. 누구나 갖춰야 할 기준. 그러면 많은 프로젝트의 서블릿 매핑이 /라는 것을 알 수 있습니다. 이는 매우 간단하기 때문에 나쁜 방법입니다. 서블릿을 통해 처리할 필요가 없기 때문에 매핑에서는 주로 서버와의 상호 작용을 고려합니다. 웹 컨테이너의 측면 구성 요소 일반적으로 .do 및 .action .do와 같은 두 종류의 식별에는 권한 인증이 필요하며 작업이 직접 해제됩니다. Node.js 등은 서블릿에 들어갈 필요가 없고 웹 컨텍스트는 URL에 따라 직접 반환되며 MVC에 MVC 가로채기 및 릴리스가 없습니다. 이는 불필요하고 문제를 일으키며 문제를 해결하는 좋은 방법이 아닙니다. 문제. 이러한 방식으로 nginx의 개입에 관계없이 정적 리소스는 웹 컨테이너에 대해 정적이며 서블릿과 관계가 없습니다. 서블릿은 처리하는 데 필요한 것에만 관심이 있습니다.

JS를 작성하기 가장 좋은 곳은 어디인가요?

많은 사람들이 jsp나 html로 js를 작성하는 데 익숙합니다. 이는 좋지 않습니다.

프로젝트를 빌드할 때 js와 css가 브라우저에 의해 캐시될 수 있기를 바라야 합니다.

그러면 해당 페이지의 script 태그에 적힌 js는 그냥 태그일 뿐이고 div나 input과 다르지 않고 캐싱되지도 않을 거라 많은 정보를 확인했는데, 제가 본 캐시도 명확하게 나와 있습니다. 캐시 단위는 파일입니다. 라벨 대신. 따라서 파일에 CSS js를 작성하고 파일을 가져오면 파일이 캐시됩니다. 직접적인 명확한 답변이 없기 때문에 이에 대해 완전히 확신할 수 없습니다.

jsp는 실제로 서블릿이므로 동적 페이지이므로 매번 동적 번역을 위해 클래스를 로드해야 하며, 그런 다음 클래스의 write 메소드가 해당 페이지를 브라우저에 http로 작성합니다. 브라우저가 렌더링합니다. html이면 정적입니다. 서블릿이기 때문에 Java 객체이므로 다양한 Java 태그와 메소드가 가능하다는 점은 의심의 여지가 없습니다. 정적은 직접 처리해야 합니다. 정적 페이지는 유사한 매크로 언어를 사용하므로 jsp를 직접 사용하는 것이 좋습니다.

페이지에 한 번에 얼마나 많은 데이터를 로드해야 합니까?

귀하의 페이지가 카테고리별로 항목을 표시하는 경우 목록에 따라 데이터의 양이 매우 적고 수백 개의 항목이며 현재 테이크아웃 주문 앱에 유형이 표시되면 모든 카테고리와 데이터가 다음 위치에 제공됩니다. 따라서 처리는 클라이언트 측에서 처리됩니다. 검색을 포함한 전체 프로세스의 카테고리 전환 및 미리보기는 모두 페이지에서 처리되며, 클라이언트의 js 및 A의 휴대폰이나 컴퓨터에서 실행되는 js는 B의 모바일과 경쟁하지 않습니다. 전화든 컴퓨터든, 유형을 전환할 때마다 ajax를 플래시하면 동일한 웹 컨테이너 그룹이 되기 때문에 경쟁이 발생하게 됩니다. 작업 빈도가 높을수록 경쟁이 커집니다. 이 점은 실제 시나리오와 밀접한 관련이 있습니다.

쿼리에서 반환되는 데이터의 양은 성능과 관련이 거의 없습니다. 수천, 수만 개의 데이터가 수십 KB 수준에 불과합니다.

쿼리 횟수, 즉 서버와의 상호 작용 횟수가 전체 성능의 직접적인 원인입니다.

쿼리의 데이터 양은 쿼리되는 테이블의 크기에 비례합니다. 한 번에 10개의 항목을 반환해도 쿼리 속도가 빨라지지 않거나 한 번에 1,000개의 항목이 반환되므로 쿼리 속도가 느려집니다. . 데이터베이스 작업은 기본적으로 컬렉션 애플리케이션이며 아무것도 생성되지 않습니다.

튜닝의 전제는 가장 적절한 양을 주는 것입니다. 많이 줄수록 적절한 양이 나오는 것은 아닙니다. Jdk나 tomcat이 사용하는 OS에서 소비할 수 있는 메모리에는 상한선이 있습니다. 다른 숫자와 다른 숫자.

nginx를 사용하세요.

필요할 때 캐시를 사용하세요.

필요 여부에 따라 메시지 미들웨어 또는 기타 미들웨어를 선택하세요.

별도 또는 기본 데이터베이스 , 현재 데이터베이스가 비즈니스 볼륨을 지원할 수 없는 것이어야 합니다.

단일 사례가 가장 좋은 방법입니다.

멀티스레딩은 특정 언어를 불문하고 날카로운 검입니다.

스프링을 활용한 현재 최고의 비계입니다.

가능하면 jdbc를 많이 사용하세요.

클라이언트에서 작업을 수행할 수 있다면 서버와 상호 작용하지 마세요. 클라이언트의 리소스는 방대하지만 서버의 리소스는 제한되어 있습니다.

가능한 한 적은 요청을 보내도록 노력하세요. 실시간 애플리케이션이 아닌 이상 요청을 적게 보내는 코드가 좋은 코드입니다.

코드의 모든 도구는 도구이며 API는 가장 이해해야 할 부분입니다.

모든 것은 객체이며 Java에서는 순수합니다. 프록시는 객체, 리플렉션은 객체, 객체는 객체이며 기본 데이터 유형은 객체가 아닙니다.

기본형을 제외한 모든 작업은 객체를 통해 이루어집니다. 아무리 복잡한 과정이라도 메소드의 매개변수와 결합된 해당 객체의 메소드를 통해 이루어집니다. 클래스를 직렬화 및 역직렬화하는 방법을 직설적으로 말하면 파일의 IO 및 전송을 수행한 다음 이를 jvm에 로드하고 객체로 구성하는 것입니다.

rpc가 스레드에서 무언가를 호출하지 않는 이유는 프록시가 사용자의 요구 사항을 매개변수로 변환하고 이를 데이터 스트림으로 전송하기 때문입니다. 그런 다음 스트림은 객체로 변환된 다음 스트리밍되어 다시 전송됩니다. 그런 다음 객체를 구성하고 객체를 통해 처리합니다.

NIO가 좋은 방법이고, netty가 좋은 선택입니다. netty를 능가할 수 있는 멀티스레드 소켓이 있나요?

zookeeper는 분산 등록과 같은 일련의 솔루션을 위한 탁월한 도구입니다.

이런 것들은 원리와 목적이 더해진 것이므로 열심히 찾아보아야 사용할 수 있습니다.

위 내용은 개인적인 이해이므로 수정을 환영합니다.

JAVAEE 프로젝트 구조와 동시성에 대한 더 많은 글은 PHP 중국어 홈페이지를 주목해주세요!