들어본 적 없는 Java 8의 10가지 기능

람다, 람다, 람다. 사람들이 Java 8에 관해 이야기할 때 듣는 내용은 이것이 전부입니다. 그러나 그것은 단지 한 부분일 뿐입니다. Java 8에는 몇 가지 강력한 새 클래스와 관용어, 그리고 처음부터 있어야 했던 기능 등 많은 새로운 기능이 있습니다. 저는 확실히 알 가치가 있는 작은 보석이라고 생각되는 10가지 새로운 기능으로 넘어가고 싶었습니다. 그 중에 여러분이 시도해보고 싶은 것이 적어도 한두 개 있을 테니 시작해 보세요! 1) 기본 방법. Java 언어의 새로운 기능으로 이제 인터페이스( 기본 메소드 )에 메소드 본문을 추가할 수 있습니다. 이러한 메서드는 해당 인터페이스를 구현하는 모든 클래스에 무조건 추가됩니다. 이는 이전 코드를 손상시키지 않고 기존 라이브러리에 새로운 기능을 추가할 수 있는 기회를 제공합니다. 그것은 확실히 플러스입니다. 반면에 이는 특정 조건을 규칙으로 따라야 하는 인터페이스와 이를 따르는 클래스(개인 구현) 사이의 경계를 심각하게 모호하게 만듭니다. (오른쪽) 사용자에게 이는 인터페이스를 더 스마트하게 만들고, 반복을 피하고, 라이브러리를 확장하는 우아한 방법이 될 수 있습니다. 나쁜 손에; 우리는 이것을 호출하고 이를 구체적인 유형으로 변환하는 인터페이스의 메소드를 곧 보게 될 것입니다. Brrr.... 2) 프로세스를 중지하는 중입니다. 추가 프로세스를 시작하는 것은 프로세스가 중단(크랙)(충돌)되거나 정지(중지)되거나 CPU를 100% 사용할 때 디버깅하기 위해 다시 돌아와(디버그) 반쯤 알고 있는 작업 중 하나입니다. Process 클래스는 이제 통제하기 어려운 프로세스를 제어하는 ​​데 도움이 되는 두 가지 새로운 메서드로 무장되었습니다. 첫 번째 isAlive()를 사용 하면 프로세스를 기다리지 않고도 프로세스가 실행 중인지 쉽게 확인할 수 있습니다. 두 번째이자 더 강력한(경고!) 것은 destroyForcically() 입니다. 이를 통해 시간(대기 중이든 아니든)을 초과했거나 더 이상 필요하지 않은 프로세스를 (뻔뻔하게) 강제로(종료) 중지할 수 있습니다. 3) 스탬프락. 이제 정말 흥미로운 일이 생겼습니다. 코드 동기화를 좋아하는 사람은 없습니다. 이는 애플리케이션의 성능을 저하시키거나(특히 대규모로) 더 심한 경우 애플리케이션을 정지시키는 확실한 방법입니다. 그럼에도 불구하고 때로는 선택의 여지가 없습니다. 리소스에 대한 멀티스레드 액세스를 동기화하는 데는 다양한 관용구가 있습니다. 가장 선호되는 것 중 하나는 ReadWriteLock 및 관련 구현입니다. 이 관용구는 리소스를 조작하는 스레드만 차단하면서 여러 스레드가 리소스를 사용하도록 허용함으로써 경합을 줄입니다. 듣기에는 좋지만 실제로 이 잠금은 너무 느립니다 . 특히 쓰기 스레드 수가 많은 경우에는 더욱 그렇습니다. 이는 너무 나쁜 것으로 판명되어 Java 8에는 StampedLock 이라는 새로운 RWLock이 도입되었습니다 . 이 잠금은 속도가 더 빠를 뿐만 아니라 낙관적 잠금을 위한 강력한 API를 제공합니다. 여기서는 코드의 중요한 섹션 동안 쓰기 작업이 발생하지 않기를 바라면서 저렴한 비용으로 읽기 잠금을 얻을 수 있습니다. 섹션이 끝나면 해당 시간 동안 녹음이 발생했는지 잠금에 묻습니다. 이 경우 다시 시도할지, 잠금을 에스컬레이션할지, 아니면 포기할지 결정할 수 있습니다. 이 자물쇠는 강력한 도구이며 그 자체에 대해 포스팅할 가치가 있습니다. 나는 이 새로운 장난감에 대해 엄청나게 흥분된다. 엄청난! 추가적으로 당신은 읽을 수 있습니다 여기 . 4) 경쟁 기록자. 이는 멀티스레드 애플리케이션을 실행하는 사람을 위한 또 하나의 작은 보석입니다. 여러 스레드에서 카운터를 읽고 쓰기 위한 간단하고 효율적인 새 API입니다 . 때로는 AtomicInteger를 사용하는 것보다 훨씬 빠릅니다. 꽤 멋져! 5) 선택적(또는 선택적) 값. 아, 널 포인터는 모든 Java 개발자에게 골칫거리입니다. 아마도 모든 예외 중에서 가장 인기 있는 것은 매우 초기부터 존재해 왔습니다. 적어도 1965년 이후 . Scala 및 Haskell에서 차용한 Java 8에는 null이 될 수 있는 참조를 래핑하기 위한 Optional이라는 새로운 패턴이 있습니다. 이는 결코 null을 없애는 묘책이 아니라 API 디자이너가 코드 수준에서(문서 대신) null 값이 반환되거나 메서드에 전달될 수 있음을 표시하는 수단이며 호출자는 반드시 이를 수행해야 합니다. 그것을 준비하십시오. 따라서 이는 호출자가 참조가 안전하지 않게 역참조될 수 있는 래퍼에서 이스케이프되는 것을 허용하지 않는 경우 새 API에 대해서만 작동합니다. 나는 이 기능에 대해 상당히 양면적인 입장을 갖고 있다고 말하고 싶습니다. 한편으로 null은 여전히 ​​큰 문제로 남아 있으므로 이 문제를 해결하기 위해 수행된 모든 노력에 감사드립니다. 반면에 나는 이것이 성공할 수 있을지 매우 회의적이다. Optional을 사용하려면 회사 전체의 지속적인 노력이 필요하고 즉각적인 영향이 거의 없기 때문입니다. 강력한 단속이 없으면 도로 왼쪽에 머물 가능성이 높습니다. Optional 에 대해 자세히 알아보세요 . 6) 모든 것에 주석을 답니다. Java 언어의 또 다른 작은 발전은 코드의 거의 모든 것에 주석을 추가할 수 있다는 것입니다. 이전에는 클래스나 메서드 선언 같은 항목에만 주석을 추가할 수 있었습니다. Java 8부터 값을 특정 유형으로 캐스팅하거나 새 객체를 할당할 때 변수 및 매개변수 선언에 주석을 추가할 수 있습니다. 이는 언어를 정적 분석 및 측정 도구(예: FindBugs)에 더욱 친숙하게 만들기 위한 집중적인 노력(JavaDoc 도구 및 API 개선과 함께)의 일부입니다. 이것은 좋은 기능이지만 Java 7에 도입된 InvokeDynamic 과 마찬가지로 실제 가치는 사회가 이를 어떻게 활용하는지에 따라 달라집니다. 7) 오버플로 작업. 이제 일련의 방법이 있습니다., 이는 첫날부터 핵심 라이브러리의 일부였어야 합니다. 내가 가장 좋아하는 취미는 정수가 2^32를 초과할 때 숫자 오버플로를 디버깅하고 가장 심각하고 예상치 못한 오류(예: "도대체 어떻게 이런 이상한 값을 얻는가?")를 생성하는 것입니다. 다시 말하지만, 여기에는 묘책이 없지만, 무조건 오버플로되는 표준 +/* 연산자보다 덜 관대하게 오버플로될 때 숫자를 조작하는 함수가 많이 있습니다. 8) 카탈로그를 살펴보세요. 디렉토리 트리의 내용을 반복하는 것은 오랫동안 사람들이 Google에서 검색하는 것 중 하나였습니다(이 경우 Apache.FileUtils를 사용하는 것이 좋습니다). Java 8에서는 Files 클래스 에 10가지 새로운 메소드가 추가되었습니다. 내가 가장 좋아하는 것은 디렉토리 구조의 내용을 반복하기 위해 게으른 스레드(대형 파일 시스템에 중요)를 생성하는 walk() 입니다. 9) 강력한 무작위 생성. 요즘에는 비밀번호와 키의 취약성에 대한 이야기가 넘쳐납니다. 소프트웨어 보안은 복잡한 비즈니스이며 오류가 발생하기 쉽습니다. 이것이 바로 제가 새로운 SecureRandom 방법을 좋아하는 이유입니다. getinstanceStrong() - Java Virtual Machine에 사용할 수 있는 가장 강력한 무작위 생성기를 자동으로 선택합니다. 이렇게 하면 오류가 발생하거나 생성기가 약해질 가능성이 줄어들어 키와 암호화된 값이 해킹에 더 취약해집니다. 10. 날짜.toInstant(). Java 8에는 날짜와 시간에 대한 완전히 새로운 API가 도입되었습니다 . 기존의 것이 그다지 좋지 않기 때문에 이것은 꽤 이해할 수 있습니다. Joda는 본질적으로 몇 년 동안 날짜와 시간에 대한 Java API를 지향해 왔습니다. 그러나 새 API를 사용하더라도 한 가지 큰 문제가 남아 있습니다. 이전 API를 사용하는 코드와 라이브러리가 엄청나게 많습니다. 그리고 우리 모두는 그들이 여기에 남아 있다는 것을 알고 있습니다. 그래서 너는 뭘 할 껀데? 이를 달성하기 위해 Java 8은 이를 새로운 API로 변환하는 toInstant() 라는 Date 클래스에 새로운 메소드를 추가하여 다소 우아한 작업을 수행했습니다 . 이를 통해 이전 날짜 API를 사용하는 코드로 작업하는 경우에도 새 API로 빠르게 이동할 수 있습니다(가까운 미래에도 계속 그렇게 할 것입니다).