根本原因是JMeter只加载lib/目录下的jar，不识别Maven classpath；需将含依赖的fat jar放入lib/，类须继承AbstractJavaSamplerClient并实现runTest，参数通过JavaSamplerContext获取，避免阻塞操作和日志输出。
Java请求取样器为什么总报 ClassNotFoundException
根本原因是 JMeter 没有自动加载你项目里的 class 或 jar，它只认 lib/ 目录下的依赖，且不走 Maven classpath。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把编译好的
.jar（含所有依赖，推荐用maven-assembly-plugin打成 fat jar）丢进 JMeter 的lib/目录，不是lib/ext/ - 确保 jar 包里没有重复的第三方库（比如两个不同版本的
slf4j-api），否则 JMeter 启动时可能静默失败 - 类必须继承
org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient，且实现runTest方法——少一个方法或签名不对，就会在 GUI 里看不到该类 - 别在 IDE 里直接跑 Java Sampler 类，JMeter 不会读你的
target/classes，得真打包、重启 JMeter 才生效
如何让 Java 请求取样器接收动态参数
JMeter 的 Java Sampler 本身不支持像 HTTP 请求那样点选变量，参数全靠 JavaSamplerContext 传进来，写死就废了。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在 JMeter GUI 的 Java Request 配置界面里，填入键值对，比如
host=api.example.com、timeout=5000 - 代码里用
context.getParameter("host")拿值，注意空指针——没填默认是null，别直接.toString() - 数值型参数要手动转：用
Integer.parseInt(context.getParameter("timeout"))，别信自动装箱 - 如果参数是 JSON 或复杂结构，建议 Base64 编码后传入，再在 Java 侧解码，避免引号、换行导致解析错乱
Java Sampler 性能差、线程阻塞怎么办
很多人写完发现吞吐量上不去，一查线程堆栈全是 WAITING，其实是自己写的逻辑卡住了 JMeter 的采样线程。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 绝对不要在
runTest里调用Thread.sleep()或同步 I/O（比如FileReader），这会让整个线程挂起，压测线程数再多也没用 - HTTP 调用必须用异步客户端，比如
OkHttp的enqueue()，或HttpClient的executeAsync()；别用HttpURLConnection原生同步方式 - 连接池要显式配置：OkHttp 的
ConnectionPool、HttpClient 的PoolingHttpClientConnectionManager，不然每请求新建 TCP 连接，扛不住并发 - 日志输出关掉：删掉所有
System.out.println和低级别log.debug，JMeter 日志框架在高并发下写磁盘会成为瓶颈
导入自定义 Java Sampler 后 JMeter 启动报错或类不显示
常见现象是启动日志里出现 java.lang.VerifyError 或 GUI 列表空白，本质是类加载冲突或字节码不兼容。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确认你用的 JDK 版本 ≤ JMeter 自带的 JVM 版本（比如 JMeter 5.6 默认适配 JDK 11，你用 JDK 17 编译的 class 就可能 Verify 失败）
- 检查 jar 包是否包含
MANIFEST.MF里声明了Class-Path:，JMeter 不解析这个字段，依赖必须全部打进 jar - 删掉
lib/ext/下旧版同名 jar（比如你放了guava-31.1-jre.jar，但 JMeter 自带guava-29.0-jre.jar，类加载器可能随机挑一个导致 NoSuchMethodError） - 临时加 JVM 参数
-Dlog_level.jmeter=DEBUG启动 JMeter，看控制台有没有 “Failed to load class” 类似提示，比 GUI 报错更早暴露问题
最麻烦的其实是 classpath 隐式污染——JMeter 启动时会扫描 lib/ 下所有 jar，哪怕你没在 Sampler 里 import，只要某个 jar 间接依赖了冲突版本，就可能在运行时某次请求才崩。建议每次更新依赖都清空 lib/，只留必需项。
