比如你读文件要略过若干个字节的头部（比如 BOM ）
更多的情况是你从网络读了一些 byte 过来，要略过头尾

测试了下普通的，如果是编译的时候什么参数都不加是 300 多毫秒。加上-O3 就变成 0 毫秒了。看看是不是你的编译参数的问题。因为 operation 函数对 result 的操作，所有前面的都是没有意义的，只有最后一个有意义，那么编译器完全可以进行优化

大部分商业的 jprofiler, YourKit, XRebel
记得开源的也有，好像用的不多

自己随便用什么语言写个脚本，对于每个进程的 PID，cat /proc/%d/net/dev
能看到这个进程在不同网卡的进出流量

没戏，都是喙头，以前公司买过，号称无限流量，上面就放个 nginx 给手机游戏的 app 做静态图片的存储，
两三天就被停了，退钱，发来 mail 说你的流量影响了其它用户的使用，如何如何

VMWare ESXi 应该最省事，不要钱，正好你个人用也用不上 VCenter 那些高级的 HA 之类的功能
问题是不支持消费级的网卡(比如 Realtek)，记得网上有绕过去的办法，
总之试试吧, 访问就 VNC/RDP/SSH 这些

试过一些，和 opencv / ffmpeg / imagemagick 没法比，如果要很强的功能还是 Runtime.exec 或者 JNI 调用

一个 thread 的内存占用，包括创建线程的时候可以指定参数来设置 stack 的大小，不指定就用默认的 stack 大小
加上内核保存这个 thread 的状态信息的各种 struct。

参考 pthread_create, pthread_attr_t

Win 下也一样。

不想远程装东西的话 jni 配合 perfmon api 或者 wmi api 远程需要建立连接，用户名密码，以前做过肯定可行，问题是
Home 版貌似不行，再就是 win 上需要权限比较高的用户才行，记得至少是 power user 组，要是客户比较严的话不可能给你这个用户

WIN 的话调用 MS 的 Performance Counter API 或者 WMI API
Linux 就调用 ps 等等工具，parse output

建议用查询条件来区分，
没法区分的话建议直接用原生的 jdbc resultset 来控制，总之如果是一个大表的话这种对数据库服务器的压力肯定会很大，
建议用多次查询每次小批量的数据

1. 用线程号，或者 userid，requestid 之类的来区分
2. 比较时髦的方法是 tracing，opentracing / jaeger / spring sleuth