Solaris 11环境下JNI/C本地套接字连接失败问题求助

这种跨Solaris版本的JNI套接字坑我之前踩过好几次，咱们从几个最可能的方向一步步排查：

1. 先抓最关键的线索：打印connect的错误码！ #

你说调用陷入异常状态，但没提具体错误信息——这是第一步必须补的。在JNI代码里，connect调用失败后，立刻用下面的代码把错误细节打出来：

#include <stdio.h>
#include <string.h>
#include <errno.h>

// 在connect调用后添加
if (connect(sockfd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
    fprintf(stderr, "JNI connect failed: errno=%d, msg=%s\n", errno, strerror(errno));
}

Solaris11的错误码和10有不少差异，比如权限问题返回EACCES、路径不存在返回ENOENT，这些信息能直接缩小排查范围。

2. 检查JNI进程与纯C进程的权限/路径差异 #

Solaris11对进程权限和文件系统的管控比10严格太多：

• 套接字文件权限：如果纯C程序是用root或特定用户运行，而JVM是普通用户，那本地套接字文件（比如/tmp/mysocket）的读写权限可能不允许JVM访问。用ls -l查看socket文件的权限和所属用户组，对比JNI进程的运行用户。
• JVM临时目录差异：Java默认的java.io.tmpdir在Solaris11里可能和纯C硬编码的/tmp不是同一个（比如部分JVM会用/var/tmp或用户专属临时目录）。直接打印JNI里要连接的sockaddr_un.sun_path字符串，和纯C的路径做完全对比。

3. JNI线程模型与系统线程库的兼容性问题 #

Solaris11默认把线程库从libthread切换到了libpthread，而JNI线程是绑定在JVM线程上的：

• 编译链接选项检查：纯C程序可能加了-lsocket -lnsl -lpthread链接参数，但JNI的编译脚本是不是漏了这些？用ldd your_jni_library.so在Solaris11上查看依赖，确认socket、nsl、pthread这些库都正确链接。
• 线程上下文对比：纯C可能在主线程调用connect，而JNI是在Java子线程里执行的。试试在JNI的connect前后打印线程ID（用pthread_self()或Solaris的thr_self()），对比纯C的线程ID，看线程环境是否有异常。

4. 套接字参数的隐含传递坑 #

虽然用的是同一个头文件，但JNI层的参数传递容易出细节问题：

• 字符串终止符：如果套接字路径是从Java字符串传过来的，JNI转换时有没有确保C字符串是\0结尾的？比如用GetStringUTFChars拿到的字符串是正确的，但手动拷贝时没加终止符，sockaddr_un.sun_path就会出现乱码，导致连接到不存在的socket。
• 结构体完整性：打印整个sockaddr_un结构体的sun_family（必须是AF_UNIX）和sun_path字段，和纯C里的结构体做字节级对比，确保没有对齐或赋值错误。

5. Solaris11本地套接字的行为变化 #

Solaris11对本地套接字的默认配置做了调整：

• 试试显式设置SO_REUSEADDR选项：在JNI创建socket后，添加这段代码：

  int opt = 1;
  if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) == -1) {
      perror("setsockopt SO_REUSEADDR failed");
  }
  

  有些场景下，Solaris11默认禁用了地址重用，旧的socket残留会影响新连接建立。

先从打印错误码开始，这是最快定位问题的方法，再顺着权限、路径、编译选项这些点排查，大概率能找到症结。

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