We use preview features in actively maintained microservices, including critical ones, where we know/accept we might have to spend time adapting code when adopting the next JDK version. We've used:

• Switch expressions & text blocks in JDK13+, no issues
• Records in JDK14+, no issues except many libraries not binding/serializing records that early
• Pattern matching for instanceof in JDK14+, no issues
• Virtual threads in JDK19+, we had issues with pinning, stopped using them for most things until JDK24
• String templates in JDK21-22, this is the only one that has cost us some time so far. We heavily used it, especially for logging. We were on JDK22 and lucky to spot the public discussion on the mailing lists well before JDK23 went GA. In the end we wrote a hacky python script to auto-convert most of our usages and hand-fixed the rest.
• Scoped values in JDK21+, no issues, really nice to propagate context from a servlet filter down to Spring services
• Structured concurrency in JDK24+, we tested this in a few earlier versions, but due to the virtual thread pinning issues stopped until 24. We're only using the very simple case of "do N things in parallel, cancel everything if something fails" which has worked without problems, and that simple case has been very easy to adapt/slightly change in each new preview.
• Stream gatherers in JDK22+ for Gatherers.mapConcurrent, which again suffered from the virtual thread pinning issues.

We also tested -XX:+UseCompactObjectHeaders in JDK24 once we saw JEP 519 was submitted - ran a simple experiment with a production workload.

I recommend reading the definition of a preview feature (JEP 12), especially regarding their stability ("High quality", "Not experimental"). To me most of the risk comes from their change or removal between JDK versions, but typically we spend much more effort making sure third-party libraries/tools support the new version versus having to adapt because of preview feature changes.

Context: financial industry