执行以下命令解决

 git config core.protectNTFS false

想把 iPhone 的照片导入到 Mac 上面, 插上之后, 一直连了断, 断了连. 充电的标志一下有, 一下无. 如果打开 photos.app 会突然看到一下连上, 马上断掉, 然后重新连上, 再次断掉.

一开始怀疑是充电线的问题, 因为有的充电线只有充电的线路, 没有数据线路. 但是这根线本来就是为了传数据买的, 并且时断时续, 跟线怎么摆放, 是不是弯曲没有任何关系, 说明很有可能不是线的问题.

于是去 google 了一下, 发现其他人也遇到类似的问题. 其中有一个官方问答里面提到了 usbd 的进程. 于是打开了 Mac 的 monitor, 确实看到了 usbd 进程. 于是强制退出这个进程, 然后重新插上 iPhone, 然后 iPhone 提示是不是信任这个设备, 点击确定, 问题解决.

遇到过几次 Java NIO 使用 DirectMemory 导致的 OOM, 在诊断的过程中, 其中一个问题就是如何定位当前使用的 Direct Memory 的大小.

在早期, 都是通过 Java NMT Native Memory Tracking 的工具, 首先启动的过程中添加 tracking 的参数, 然后启动后去重现, 然后使用 jcmd 命令去查看各种内存区域的使用情况.

当然, 也可做一个 heap dump, 通过 heap dump 中的 DirectByteBuffer 等实例的 capacity 来确定到底使用了多大的大小.

上次在 Java Performance 这本书的第二版看到, JVM 带的 MBean 就包含了一个 MBean, 它就能确定当前 JVM 使用 Direct Memory 的大小. 所以, 如果你在桌面环境, 可以通过 JConsole 或 JVisualVM 等工具去查看这个 MBean, 如那本书里的截图:

或者 google 一下 jmx command line, 能看到很多人写的命令工具, 去连接 JVM, 然后查看 MBean 状态的, 也能达到同样的目的.

我们公司的框架工具自动提供在页面查看各种 MBean 状态的功能, 非常好用. 直接能看到 DirectMemory 已经达到设置是上限.

内部推荐 联系(base64 encoding): eGlhdGlhbkBlYmF5LmNvbQ==

以下是最新(2020/07/22)的职位列表: 具体 JD 见 https://www.ajinga.com/company-detail-new/5790/

有时候为了让 CPU 贡献最大的能力, 我们会想尽办法让 CPU 在最高频上达到100%使用率, 可是无论怎么优化都达不到100%, 到底问题出在哪里?

1. 各种 IO 拖慢了 CPU (waiting), 导致 CPU 在等取指令, 从网络到本地, 从磁盘加载到内存, 从内存加载到缓存, 从缓存到寄存器, 在内核态和用户态直接复制;
2. 各种锁 线程/进程被 block;
3. 线程数不够多;