你遇到的这两个错误其实是连锁反应——native库加载失败直接导致了后续的ALPN配置异常，下面是几个针对性的排查和解决步骤：

1. 确认依赖版本兼容性 #

首先要明确，grpc-netty和netty-tcnative的版本必须严格匹配。你用的grpc-netty 1.2.0确实对应netty-tcnative-boringssl-static 1.1.33.Fork26，但要确保依赖管理工具（Maven/Gradle）没有引入冲突的版本。可以运行以下命令检查依赖树：

• Maven：mvn dependency:tree | grep netty
• Gradle：gradle dependencies | grep netty
  如果发现其他版本的netty-tcnative或netty-core，直接排除掉冲突依赖。

2. 调整Tomcat类加载策略 #

Tomcat的类加载器层次可能限制了应用内native库的加载。建议把netty-tcnative-boringssl-static-1.1.33.Fork26.jar从应用的WEB-INF/lib移动到Tomcat的$CATALINA_HOME/lib目录下，让Tomcat的公共类加载器负责加载这个jar，避免应用类加载器的权限限制。

3. 验证系统架构与native库的匹配 #

报错里系统在寻找netty-tcnative-linux-x86_64系列库，你需要确认：

• 运行Tomcat的服务器是x86_64架构的Linux系统，如果是ARM等其他架构，需要替换为对应版本的netty-tcnative包（比如netty-tcnative-boringssl-static-linux-aarch64）。
• 打开你的netty-tcnative-boringssl-static jar包，检查是否包含META-INF/native/libnetty-tcnative-linux-x86_64.so文件。如果没有，说明jar包损坏或下载错误，重新从仓库获取正确的静态包。

4. 手动指定Native库路径 #

如果上述方法无效，可以尝试手动提取native库并指定路径：

1. 从netty-tcnative-boringssl-static-1.1.33.Fork26.jar中提取META-INF/native/libnetty-tcnative-linux-x86_64.so文件，放到服务器的某个目录（比如/opt/tomcat/native-libs）。
2. 修改Tomcat的启动脚本（catalina.sh或catalina.bat），添加JVM参数：

   JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/opt/tomcat/native-libs"
   

3. 重启Tomcat，让JVM能直接定位到这个native库。

5. 排除Jetty ALPN依赖冲突 #

第二个错误提到的Jetty ALPN配置问题，大概率是项目或Tomcat中引入了Jetty的ALPN相关依赖，和netty-tcnative的boringssl实现冲突。检查依赖树，排除所有Jetty的ALPN/NPN依赖，比如Maven中可以这样配置：

<dependency>
    <!-- 替换为你的冲突依赖 -->
    <groupId>xxx</groupId>
    <artifactId>xxx</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-alpn-server</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-alpn-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>

优先解决第一个native库加载的问题，第二个ALPN错误通常会随之消失。如果还是不行，可以尝试升级grpc-netty到1.3.x系列，同时对应升级netty-tcnative版本，新版本的兼容性和稳定性会更好。

内容的提问来源于stack exchange，提问作者Ajay