diff --git a/src/advance-practice1/multi-threads.md b/src/advance-practice1/multi-threads.md
index 3a15d85e..35680451 100644
--- a/src/advance-practice1/multi-threads.md
+++ b/src/advance-practice1/multi-threads.md
@@ -527,7 +527,7 @@ impl Worker {
 
 一旦获取到锁里的内容 `mpsc::Receiver<Job>>` 后，就可以调用其上的 `recv` 方法来接收消息，依然是一个 `unwrap`，原因在于持有发送端的线程可能会被关闭，这种情况下直接 `panic` 也是不错的。
 
-`recv` 的调用过程是阻塞的，意味着若没有任何任务，那当前的调用线程将一直等待，直到接收到新的任务。`Mutex<T>` 可以同一个任务只会被一个 Worker 获取，不会被重复执行。
+`recv` 的调用过程是阻塞的，意味着若没有任何任务，那当前的调用线程将一直等待，直到接收到新的任务。`Mutex<T>` 可以保证同一个任务只会被一个 Worker 获取，不会被重复执行。
 
 ```shell
 $ cargo run
@@ -570,7 +570,7 @@ Worker 2 got a job; executing.
 终于，程序如愿运行起来，我们的线程池可以并发处理任务了！从打印的数字可以看到，只有 4 个线程去执行任务，符合我们对线程池的要求，这样再也不用担心系统的线程资源会被消耗殆尽了！
 
 
-> 注意： 处于缓存的考虑，有些浏览器会对多次同样的请求进行顺序的执行，因此你可能还是会遇到访问 `/sleep` 后，就无法访问另一个 `/sleep` 的问题 :(
+> 注意： 出于缓存的考虑，有些浏览器会对多次同样的请求进行顺序的执行，因此你可能还是会遇到访问 `/sleep` 后，就无法访问另一个 `/sleep` 的问题 :(
 
 
 ## while let 的巨大陷阱