This question is a duplicate, however I feel that it's necessary given the question. The original was posted in 2012: about 5 years ago before NIST had even published the final specification.
The question is more or less the same as the original. Has SHA3 been studied enough to be considered secure for high-value situations, and is there an advantage to using it over it's predecessor, SHA2. Basically, should we use it?
I'm not convinced that we should. SHA-3 has some nicefeatures for sure, but for the reasons I list below, I would probably suggest using SHA-2 or BLAKE2 for the time being. Even NIST themselves say:
Currently there is no need to transition applications from SHA-2 to SHA-3.
That said, you may still be thinking "why not"?
SHA-3 is not yet FIPS-140 compliant. Without FIPS 140-3, it is out of reach of non-military government agencies and government contractors. If you are worried about FIPS compliance, you are stuck with the SHA-2 suite for now.SHA-3 was included in FIPS 140-2 Annex A, and even though this document still says "Draft" on the cover page it appears to have been finalized via thesetwo pages.
Performance. SHA-3 is incredibly fast in hardware (ASIC) implementations. However, it is much slower in software running on CPUs with limited registers, meaning it's less useful generally*. Its primary competitor (at least, in the aftermath of the competition) is BLAKE2, which has shown to be much faster on general CPUs and is sometimes favored over Keccak/SHA-3 for other reasons. While I feel that NIST understated the in-software performance differences between finalists, their comments on performance in the last round of decision making may be helpful to provide context. From NISTIR 7896, section 3.2:
a. All five finalists perform well enough to be usable in most applications.
b. None of the five finalists is the best for every application, and none offers really compelling improvements over the SHA-2 algorithms.
c. The ARX-based algorithms, BLAKE and Skein, perform extremely well in software.
d. Keccak has a clear advantage in throughput/area performance in hardware implementations.
e. Grøstl and JH are considerably slower than the other three algorithms in most software implementations.
Potentially unnecessary prudence. It is also worth noting that BLAKE got negative remarks due to how similar it was to SHA-2. Out of prudence, this helped Keccak/SHA-3 win the competition. From NISTIR 7896, section 3.4:
b. Because SHA-2 is an ARX-based design with a key schedule, it has some important design elements in common with BLAKE and Skein, although neither is closely related to SHA-2. However, cryptanalytic tools that apply to SHA-2 in the future seem more likely to apply to BLAKE or Skein than to the other three finalists.
* Recall that we're discussing cryptographic hash functions here, not necessarily password hashing functions or KDFs.
You should be using the strongest cipher you can, and SHA3 seems to be suitable. Altough, you are ahead of your age, since almost nobody uses it. Not even OpenSSL supports SHA3. The thing is, SHA2 is still generally considered secure, and for a complex system, you would be better off choosing SHA2 over SHA3 to avoid incompatibility issues.